繁栄したgit-mergeの複雑さ

はじめに

「キラー機能」SLE Gitは軽量ブランチであると考えられています。 SVNでGitに切り替えたので、この利点を最大限に感じました。ブランチは非常に高価なプロセスでした。ブランチを作成するには、作業ディレクトリ全体をコピーする必要がありました。 Gitではすべてがシンプルです。ブランチを作成するということは、 .git/refs/headsフォルダー内の特定のコミットへの新しいポインターのみを作成することを意味します。

Gitで分岐するための主なユーザーレベルのコマンドは、git-branch、git-checkout、git-rebase、git-log、そしてもちろんgit-mergeです。 私にとっては、git-mergeが最も大きな責任のあるゾーンであり、巨大な魔法のエネルギーと大きなチャンスのポイントだと考えています。 しかし、これはかなり複雑なチームであり、Gitのかなり長い経験でさえ、その微妙な点や異常な状況で最も効果的に適用する能力を習得するには不十分な場合があります。

git-mergeの複雑さを理解し、この素晴らしい魔法を飼い慣らしてみましょう。

ここでは、 合併が成功した場合のみを考えます。つまり、 競合のない合併を意味します。 競合の処理と解決は、別の記事にふさわしい興味深いトピックです。 Git internals：data storage and mergeの記事も読むことを強くお勧めします。この記事には、私が依存している多くの重要な情報が含まれています。

チームの解剖学

マニュアルによると、コマンドの構文は次のとおりです。

 
  git merge [-n] [--stat] [--no-commit] [--squash] [-[no-] edit] 
  [-s <戦略>] [-X <戦略オプション>] 
  [-[no-] rerere-autoupdate] [-m <msg>] [<commit> ...] 
  git merge <msg> HEAD <commit> ... 
  git merge --abort 
 

概して、Gitには2つのタイプのマージがあります。早送りマージと真のマージです。 両方のケースのいくつかの例を考えてみましょう。

真のマージ

いくつかの改善バグを導入するために、masterブランチから逸脱しています。 コミットの履歴は次のとおりです。

 
  マスター：A-B-C-D 
                   \ 
  機能：X-Y 
 

マスターgit merge featureブランチで実行します。

 
  マスター：A-B-C-D-（M） 
                   \ / 
  機能：X-Y 
 

これは最も一般的なマージパターンです。 この場合、masterブランチに新しいコミット（M）が作成されます。これは2つの親を参照します：コミットDとコミットY。 マスターポインターはコミット（M）に設定されます。 このようにして、Gitはどの変更がコミット（M）に対応し、どのコミットがmasterブランチの最後であるかを理解します。 通常、マージコミットは「Merge branch 'feature'」などのメッセージで行われますが、 -mスイッチを使用して独自のコミットメッセージを定義することもできます。

このケース専用に作成したテストリポジトリでコミットの履歴を見てみましょう。

 
  $ git log --oneline 
  92384bd（M） 
  bceb5a4 D 
  5dce5b1 Y 
  76f13e7 X 
  d1920dc C 
  3a5c217 B 
  844af94 A 
 

次に、コミット情報（M）を見てみましょう。

 
  $ git cat-file -p 92384bd 
  ツリー2b5c78f9086384bd86a2ab9d00c7e41a56f01d04 
  親bceb5a4ad88e80467404473b94c​​3e0758dd8e0be 
  親5dce5b1edef64bd0d4e1039061a77be4d7182678 
  著者Andre <andrey.prokopyuk@gmail.com> 1380475972 +0400 
  コミッターアンドレ<andrey.prokopyuk@gmail.com> 1380475972 +0400 

  （M） 
 

2つの親、リポジトリファイルの指定された状態に対応するツリーオブジェクト、およびコミットした人に関する情報が表示されます。

マスターポインターが参照する場所を見てみましょう。

 
  $ cat .git / refs / heads / master 
  92384bd77304c09b81dcc4485da165923b96ed5f 
 

実際、コミットにプッシュされます（M）。

スカッシュとノーコミット

しかし、機能ブランチの内容があなたを打ち負かすことができるとしたらどうでしょう？ たとえば、改善は小さく、1つの論理的なコミットにうまく適合することができましたが、仕事の最中に列車に逃げて家で続けなければならなかったことが判明しましたか？ この場合、2つの方法があります：リポジトリをエクスポートしてから別のマシンにインポートするか、（特に電車に行くのに10分かかり、駅まで約1キロかかる場合）- push origin feature作成しpush origin feature 。

不完全なコミットをメインブランチに注ぐことは悪いことであり、あなたはそれについて何かをする必要があります。 1つの方法、そしておそらく最も簡単な方法は、 --squashオプションです。

git merge feature --squashは、機能ブランチのすべてのコミットの変更をgit merge feature --squashそれらをマスターブランチに転送して、インデックスに追加します。 この場合、 マージコミットは作成されません 。手動で行う必要があります。

マージ時に--no-commitパラメーターを渡すことにより、squashパラメーターなしで同じ動作を実現できます。

