4

私はSVNのバックグラウンドを持っているので、典型的なgitワークフローがどのように見えるかわかりません。SVNでマージするときは、マージを説明するコミットメッセージを提供します。これが必要なのは、SVNのマージ追跡が歴史的に貧弱だったためです。

gitのデフォルトの動作は、マージが成功した場合にマージの結果を自動的にコミットすることであることに気づきました。これは、通常、ログにマージが表示されないことを意味します。したがって、履歴内のすべてが1つのブランチで開発されたように見えます。これは、マージを追加のコミットとして表示するよりも望ましいですか？理由とそうでない理由はいくつか考えられますが、他のユーザーからの意見をお願いします。

4

2 に答える 2

7

あなたは 2 つの状況を誤解していると思います (または、あなたが何を尋ねているのかわかりません)。

  1. 現在使用しているブランチの直接の子であるサイド ブランチをマージすると、いわゆる早送りの状況が発生します。通常の git ではマージ コミットは作成されず、ブランチ ヒントが進められるだけですが、--no-ffオプションで防止できます。

    デフォルトでは、このような無意味なマージは回避されます。これは、真の分散開発でより適切に機能するためです。

  2. 現在のブランチとマージしようとしているブランチが本当に分岐している場合、つまり、各ブランチに他のブランチにないコミットがある場合、git はマージを実行し、競合なしでマージを実行できる場合は、自動的にマージコミットを作成します。merge.logこのようなマージ コミットには、 config 変数 (以前は)の対象となる、自動化されたコミット メッセージがありますmerge.summary。オプションを使用して、このような自動コミットをコミットしないようにすることができ--no-commitます。

    もちろん、「git log --no-merges」を使用しない限り、「git log」はマージコミットを表示します。

この説明が少しでもお役に立てば幸いです。

于 2009-10-20T17:30:41.670 に答える
5

--no-mergesにオプションを指定しない限りgit log、通常、自動生成された簡単なコミットの説明が与えられたマージが表示されます。

gitはコミットの親子関係を記録し、マージの興味深い機能はその構成ブランチであるため、これは通常は問題ありません。

を試してみるgit log --graph --onelineか、グラフィカルな履歴ビューアを使用してください。gitレコードのマージ方法は、長く続くマージコミットメッセージよりもはるかに重要で便利であると確信できます（すべきです！）。

マージは、解決で行われた「魔法の」何かがあった場合にのみ、詳細なコミットメッセージを本当に必要とします。これは手動による介入を意味するため、この時点で簡単に追加できます。

于 2009-10-20T17:26:54.667 に答える