Git ユーザマニュアル (バージョン 1.5.3 以降用)
(訳注：この資料は、http://www.kernel.org/pub/software/scm/git/docs/user-manual.html に掲載されている 内容を日本語訳したものです。 英語が得意でないので、誤訳があるかもしれません。 必要な場合は、原文を参照してください。) git は高速な分散リビジョン管理システムです。 このマニュアルは、基本的な UNIX コマンドのスキルをもった人が読むことを想定していますが、 git に関する前提知識は必要ありません。 Chapter 1, リポジトリとブランチ と Chapter 2, 履歴の探索 では git を使用してプロジェクトを取得・調査する方法を説明します。 — これらの章を読むことで、ソフトウェアプロジェクトの特定のバージョンをビルドして テストしたり、回帰点を探し出す方法などを習得してください。 実際に開発する必要のあ
みたのブログ: Bisection searches
あるプログラムをバージョンアップすると、それまでちゃんと動いていたのに何か動作がおかしくなってしまうということはよくあると思います。 再現性のあるバグがあって、ちゃんと動作するバージョンと、そうでないバージョンがあってそのプログラムが適切にバージョン管理されていれば、ほとんどの場合バージョン間の二分探索することによって、そのバグがいつどの変更によって引き起こされるようになったか特定することができます。 Linux kernel は、 v2.6.12 ぐらいから git というリビジョン管理システムで管理されていて、 上記のようなバグの二分探索は git-bisect というツールでおこなえます。 http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html たとえば v2.6.16 ではちゃんと動いていたけど v2.6.17
ユメのチカラ: カーネルにおけるリグレッションの特定
例えば、2.6.17では問題ないのに、2.6.18だとなぜか問題が発生するとする。linux kernel は git というソースコード管理システムによって、全ての変更が管理されているので、その機能を利用して問題を発生させたパッチを特定する事ができる。 基本的な考え方は、コミットしたパッチを問題を発生させた組と、発生しない組にわけていって、問題を絞り込む。2分検索だ。 例えば、1000個分の変更がコミットされていたとする。これを問題が発生しない状況から一個一個順ぐりにあてていき、問題が発生したら、最後にあてたパッチが原因だということがわかる。この順ぐりにあてていく場合、最悪1000回試行錯誤しなくてはいけない。 2分検索の場合、まづ、500個分あてた状態で(gitで簡単にそのような状況をつくれる)試験をし、仮に問題が発生しなければ、残りの500個に問題があるので、さらに、その半分250個
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A Visual Git Reference
IBM Developer