このマージが適用される場合、機能ブランチのコミットは履歴に含まれませんが、Sqコミットにはすべての変更が含まれます。

 
  マスター：A-B-C-D-平方 
                   \  
  機能：X-Y 
 

後で、「クラシック」 git merge featureを実行する場合git merge featureこれを修正できます。 その後、ストーリーは次の形式になります。

 
  マスター：A-B-C-D-Sq-（M） 
                   \ / 
  機能：X-Y 
 

コミットせずにマージし、致命的なエラーを犯したことに気付いた場合、単純なコマンドgit merge --abortすべてを取り消すことができます。 合併中に競合が発生した場合でも同じコマンドを適用できますが、現時点では競合を解決したくないでしょう。

巻き戻し（早送りマージ）

コミット履歴の別のケースを考えてみましょう。

 
  マスター：A-B-C 
                   \ 
  機能：X-Y 
 

すべては前回と同じですが、マスターブランチにはブランチ後のコミットはありません。 この場合、早送りマージ（巻き戻し）。 この場合、マージコミットはなく、ポインター（ブランチ）マスターは単にYをコミットするように設定され、機能ブランチもそこを指します。

 
  マスター、機能：A-B-C-X-Y 
 

巻き戻しを防ぐには、 --no-ffオプションを使用できます。
git merge feature --no-ff -m '(M)'を実行する場合、次の図が表示されます。

 
  マスター：A-B-C-（M） 
                   \ / 
  機能：X-Y 
 

早送りが唯一許容される動作である場合、 --ff-onlyオプションを指定できます。 この場合、巻き戻しがマージに適用できない場合、マージが不可能であることを示すメッセージが表示されます。 最初の例で--ff-onlyオプションを追加した場合に--ff-onlyます。この例では、機能を分岐した後、マスターブランチでコミットCが作成されました。

git pull origin branch_nameを実行すると、 --ff-onlyようなもの--ff-onlyことを追加できます。 つまり、origin / branch_nameブランチとマージするときに巻き戻しが受け入れられない場合、操作はキャンセルされ、実行できないことに関するメッセージが表示されます。

合併戦略

git-mergeチームには、-- --strategy 、ストラテジーという興味深いオプションがあります。 Gitは次のマージ戦略をサポートしています。

• 解決する
• 再帰的
• 私たちのもの
• たこ
• サブツリー

戦略を解決する

解決戦略は、従来の3者間マージです。 標準の3者間マージアルゴリズムは、共通の祖先を持つ2つのファイルに使用されます。 従来、このアルゴリズムは次の手順の形式で表すことができます。

1. 共通の祖先を検索し、
2. 共通の祖先に関して両方のバージョンで変更されたブロックを検索する
3. 変更されないままのブロックが記録されます。
4. 子孫の1つでのみ変更されたブロックは変更済みとして記録され、
5. 両方のバージョンで変更されたブロックは、変更が同一である場合にのみ記録されます。それ以外の場合、競合が宣言され、その解決がユーザーに提供されます。

この戦略には1つの欠点があります。最初の共通コミットが常に2つのブランチの共通の祖先として選択されます。 最初の例の場合、これは怖くありませんgit merge feature -s resolve安全に使用でき、結果が期待されます。

 
  マスター：A-B-C-D-（M） 
                   \ / 
  機能：X-Y 
 

ここで、Cは2つのブランチの共通コミットであり、このコミットに対応するファイルツリーが共通の祖先と見なされます。 このコミット以降にマスターおよび機能ブランチで行われた変更が分析され、その後、条件付きアルゴリズムのパラグラフ4および5に従って、コミット（M）の新しいバージョンのファイルツリーが作成されます。

どのような場合、解決戦略の欠如が現れますか？ コミット（M）で競合を解決する必要があり、その後開発を継続し、もう一度git merge feature -s resolveを実行したい場合に現れgit merge feature -s resolve 。 この場合、コミットCは再び共通の祖先として使用され、競合が再び発生し、介入が必要になります。

再帰的戦略

この戦略は、解決戦略の問題を解決します。 また、3者間マージも実装しますが、実際のマージではなく、次の条件付きアルゴリズムに従って構築される「仮想」祖先が祖先として使用されます。

1. 共通の祖先のすべての候補が検索され、
2. チェーンは候補をマージし、新しい「仮想」祖先を作成します。最近のコミットの優先度が高くなり、競合の再現が回避されます。

この行動の結果は共通の祖先とみなされ、三国間合併が行われます。

この戦略を説明するために、plasticscmブログの記事Merge recursive strategyから例を借りましょう。



したがって、mainとtask001の2つのブランチがあります。 そして、開発者は倒錯の良い判断者であることが判明しました：彼らはmainブランチのcommit 15とtask001ブランチのcommit 12、およびcommit 16とcommit 16をマージしました。 、しかし、「仮想」祖先の構築を伴う再帰的戦略は私たちを助けます。 その結果、次の図が得られます。



再帰戦略には、 -Xスイッチを使用してgit-mergeコマンドに渡される多くのオプションがあります。

