我正在關注 gitflow 分支模型。我非常嚴格地遵循指導方針。
- 我從 dev 創建一個發布分支，并在那里進行最終的錯誤修復和調整
- 然后我把它合并到main，然后到dev，然后洗掉release分支
- 將發布分支合并到主分支和開發分支時，我使用 --no-ff（無快進）標志
- 我目前唯一沒有遵循的是將發布的更改合并到其中后，從 git 標記我的 main。相反，我使用發布功能從 GitHub 存盤庫標記它。
但是，我的開發分支現在這樣說：
該分支提前 1 次提交，主后 1 次提交。
我對此感到困惑。似乎每個分支上的新合并提交（由將發布合并到 dev 和 main 引起）是唯一的區別。這應該發生嗎？難道我做錯了什么？
uj5u.com熱心網友回復：
這完全沒問題，在某些情況下也是可以預料的。讓我們來看看發生了什么：
- 您
release從develop. 此時develop和release是完全相同的。 - 您添加了一些帶有錯誤修復的提交
release（或者沒有，出于此問題的目的，它實際上并沒有改變結果）。 - 一旦對 感到滿意
release，就可以部署它并將其合并到main使用--no-ff（無快進）標志中。這會在 上創建一個新的合并提交main。因此，此時release并main具有相同的內容，但main有一個額外的提交。 - 現在您還合并
release回develop，也使用--no-ff. 這會創建一個新的提交develop，它不在releaseor上main。 - 現在你洗掉
release.
所以在這一點上，develop至少有1 個提交不在 on main，并且恰好main有一個提交不在. 大概自創建分支以來您沒有添加任何提交，因此將恰好是 1 之前的提交，并且恰好是 1 之后的提交。developdevelopreleasedevelopmainmain
注意：下次你做一個release分支時，同樣的程序會發生，但你最終會得到 2 個main不在的提交develop，這將繼續增加，直到你做你的第一個hotfix分支，這將帶來所有那些舊的合并一次又一次地承諾develop。這是意料之中的，但當您第一次看到它時可能會感到困惑。
提示：在經歷了hotfix將許多合并提交回傳到的分支之后develop，現在當我在使用 Git Flow 的 repos 中作業時，在合并release到之后main，我更喜歡合并main到develop而不是合并release到develop. 內容將是相同的，但現在develop不會落后main了。這還有一個額外的好處，那就是在部署之前更容易確定任何release分支是否完全是最新的；main您只需要確保提交master點也位于release.
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/443665.html