1

開発ブランチに切り替えた後、gitが作業中の機能ブランチをメインの開発ブランチにマージする原因となった状況を理解しようとしています。

マージを元に戻すことはできましたが、完全に解決するのに1日の大部分を要したため、将来的には回避したいと思います。

ワークフローは次のとおりです。

機能ブランチで作業した後、バグ修正に取り組む必要があります。私の機能ブランチ（refs / heads / feature / uploader / 90）は、メインの開発ブランチに対応しています。

git merge origin/develop

次に、開発ブランチに切り替える必要があります。

git checkout develop

git出力：

ブランチ'develop'に切り替えました。ブランチは'origin/ development'より88コミット遅れており、早送りできます。

次に、プルを発行すると：

git pull origin refs/heads/develop

何らかの理由で、gitが私の機能ブランチをdevelopにマージすることを決定したようです。出力は次のようになります。

branch develop -> FETCH_HEAD
Fast-forwarding to: 102301bcc51fc6d7978e5287df9d031d82e53bc9
Trying simple merge with d139bab0a96df01408f82110e38b6e0b6b98e6e6
Merge made by the 'octopus' strategy.

そして、私のコミットログは私がコミットしていることを示しています： github.com：MakerStudios/dashboardのブランチ'feature/ uploader/90'と'develop'をdevelopにマージします

4

1 に答える 1

2

これは、早送りマージとして知られているものです。

これは（デフォルトで）マージを実行するたびに発生します。この場合、常駐しているブランチのすべての変更が、マージしようとしているブランチにすでに存在します。

したがって、上記の例では、refs/heads/feature/uploader/90のすべての変更がすでに含まれているrefs/heads/developため、真のマージコミットを作成する代わりに、と同じコミットを指すようにgitrefを移動しました。developfeature/uploader/90

を実行することでこの動作を回避できますがgit merge --no-ff、これは早送りされないか、merge.ffプロパティをに変更しますfalse。

望ましくない早送りマージを元に戻すことは、あなたが思っているほど難しくはありませんgit reset --hard。マージで入ってくるものの前の最後のコミットまでです。

于 2013-01-10T19:52:51.963 に答える