我試圖找出造成這種情況的正確的工作流程：更正共享功能分支的Git工作流程？
在共享回購，我們對這些分支：
-master
-feature
的功能分支是共享分支，因爲許多開發人員正在共同研究一項新功能。他們正在積極推動他們對功能分支的改變。
我試圖避免「衝突地獄」的那一天功能終於被合併到主。目前，我看到一些選項：
1）積極合併主到功能，並且經常這樣做。但是，這不是建議在git文檔中，我開始明白爲什麼。當我嘗試這個時，我似乎一次又一次地解決了同樣的衝突。
2）以某種方式使用rebase。我已經讀過這個，但它看起來像不會工作，因爲功能分支實際上是共享的。所需要的只是一個開發人員進行2次rebase，而其他開發人員可能會因不匹配的歷史記錄而產生衝突。
3）打開功能分支到集成分支，並有開發者使用自己獨立的特性分支與墊底讓事情變得理智。
4）完全不同的東西？
對於共享分支，我將使用＃3，並將其用作「集成」分支來鞏固其工作。
開發商將不得不使用重訂其工作合併回feature之前不斷重播上的feature頂部的private分支，這樣，它們分別是：
private分支feature）（如"git rebase vs. merge"答案描述）是小事一樁（通常快進）這個想法是，一旦feature分支必須在master中合併，feature（該分支「凍結」）上不再接受任何貢獻，並且您可以首先安全地將其重新分配在master之上，或者合併它直接到master。
，然後你開始一個新的分支feature（如果需要的話，可以真正開始在以前feature分支的平行）
您可以使用rerere來處理多次看到的合併衝突。
（我不是選項1，2或3所以我想太熱衷找到一個更好的工作流程，所以我下面的描述我是如何在想，希望有人接近問題會勸我）
人們可能會明智地將修補程序隊列返回到本地功能分支。
GIT中的工作流程特徵分支
的過程是如下： -
第一次：
git pull
git checkout -b sprint-4
git pull origin sprint-4
上述命令將p所有來自git的文件
將在我們的本地機器上創建名稱爲sprint-4的分支。
將文件從服務器拉到我們的sprint-4分支。
對於每一個新功能： -
git checkout -b <feature-branch>, example: git checkout -n fer-181
git push -u origin <local-branch>:<remote-branch>, example git push -u
origin fer-181:fer-181
日報：（您的特性分支）
git pull
git merge dev
做你的工作了一天
混帳推起源
功能非常齊全：如有
git checkout dev
git merge <feature-branch>
git push origin dev
git pull
git merge dev
你最終會遇到不可用的歷史記錄 – sherpya 2015-10-04 16:39:09
我認爲開發通常應該發生在每個開發者分支上，並且共享分支通常應該僅用於集成是一個很好的經驗法則。 – 2010-09-29 07:22:15
我不太熟悉rebasing，所以我會問這個問題：在這種情況下，用戶是否會將他們的私人分支合併到功能中一次（並且如果他們需要做更多工作，則創建一個新的專用分支），還是安全的讓他們多次合併以及他們正在進行的重組？ – Ben 2010-09-29 16:46:00
@讓本地重新定義的想法正是爲了允許多重合並：因爲你永遠不會發布你的'私人'分支，你可以在將你的工作合併到'features'並推送它之前重新定義它。也就是說，如果給定的開發工作在一個給定的「私人」分支上完成，最好做一個新的開發，而不是試圖重用現有的開發。當地的歷史會更清晰。 – VonC 2010-09-29 17:11:24