5

以下に説明する状況で、マージ中にコミットを選択する優先順位は何でしょうか。

develop支店があります。

D1 - D2 - D3

次にrelease、そこからブランチを作成し、いくつかのコミットを追加しました。

D1 - D2 - D3 - R4 - R5

その間に、開発するためのいくつかのコミットが追加されました

D1 - D2 - D3 - D6

次に、 ：releaseを使用してブランチからいくつかのコミットを削除します。git rebase -i HEAD~3

D1 - x - x - R4 - R5

ブランチはどのreleaseようにマージされてdevelop使用されgit merge --no-ff releaseますか？私はそれをこのようにしたい：

D1 - D2 - D3 - R4 - R5 - D6

そして、コミットの削除を伴うマージされたブランチを取得する可能性はありますか？

D1 - x - x - R4 - R5 - D6

「舞台裏」についての説明を楽しみにしています:)

4

3 に答える 3

4

を実行すると、マージ時にそれらのコミットが元に戻りますrevert。releaseあなたがした場合、rebaseそれはしません。これrevertは、明示的にそれらを削除し、その事実を履歴に保持していることを示しているためです。 rebaseそれらのコミットがで発生したことがないように見えるので、それらを削除するrelease理由はありません。merge

優先順位に関しては、どちらのブランチも同じ優先順位を持っています。ブランチに共通する最後のコミットに戻ると、各ブランチが異なる方法で何かを変更した場合、gitはそれをマージの競合として表示します。がこれらのコミットを元に戻さない唯一の理由は、rebase履歴を書き直して、そもそもブランチに存在しなかったように見せるためです。

余談ですが、これらのことをgitで、クローンで、またはブランチに注意することで、おそらく質問するよりも短い時間でテストできることに気づいていますか？

于 2012-09-05T12:57:35.800 に答える
3

他の答えへの追加として：

状況でのマージ中にコミットを選択する優先順位は何ですか？

Gitには通常、マージ中の「優先度」の概念がありません。マージ中、すべてのブランチは等しく重要であり、Gitはすべてのブランチからの変更を結合しようとします。

矛盾がある場合（異なるブランチが同じ行を異なる方法で変更するなど）、Gitはどういうわけか1つのブランチを「勝ち」させませんが、マージの競合を報告します。

これは実際には意図的な設計上の決定でした。LinuxがGitでのマージについて話している：

Linus：私個人的には、非常に再現性が高く、賢くないものが欲しいです。私が理解していること、またはそれができないと私に言っていること。

http://www.wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php

そのため、Gitは意図的に、どのブランチが「より重要」であるかを巧妙に把握しようとはしません。ユーザーに決定を任せるだけです。

于 2012-09-17T10:32:10.707 に答える
1

あなたは知っているようですgit-rebase、そう：

$ git checkout develop
$ git rebase -i D1 release

インタラクティブモードでは、コミットを好きなように選択して並べ替えることができます。

于 2012-09-05T12:54:39.017 に答える