Git的工作流程，不斷分出主，並釋放分支

Question

我做了很多的搜索這一點，我道歉，如果這是一種欺騙，我找不到直接解決了我的問題的任何答案。

我們有一個客戶，誰就會仔細考慮了一會兒一個功能，而這樣做將很快批准的另一特徵。

這意味着我們從主設備製作功能分支並將它們合併到一個QA環境中進行部署，這一切都很好，但是當功能2在功能1之前獲得批准後，我們​​需要將功能2合併到我們的發行版分支中特徵1的痕跡。

這聽起來不錯，但是這已經持續了一段時間，有大師和釋放之間的經常是不同的提交歷史。

我們試過了什麼;

1. 分支feature2從主和合並feature2分支到版本 - 這會導致過多的不必要的提交歷史記錄與它。
2. 將主合併到版本中。看問題1.歷史太多。
3. 從版本創建功能分支，而不是主控。理論上很好，但定期會有太多的衝突，使之成爲一個很好的選擇。
4. 櫻桃採摘。 Ergh。這是我們唯一能夠做到的事情，它對我們分歧的分支做出了貢獻。

有誰有這個建議的工作流程？

我想我們可以從主在發佈分支的分支點，但後來我想我們就會有同樣的問題如上2。

編輯

見下文（什麼樣的Git工作流程的適合我們的情況？）連接兩個 - 可能是「臨時」的分支可以部署到開發環境工作？

一些類似的討論;
What git branching models actually work?
What kind of Git workflow suits our case?

Answer 1

嘗試git merge --squash branchname(docs)。

它使整個分支進入一次提交，從而消除歷史問題。這可以讓你遵循一個模式，你擁有一個持久的主控和發佈分支，以及對彼此一無所知的瞬態特性分支。主人是功能從哪裏分出來和合併到哪裏，發佈分支是在設計發佈時合併主人的地方，而功能分支則是大部分開發發生的地方。當某個功能獲得批准後，它會與git merge --squash合併爲主，這會導致主控對整個功能進行一次提交。然後，如果需要，可以刪除功能分支。此外，如果該功能未被刪除，看起來它會繼續與主控人員愉快地合併，因此您甚至可以保持分支並獨立工作，定期使用git merge --squash將其合併到主控中，並且git merge將主人合併（保持最新狀態）。

如果更多的歷史重要，那麼你可以看看git rebase -i，在那裏你可以將一個功能分支合併到master中，然後用git rebase -i清理結果歷史記錄。按順序執行意味着功能分支仍然與其他地方一樣，而主分支還有一些額外的提交，代表功能分支上的開發。問這聽起來有趣，我會試着進一步解釋。

對於版本，然後你可以使用任何git merge --squash合併到發佈分支，這將保持更清潔，或者你可以拉高手（今限制）歷史進入釋放與git merge

這裏是混帳日誌可能會顯示爲生成的提交圖：

* d779567  master Done 
* 298c1c7  master Closer 
* 736d826  master Building 
| * 4657b01  fdab66dc33 Done! 
| * 3af011a  fdab66dc33 Closer... 
| * 6372833  fdab66dc33 Closer... 
| * d345a43  fdab66dc33 Building... 
| * 0b64509  fdab66dc33 Building... 
| * 9da143c  fdab66dc33 Building... 
| * c99dbce  fdab66dc33 Building... 
| * 501a25c  fdab66dc33 Building... 
| * 4f999ee  fdab66dc33 Building new feature 
|/ 
* e891881  master Work on master 
| * 3571493 release Releasing version 2! 
| |\ 
| |/ 
|/| 
* | 68f75f0  master Feature 1 done 
* | 5dbe17c  master Feature 2 done 
| * bbcc8e8  release Bugfix on current release 
|/ 
* d5732fd  release Work directly on master 
* 1098d81  release Initial commit 

從底部開始工作：完成了一些初始工作;發佈了一個版本，然後我們意識到我們需要修復一個bug。我們從他們的首發中獲得了兩個功能的反向批准，另一個發行版被刪除。然後一些工作直接發生在主人身上。現在事情變得更加混亂。右邊的分支（fdab66dc33實際上是分支名稱）是一個功能分支，它已經進行了很多提交。左邊的分支是主分支，而頂部的三個提交是合併特徵分支到其中的結果，然後使用git rebase -i壓縮一些特徵分支的提交。