GITユーザーがコミットを編集する理由

Radio-Tの最後の2つの問題で、発表者はGITについて議論しようとしました。 Eugene（@Umputun）は、リベースが必要な理由を疑問に思い、コミットを編集しているかどうかを尋ねたときに非常に驚きました。 私の意見では、GITを理解するためには、Linuxカーネル開発プロセスを掘り下げるだけで十分です。



変更がメインリポジトリにどのように到達するかを見てみましょう。 開発者はgitを自分自身に複製し、新しい機能の開発を開始します。 開発の過程で、彼はコードを書き、テストし、バグを見つけ、修正します。 おそらくいくつかのコミットを行っています。 機能の準備ができたら、これらすべてのコミットをパッチの形で受け取って送信することはできません。これをすべて単一のパッチの形で送信することはできません。

開発者の次の目標は、メンテナーや他のチームメンバーが理解できるようにすべての変更を解除することです。 このプロセスにはいくつかのルールがあります。各パッチには論理的な変更が1つだけ含まれています。 各パッチは破壊的であってはなりません。 コミットメッセージは、可能な限り詳細に変更を説明する必要があります。



この二重の仕事には、独自の動機があります。 パッチの表示（レビュー）は、最も魅力的で興味深いものではないため、誰もがこのプロセスを最大限に促進するよう努める必要があります。 メンテナーは、他のチームと同様に、適切な解決策を求めて考えが浮かんでいるのを見ることに興味がありません。 この特定のアプローチが選ばれた理由を説明するコミットメッセージを読むだけで十分です。 さらに興味深いのは、開発中に作成したバグです。



ほとんどの場合、新しいブランチを作成し、すべてのコミットをロールバックし（gitリセット）、git commit --interactiveでブレークダウンを開始します。 このコマンドを使用すると、どの変更をどのコミットに適用するかを選択できます。 すべての準備ができたら、git format-patchコマンドを使用してパッチを作成し、git send-emailを使用してパッチを送信できます。



パッチがすぐに受け入れられたのは良いことですが、誰かがそれらのエラーを見つけて、コメントまたは修正するために何か他のものを求めます。 この場合、git rebase --interactiveが便利です。これにより、コミットの順序を変更したり、2つ以上のコミットを結合したり、任意のコミットで編集を停止したりできます。 すべての欠点を修正した後、パッチが再度作成されて送信され、それが受け入れられるまで続きます。 ところで、メーリングリストにパッチを送信する前に、リポジトリを更新する必要があります。これにより、すべての変更が最上部に残るようになります。これはリベースと呼ばれます。



メンテナーがパッチを受け入れた場合、そのリポジトリにコミットします。 次のマージウィンドウが到着すると、プルアップ要求をアップストリームメンテナーに送信します。 理想的には、それぞれの新しい変更を個別に転送し、線形の履歴を持つことが可能です。 私たちは現実の世界に住んでいます。そこでは、変化は互いに衝突する可能性がありますが、個々の変化の時間はありません。 そのため、git pullを使用すれば、すべての変更が1つの部分にコミットされ、履歴（git log）ではすべてが線形に見えますが、競合は1回修正されます。



また、ポッドキャストでは、すべてを壊したコミットをバイナリ検索するツールであるgit bisectが言及されました。 バグがなく、バグが既に存在するコミットを知っているとします。 目標は、このバグを最小限の手順で植え付けたコミットを見つけることです。 コミットにロールバックします。これはまさに中間です。 この時点でバグがない場合、問題のコミットは右側にあり、そうでない場合は左側にあります。 それが見つかるまで繰り返します。 git bisectの特徴は、非直線の履歴を正しく処理できることです。これについては上で説明しました。