合並/變基工作流程

Question

我正在更改git-merge-workflow的過程中遇到以下問題：

到目前為止，每當我發布新版本時，我就一直將（--no-ff）在develop分支上的更改合並回master 。 這將生成一個新的merge-commit，其中包含所有develop -commits的歷史記錄（--log）。 我意識到，這是次優的，並希望真正做到快進從我的合並develop分公司master （已經改變我犯下的消息develop ，以反映一個“干凈”的方式我的變化）。

我當前的問題：最近一次對master的提交仍然是最后一次的merge-commit，因為我不能從develop到master進行ff-merge，因為2個分支“發散了”（合並-commit上缺少develop ）。

我想解決這個問題的想法是在開發中： git rebase master ，它將拉入這個merge-commit，然后使我能夠在master上進行git merge develop 。 但是，這會產生一個新的提交上develop （這個特別的合並提交）或將Git的足夠聰明，認識到這種變化的合並提交已經部分develop ？

Answer 1

git rebase master在develop會很好地滿足您的目的。

如果您的分支當前是這樣的：

A-B-C-D-E <-- master
       /
  F-G-H-I-J <-- develop

然后它們就會像這樣結束（因為IJ是從E IJ的唯一位）：

A-B-C-D-E <-- master
         \
          I'-J' <-- develop

然后，它會像下面這樣快速合並回master：

A-B-C-D-E-I'-J' <-- master

Answer 2

您的方法應該允許它工作。 當然，您可以解決此問題的另一種方法是在下一次合並時完全刪除您的developer分支，以防重新部署失敗。 然后，從master分支出一個新的開發，並從那時起重新建立基礎。

在我以前的公司中，我們也嘗試將工作流程從合並切換到重新定基。 但是最終由於合並不同的分支而出現了各種奇怪的問題。 直接從master重新開始在development分支上感覺更干凈，更安全。