• 私たちと彼らのもの
  競合を自動的に解決するために使用されます。 私たちのもの-「私たちの」バージョン、「dst」のバージョン、彼らのものを好む-「彼らの」バージョンを好む。
  
• 再正規化（非正規化）
  オプションをさまざまなタイプのラインフィードとマージする際の誤った競合を防ぎます。
  
• diff-algorithm = [patience | minimal | histogram | myers] 、および忍耐オプション
  ファイル差別化アルゴリズムの選択。
  これらのオプションの詳細については、 git-diffのドキュメントをご覧ください。 つまり、これらのアルゴリズムのプロパティは次のとおりです。
  デフォルトでは、myersは標準の貪欲なアルゴリズムです。 デフォルトで使用されます。
  最小 -最小限の変更を検索しますが、時間がかかります。
  忍耐 -「patience diff」アルゴリズムを使用します。 これについては、アルゴリズムの作者から 、またはSOの簡略版で読むことができます。
  ヒストグラム -「低頻度の共通要素をサポートする」と記述されている目標で忍耐アルゴリズムを拡張します。 正直に言うと、どのような具体的なケースが暗示されているかという質問に対する明確な答えを見つけることができませんでした。
  
• スペースの変更を無視、すべてのスペースを無視、eolのスペースを無視
  これらのオプションのルーツは、やはりgit-diffにあり、マージ中のファイルの区別に関連しています。
  ignore-space- change-行のスペースの数の違い、および行末のスペースの違いを無視します。
  ignore-all- space-比較時にスペースは完全に無視されますが、
  ignore-space-at-eol-行末のスペースの違いは無視されます。
  
• rename-threshold = <n>
  このオプションは、ファイルが新しいファイルではなく、git-diffがカウントされなかった名前が変更されたファイルと見なすことができるしきい値を設定します。 たとえば、 -Xrename-threshold=90%は、削除されたファイルの内容の90％を含むファイルが名前変更されたと見なされることを意味します。
  
• サブツリー[= <パス>]
  このオプションを使用して再帰マージを実行すると、サブツリー戦略のより高度なバージョンになります。アルゴリズムは、マージ中にツリーがどのように適合するかという仮定に基づいています。 代わりに、この場合、特定のオプションが示されます。
  

タコ戦略

この戦略は、3つ以上のブランチをマージするために使用されます。 結果として、コミットには3つ以上の親が含まれます。

この戦略には、潜在的な競合に関して細心の注意が必要です。 この点で、タコ戦略を使用する場合、マージを拒否することもあります。

私たちの戦略

私たちと再帰戦略を混同しないでください。

git merge -s ours obsoleteを実行すると、あなたはちょっと言った：私はブランチの履歴をマージしたいが、廃止されたブランチで発生したすべての変更を無視したい。 代わりに、私たちの代わりに次のオプションを使用することをお勧めします。

 
  廃止された$ git checkout 
  $ git merge -s recursive -Xtheirs master 
 

私たちの戦略は、より根本的な手段です。

サブツリー戦略

この戦略を説明するために、 「Pro Git」 という本のサブツリーのマージの章の例を見てみましょう。

プロジェクトに新しいリモートリポジトリであるrackを追加します。

 
  $ git remote add rack_remote git@github.com：schacon / rack.git 
  $ git fetch rack_remote 
  警告：一般的なコミットはありません 
  リモート：オブジェクトのカウント：3184、完了。 
  remote：オブジェクトの圧縮：100％（1465/1465）、完了。 
  リモート：合計3184（デルタ1952）、再利用2770（デルタ1675） 
  オブジェクトの受け取り：100％（3184/3184）、677.42 KiB |  4 KiB / s、完了。 
  デルタの解決：100％（1952/1952）、完了。 
  git@github.comから：schacon / rack 
   * [新しいブランチ]ビルド-> rack_remote /ビルド 
   * [新しいブランチ]マスター-> rack_remote /マスター 
   * [新しいブランチ] rack-0.4-> rack_remote / rack-0.4 
   * [新しいブランチ] rack-0.9-> rack_remote / rack-0.9 
  $ git checkout -b rack_branch rack_remote / master 
  ブランチrack_branchは、リモートブランチref / remotes / rack_remote / masterを追跡するように設定されています。 
  新しいブランチ「rack_branch」に切り替えました 
 

masterブランチとrack_branchブランチの作業ディレクトリがまったく異なることは明らかです。 スカッシュを使用してrack_branchからmasterにファイルを追加し、必要のない事実で履歴が詰まるのを防ぎます。

 
  $ git checkout master 
  $ git merge --squash -s subtree --no-commit rack_branch 
  スカッシュコミット-HEADを更新しない 
  自動マージはうまくいきました。  要求どおりにコミットする前に停止しました 
 

ラックプロジェクトのファイルは作業ディレクトリにあります。

最後の言葉

そのため、Gitとの作業中に得られたgit-mergeの繁栄に関するすべての知識を集めました。 これが誰かを助けてくれれば嬉しいが、もし誰かが材料を補ったり、不正確や間違いを訂正してくれたりしたら、私が突然助けてくれたら嬉しい。