Git工作流：如何合並僅在新分支上進行的提交

Question

我們正在使用git來跟蹤開發和版本化版本，並遇到了一些合並分支的問題。 這是我們的工作流程：

production/1.0.0  A--B

stage/2.0.0       A--B--C--D

development       E--F--G--J--L
                         \
feature                   H--I--K

功能開發發生在從開發創建的功能分支上，並在准備好時合並回來進行演示和測試。

這一切都運行良好，問題是創建該功能分支的開發人員將其功能放入階段分支進行部署。 因為它們在G開發時分支，當它們合並時，它包括EFG，當他們只想合並HIK時。

我們的git工作流的目標是讓開發人員標記他們自己的代碼以備發布，並協調整個開發分支將能夠合並到部署分支是不可行的，因為開發在世界各地發生。

是否有一個git命令來合並在功能分支上進行的提交？ 我知道rebase和cherry pick，但是一個功能可以由大量的提交組成，其中包括開發追趕其功能分支的合並。 有更好的解決方案嗎？

這個工作流程正確嗎？ 我們是在嘗試做一些不可持續的事情嗎？

Answer 1

這將是一個git rebase --onto與git merge-base ：

git checkout stage/2.0
git rebase --onto stage/onto $(git merge-base development feature) feature

這將重放G （在開發和功能之間的“合並基礎”提交）到stage/2.0 branch 之后的feature分支的提交。

結果：

stage/2.0.0       A--B--C--D
                            \                   
feature                      H'--I'--K'

development       E--F--G--J--L

舊的H ， I和K提交仍然在reflog（ git reflog ）中被git reflog ，但是已經被挑選並在stage/2.0之上重放。

這個工作流程正確嗎？ 我們是在嘗試做一些不可持續的事情嗎？

它有以下警告：
它需要在這樣的基礎之后進行仔細的測試，因為H ， I和K在G之上完成，這在stage/2.0分支中根本不存在。

如果這些提交依賴於基於G內容，那么在暫存分支中將找不到該初始內容。 一些回歸測試應該表明這一點。

使用git cherry-pick （也可以重放多次提交 ）會將這些提交復制到登台分支上，使feature分支保持原樣（即不在登台分支上重新設置）。
這看起來很奇怪，考慮到你需要開始哪些提交被挑選出來，以及哪些其他新feature提交還沒有被挑選到舞台上。

---

如果開發被合並到I和K之間的特征會發生什么？ （開發人員緩存他們的分支）
櫻桃挑選還包括合並和所有開發分支代碼嗎？

是的，它將包括合並提交，但不包括所有dev分支。 無論如何，它並不理想。 最好的做法是不合並dev到feature ，而墊底feature之上dev （ git rebase dev ）。
然后，當功能准備好時， rebase --onto stage/2.0

---

那么rebase --onto命令的作用基本上是將功能分支移動到stage/2.0.0 ？

是。

功能分支是否會消失？

否：通過將每個提交補丁重新應用到 stage/2.0.0 上來重新創建它。
在rebase --onto之前看到的功能分支的舊提交仍然存在，但是不可見，僅由git reflog ，如上所述。

嵌套命令$(git merge-base development feature)是否在將分支移動到stage / 2.0.0分支之前將更改從功能應用到開發？

否：它是為該功能分支計算起始提交，即：從中啟動feature分支的development提交。
如果我不使用，但一個簡單的git rebase ，從提交feature分支將包括所有提交的訪問feature HEAD（這將包括也 development提交）