1
我的問題不是很清楚（但）我可能需要您的反饋更加明白我真正需要的...用什麼平滑的Git工作流程從開發到發佈？
無論如何，我讀了很多有關git-flow和其他流量使用上的Git對於如何解決我的情況我仍然存在分歧。
我目前有一個master分支，演變爲開發和發佈。這主要是因爲所有的歷史都是從我們以前的SCM導入的。我們還在每個版本中放置了一個tag。
今天我們開始一個發佈過程。通過我們唯一的主分支，我們被迫凍結開發直到發佈完成。或者，我們可以：
- 從
master創建一個rc分支，其中應用了熱修復。最終在release分支上合併rc，然後對其應用標籤。 - 從
master創建一個develop分支，然後使用master作爲rc分支。最終在master上應用tag，並繼續以develop作爲主要開發分支。
對於解決方案（1），在第一個版本上創建分支然後將所有下一個版本合併到它的問題是開放的。此外，標籤也應該移動，這可能會造成混淆。
通過解決方案（2），master被認爲是發佈分支，而不是開發分支，因爲它應該是。
我並不真正相信git-flow會增加一些複雜性。我希望master分支保持項目的中繼，但在這種情況下，我不知道哪種解決方案最適合。
使用案例：
我有這個混帳日誌從中我想開始釋放驗證過程。
* some changes
* v1.1.1 [v1.1.1]
* hotfix
* v1.1 [v1.1]
* merged feature foo into master
* changes
* v1.0 [v1.0]
第一個解決方案是保持master開發分支，然後創建一個release/v1.2rc分支
* v1.2 [v1.2] (release/releases)
| * merge next feature to master (master)
* | changing version rc to release (release/v1.2rc)
| * merged hotfix
|/|
* | hotfix
|/
* some changes
* v1.1.1 [v1.1.1]
* hotfix
* v1.1 [v1.1]
* merged feature foo into master
* changes
* v1.0 [v1.0]
爲了讓所有排放到release/releases分支，它會做從工作是有益的開頭：
* v1.2 [v1.2] (release/releases)
/|
/|
/* | merge next feature to master (master)
* | | changing version rc to release (release/v1.2rc)
| * | merged hotfix
|/| |
* | | hotfix
|//
* * v1.1.1 [v1.1.1]
*/| some changes
* | v1.1.1
| * v1.1 [v1.1]
*/| hotfix
* | v1.1
* | merged feature foo into master
* | changes
| * v1.0 [v1.0]
*/
* v1.0
這樣做git log release/releases
* v1.2 [v1.2] (release/releases)
* v1.1.1 [v1.1.1]
* v1.1 [v1.1]
* v1.0 [v1.0]
但是，通過在單獨的分支上移動標籤和發佈，我們在master上的可見性變得很差。此外，在之前版本，即 v1.1上進行錯誤更正修正。2是不容易的，並在這一天結束時，我們得到一個非常令人不安release/releases日誌：
* v1.1.2 hotfix [v1.1.2]
* v1.2 [v1.2] (release/releases)
* v1.1.1 [v1.1.1]
* v1.1 [v1.1]
* v1.0 [v1.0]