我有一個小小的項目,用Git維護它的版本控制。 這裏的術語版本控制指的是你可以想象到的最簡單的形式: 只在主分支上並且在一天結束時產生提交,將所有提交推送到遠程。 目前爲止這麼好。只需要一個主分支就足夠了,因爲應用程序的最新狀態一直都是需要的。如何使用git發佈版本控制版本
然後,採購員告訴我他們需要v1.1和v1.2。問題是最新的主提交包含v1.1的所有內容,以及v1.2的一些撤消內容。
我的第一意圖是找到兩個'功能包'分歧的基礎提交。 我從那個提交創建了兩個分支,我開始逐個挑選基礎上的提交。幸運的是,其中並沒有太多。 這導致兩個分支(V1.1和V1.2)保持在適當的合適的東西,除了我,因爲在1.1版的功能還需要在V1.2變基V1.2到V1.1
這一切後,我有以下病史:
正如你所看到的,我有一個「懸」分支,它是主,其實,我並不需要這些提交,因爲所有的他們被挑選到正確的地方。
問題簡單的是:如何優雅地處理這種情況(基本上除去那些不必要的提交)而不會造成任何傷害,或者有沒有其他辦法可以達到同樣的效果?
Mercurial VCS項目使用一個單獨的'stable'分支,其中用於下一發行版本的所有提交都合併到該分支中。任何旨在用於發佈版本的修補程序都將被提交給該「穩定」分支,並最終被合併到主幹(或「默認」分支)中。所有新的,可能是後向不兼容的變化都被轉移到主幹上。 (請注意:我*不*建議使用汞;我通知用戶部分他們的工作流程如何。) – Isxek