実用 Git 第3版

16章高度な操作

この章では、Gitリポジトリの高度な操作のためのコマンドを取り上げる。これらのコマンドは、ファイルを操作するものからコミットを検索するものまで、さらには特定の要件のためにリポジトリを分析して書き換えるものまである。すでにご存じのように、Gitリポジトリの操作、特にリポジトリのコミット履歴を書き換えるような操作を実行すると、一定の波及効果が及ぶ。いつものことだが、このようなコマンドを実行するときには注意が必要だ。

16.1　ハンクの対話的なステージング

少し不吉なものを感じる名前かもしれないが†1、ハンクの対話的なステージングは開発作業を簡潔で簡単にわかるコミットにまとめて単純化するために使われる非常に強力なツールだ。パッチを分割してくれとか、コンセプトを1つに絞ったパッチを作ってくれと言われるようなことがあるなら、この節は役に立つかもしれない。

[†1] 訳注：hunkには大きな塊、色男といった意味がある。

小さな単位で考えて開発することができているとびきり優秀なコーダーでもない限り、あなたの日常的な開発プロセスは少しだらしなく広がり、複数の絡み合ったアイデアを含んだものになっているだろう（私たちもそうだ）。コーディングについての1つの考えが別の考えを生み、そのすぐあとに最初のバグをフィックスし、別のバグにつまずく（しかしそれもフィックスする）。そうこうするうちに、簡単な新機能を追加する。同時に2つの綴りの誤りも直している。

そして、あなたが私たちと同じように、重要なコードに変更を加えたときにすぐに上流のリポジトリへの組み込みを申し入れるのではなく、誰かにレビューしてもらうことが大切だと思っているなら、1個のパッチに関係のないまちまちな変更を全部押し込むようなことはしないだろう。実際、一部のオープンソースプロジェクトは、それだけで完結している独立したフィックスを1つのパッチにまとめて提出することを求めている。つまり、1つのパッチで複数の目的を達成しようとしてはならないのである。個々のアイデアは、しっかりと定義された単純なパッチで表現できるような独立したものでなければならない。そして、パッチはその仕事をするために必要なだけの大きさでなければならず、それ以上であってはならない。複数のアイデアをまとめて上流に送らなければならないなら、複数のおそらく順に並べられたパッチが必要になる。常識的に言って、そのようなパッチやパッチシーケンスは、しっかりとしたレビューを受け、短期間で処理され、上流の開発本流に受け入れられるはずだ。 ...