使用共享功能分支的git工作流程是什么？

Question

假設我有一個分支命名feature已經分支master 。 developer1和developer2結賬feature 。 developer1提交feature更改並將其推送。 然后developer3推動一些東西master 。 此時master和feature分叉，每個都有一個單獨的commit。

如果存在沖突，那么從master那里獲取最新feature的正確方法是什么？ 我應該將master加入到該feature ，還是將其合並？

編輯：

我應該提一下，在這種情況下，我不想重寫developer2上的歷史記錄。 因為那會很糟糕。 對？

Answer 1

考慮到feature分支已經共享，它不應該在master服務器上重新定位（因為它更改了它的 - 共享 - 歷史記錄）。

從master到feature簡單合並就足夠了（沒有推測為什么dev3推送到master ）。

---

正如亞當Dymitruk 意見 ，這就是所謂的“后合並”，並根據您的屬性的角色master ，這是有問題的：如果master代表穩定生產狀態，你應該合並到 master ，而不是master 。

但是，我的回答再次沒有假設這個角色。

---

這就是為什么著名的git流在其說明博客文章合並它們來掌握（從，例如，一個hotfix分支，如我前面的評論 ）

Answer 2

git是一個很棒的工具; 但是，它不能代替開發人員之間的良好溝通。

你要問是否在改變master也必須列入feature 。 理想情況下， 功能分支應具有盡可能少的代碼。

如果變更絕對必須包含在feature ，那么你基本上有兩個選擇： git rebase ; 而且， git cherry-pick 。 我想你可以執行從一個落后的合並master進feature ; 但是，這會導致糟糕的情況......

cherry-pick允許您對當前HEAD應用特定提交或多次提交，保留評論和作者信息。 在成功地cherry-pick ed之后，git足夠聰明，知道在將feature合並回master時兩個提交是相同的。 如果只是我們談論的一些提交，那么cherry-pick就足夠了。

rebase允許您從歷史記錄中的不同點開始應用當前分支（提交行）。 正如您所指出的，對於已經擁有feature副本的developer1和developer2來說，這可能會很麻煩。 他們還需要rebase其地方發展到新的 feature分支。

在任何情況下，直接提交到master通過developer3應該已經在它自己的特性分支，而且特性分支應該已經合並。 然后可以根據需要將該功能分支合並到feature中。 假設master只有一個（最近的）提交，您可以按如下方式糾正這種情況：

# Ensure clean working directory
$ git stash

# Create new branch at master
$ git branch some-descriptive-name master

# Move master back one commit
$ git checkout master
$ git reset --hard HEAD^

# Merge the new branch into master
$ git merge --no-ff some-descriptive-name

# Forcibly update master
#   YOU SHOULD COMMUNICATE WITH OTHER DEVS BEFORE DOING THIS
$ git push -f origin master

# Merge the new branch into feature
$ git checkout feature
$ git merge --no-ff some-descriptive-name

我無法強調良好的溝通是多么有價值，因為這些“哎呀”的事情可以並且確實一直在發生。

祝好運！

編輯：

關於cherry-pick的部分是在假設只有少數提交（或只是一個）被master的情況下編寫的，並且它們都是cherry-pick 。

x -- y (master)
 \
  a -- b -- c (feature)

Answer 3

第三個開發人員不應該在master上編寫一個功能。 罕見的例外是修補程序。 但即使這樣，它應該是它自己的分支然后與--no-ff合並到master上。 我在這里寫了一篇關於每個功能分支的長篇文章： http ： //dymitruk.com/blog/2012/02/05/branch-per-feature/