2016-09-28 22 views
2

我正在尋找一種方法來使用主題分支來創建功能開發的詳細歷史記錄(和進行中的備份),並將合併提交使用到主數據上作爲功能添加的摘要描述。那麼好吧在你的合併中使用--no-ff這兩個方向,這就是你得到的,正確的。當您嘗試推送並發現其他人已將更改推送給主人時,會出現問題。如何讓git第一個父母一致而無需重新綁定?

從我已經找到了自己在這一點上的選項是(a)重訂本地主副本「過度」這些其他的變化或(b)這些修改合併到本地主副本,然後推。選項(a)重新定義有點繁瑣,並以一種模糊事件順序的方式重寫歷史。選項(B),正常的合併,導致歷史圖形,遮蔽特性分支的身份與該「主線」(具體git log --first-parent並非指什麼一直是上游主的頭)。

我想避免這兩個結果,我認爲只需要一個小的(預測的)變化。我認爲問題只在於git將當前分支設置爲合併的第一個父代。合併兩個本地分支時,這是有道理的。但是,將當前上游分支合併到本地時,這是倒退的。那麼如何知道它是上游分支?那麼跟蹤分支是什麼,對不對?您甚至可以使用名爲--set-upstream的選項來分配它們。

所以......

  1. 我錯了是交換父母的順序合併跟蹤分支將給人乾淨的歷史的時候,還是我失去了一些有關如何跟蹤分支是使用?
  2. 怎會力混帳使用源科作爲合併的第一父,如果它是當前本地分支跟蹤分支(的方式,被分配到回購的克隆)?

編輯

我最初的出發情況下這個問題不是一個明確的主題分支,而是一個提交代表半平凡的變化仍然值得分享回「主線」。我希望這個解決方案能夠擴展到作爲多個步驟開發的變更集(一個實際的主題分支),而且這個案例似乎更清楚地描述了這個意圖,所以我用它作爲描述。不幸的是,合併的創建提交前推,事情就更難辦發現衝突(如迅速指出了@克里斯)。

對於這個更簡單的情況,我仍然對(1)和(2)的答案感興趣(並且將編輯問題,如果可以解決更簡單的問題,並且我會計算出如何給已經有問題的人回答)。

+0

你的問題並不完全清楚,但重新合併和合並是Git AFAIK中唯一的兩個主要工作流程。 –

回答

1

可以中止合併和新master重做。假設你是master和你的合併的推動只是失敗了,你可以這樣做:

$ git reset --hard origin/master # reset to newly-fetched master 
$ git merge topic_branch   # redo the merge 
$ git push origin HEAD   # re-push the merge 

如果有在初始合併然後沒什麼大不了沒有衝突。不過,您需要重做這項工作。爲了避免這種乏味,請參見git rerere

爲了您的具體問題:

  1. 是,合併初期的合併(你的master版本未能推)到新獲取的master比在其他方向上合併清潔劑,但它仍然介紹毫無意義的合併。重新合併使得歷史更清晰。
  2. git merge合併到當前分支,所以只需簽出你想成爲第一個父母。爲避免拒絕推送,請確保在合併之前從master中提取。
+0

我確實認爲,從上游跟蹤分支合併時,顛倒父母的順序會改善歷史的清晰度,並改善git的可用性。但@Chris指出,這並不能解決合併主題分支後提交失敗的難題。 – SensorSmith

相關問題