1

マスターブランチとデバッグブランチがあります。それらは1コミット離れています。デバッグブランチはマスターから分岐し、 1 つのコミットがあります。それらをマージするときは、よく知っているように別のコミットを作成せずに、マスターブランチをデバッグブランチに早送りします。master ブランチ (マージ後に HEAD^ になる) からの情報、つまりコメントが欠落しています。いくつか質問があります:

ブランチがマージされたことを示すコメントで別のコミットを作成しないのはなぜですか?
早送りの基準は？
早送りマージについて偏執的になり、毎回チェックする必要がありますか? ファイルに動作に影響を与える可能性のある
ものは何もないと思います:.gitconfig

[merge]
    tool = fugitive
[push]
    default = upstream
[diff]
    tool = vimdiff
[mergetool "fugitive"]
    cmd = vim -f -c \"Gdiff\" \"$MERGED\"
[difftool]
    prompt = false
4

1 に答える 1

1

マージしようとしているコミットが現在のコミットを親として指している場合、Git はデフォルトで早送りマージを行います (Git コミットには (ほとんど) 常にその親へのポインタ、つまり先行コミットが含まれます)。

ここで、コミット A は開発上にあり、B はマスター上にあります

C      <---       B      <---   A
older stuff       master        develop

早送りマージ後 ( git checkout master; git merge develop):

C      <---       B      <---   A
older stuff                     develop
                                master

このシナリオでは、競合は発生しません。

これをより複雑なマージと比較してください

C - B'
  \ 
    A'

ここで、B' と A' は同じ場所に変更を導入した可能性があるため、競合が発生する可能性があり、マージ コミット M で解決できる必要があります。

C - B'-M
  \   /
    A'

デフォルトの早送りマージ動作が必要ない場合は、 --no-ff スイッチを使用できます。git merge --no-ff develop上記の最初の例では、生成されます。

C - B  -  M (master)
     \   /
       A
       develop

M は、強制されたマージ コミットです。マスターはM、現像はBです。

バグの多い競合が発生する可能性があるため、人々は早送りではないマージに対して実際にはより偏執的になる傾向があります。早送りの場合にのみマージが進むようにしたい場合は、次のことができます。git merge --ff-only develop

したがって、表示されている Git の動作は標準的なものであり、.gitconfig.

この回答には詳細があります。

于 2013-06-15T07:41:03.530 に答える