GitHub 分支總是落后於 master 一個提交

Question

我有一個帶有master分支和dev分支的 GitHub 項目，當我從 dev 合並到 master 時，我看到合並提交似乎導致 dev 分支被認為是master后面的一個提交。

這在這樣的工作流程中是常見的嗎？ 還是我做錯了什么？ 我嘗試從 master 合並回 dev，但情況變得更糟（后面一個提交 + 前面一個提交）。 還嘗試了從 master 到 dev 的 rebase 合並，但 dev 留下了一個提交。

解決這個問題的方法是什么？

謝謝

使用來自 dev 的提交歷史進行編輯：

和主人：

Answer 1

更新答案

好的，你已經處理了拉取請求，但總體原則是一樣的：是的，當你第一次合並到 master 時，你的源分支（ develop ）在這個過程中實際上變成了一個提交，就像我在第一個中描述的那樣下面的版本。 您可以放心，這在此類工作流程中很常見，並且不會阻止您合並，它們只是快速前進。

---

（下面是答案的第一個版本，錯誤地假設了本地合並操作）

當您在第一次合並后描述時， master又有一次提交，這就是合並提交，正如您正確猜測的那樣。

此時，如果您希望兩個分支完全同步（盡管此時它們在文件方面已經相似），您需要做的就是merge master merge回develop ，這將是一個簡單的快進，其中develop獲得最后一次提交。