分散型バージョン管理システム「Git」タスク単位ブランチ運用のための１０のステップ - the true power
the true power さすらいのプログラマ堀井俊和の個人的なブログです（元「表参道ではたらくCTOのブログ」）。 海外のIT・技術系ニュースのキュレーションを実践中。 今回も Git のお話。 前回、前々回のエントリで、私の Git 利用方法について書きました。 中央リポジトリは従来通り Subversion（svn）を使い続けますが、ローカルで Git リポジトリを運用し、リリース可能なコードを適宜 Subversion リポジトリに push する、という方法です。 これにより、オフラインでのコミットや、複数のタスクを並行して作業する場合における、タスク毎のソースコードの独立性確保を実現することができるようになります。 今回は、こういった利用方法を行う上で必要となる Git のコマンドや Tips を紹介したいと思います。 まずは前提事項。 今回紹介する利用法では、以下のような
Git にパッチを送って取り込まれた話
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
こわくない Git
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
黒い画面とかよくわからない人のための、ゆるふわgit入門 ～github for Windows～
リポジトリとは？ 更新履歴をためておく場所です。 gitでは、リポジトリには2種類あります。 「自分の作業用リポジトリ」と 「公開用リポジトリ」です。 今日は、 自分のPC内のフォルダ＝自分の作業用リポジトリ github＝公開用リポジトリ として話をします。 githubとは？ gitで管理した更新履歴を置いておく場所。 完成したものを見せるんじゃなく、 開発途中の履歴を見せる。 普段見えない裏側のソースコードも見える。 履歴をちょこちょこ送れるので、開発してる！感が出せるのでエンジニアに人気。 人のソースコードに手を入れて送ったりもできるらしい。 別にプログラムじゃなくてもいろんな更新履歴を管理してよい。 でも交換日記とかを管理するのはやめましょう。 流れ 必要なものを用意しよう github for Windowsをインストールしよう コミットしてgithubにpublishしよう
repoとgitとbitbucket : sms日記
最近、プライベートでコード書いてません。ryosmsです。 JCROMの更新状況を追っかけていると、某氏の謎の行動が気になったりしてたんですが、案の定ハマってたみたいなので書きます さてさて、JCROMのソースは（手が入っているところは）bitbucketでソースを管理しているので、修正してpull reqを送る （下図のイメージ） 際にはGitHubへpull requestする際のベストプラクティスがほぼそのまま使えます（githubとbitbucketの違いに気をつけるだけ） ただし、リポジトリの数が膨大（＆AOSPのリポジトリも参照してる）ので、ソースの取得にはrepoを使用します （ちなみに、2012/08/09時点でのjcrom_jb-master.xmlでは、落としてくるリポジトリの数は約300あります） repoっていうのは、簡単に言えば「複数のgitリポジトリをまとめて、
GitHub - igrigorik/bugspots: Implementation of simple bug prediction hotspot heuristic
$> cd /your/git/repo $> git bugspots -d 500 .. example output .. Scanning /git/eventmachine repo Found 31 bugfix commits, with 23 hotspots: Fixes: - Revert "Write maximum of 16KB of data to an SSL connection per tick (fixes #233)" for #273 - Do not close attached sockets (fixes #200) - Write maximum of 16KB of data to an SSL connection per tick (fixes #233) - Merge branch 'master' into close_sched
グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開
ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gerrit - Google Code