我正在尋找一種方法來使用主題分支來創建功能開發的詳細歷史記錄(和進行中的備份),並將合併提交使用到主數據上作爲功能添加的摘要描述。那麼好吧在你的合併中使用--no-ff
這兩個方向,這就是你得到的,正確的。當您嘗試推送並發現其他人已將更改推送給主人時,會出現問題。如何讓git第一個父母一致而無需重新綁定?
從我已經找到了自己在這一點上的選項是(a)重訂本地主副本「過度」這些其他的變化或(b)這些修改合併到本地主副本,然後推。選項(a)重新定義有點繁瑣,並以一種模糊事件順序的方式重寫歷史。選項(B),正常的合併,導致歷史圖形,遮蔽特性分支的身份與該「主線」(具體git log --first-parent
並非指什麼一直是上游主的頭)。
我想避免這兩個結果,我認爲只需要一個小的(預測的)變化。我認爲問題只在於git將當前分支設置爲合併的第一個父代。合併兩個本地分支時,這是有道理的。但是,將當前上游分支合併到本地時,這是倒退的。那麼如何知道它是上游分支?那麼跟蹤分支是什麼,對不對?您甚至可以使用名爲--set-upstream
的選項來分配它們。
所以......
- 我錯了是交換父母的順序合併跟蹤分支將給人乾淨的歷史的時候,還是我失去了一些有關如何跟蹤分支是使用?
- 怎會力混帳使用源科作爲合併的第一父,如果它是當前本地分支跟蹤分支(的方式,被分配到回購的克隆)?
編輯
我最初的出發情況下這個問題不是一個明確的主題分支,而是一個提交代表半平凡的變化仍然值得分享回「主線」。我希望這個解決方案能夠擴展到作爲多個步驟開發的變更集(一個實際的主題分支),而且這個案例似乎更清楚地描述了這個意圖,所以我用它作爲描述。不幸的是,合併的創建提交前推,事情就更難辦發現衝突(如迅速指出了@克里斯)。
對於這個更簡單的情況,我仍然對(1)和(2)的答案感興趣(並且將編輯問題,如果可以解決更簡單的問題,並且我會計算出如何給已經有問題的人回答)。
你的問題並不完全清楚,但重新合併和合並是Git AFAIK中唯一的兩個主要工作流程。 –