2015-11-13 137 views
1

我已經用我們的git項目讓自己變成了一個泡菜。我們被迫(通過情況)將團隊分成兩個陣線,一個陣營正在進行大規模的升級/檢修任務,另一個隊伍正在研究上一版本(這是分支機構分裂的地方)上的功能/錯誤修正,共享git文件衝突

麻煩的是,這是六個月前。現在,功能團隊已經完成,而且我面臨着將這兩個包含六個月工作的兩個分支合併爲一個單一且具有凝聚力的狀態的難題。

不用說,有衝突......很多。幾乎400是具體的。我能夠通過重新綁定而不是簡單的合併來最大限度地減少混亂,這已經有了很大的幫助,特別是在將一個分支的修改後的文件移動到其他分支中的其他位置的情況下。有相當多的這些。

現在,雖然在大多數情況下衝突本身並不是特別難以解決,但我不能動搖這樣的感覺,即任何一個單獨的開發者都不應該爲這種衝突提供工作。

Git似乎並不是它在這個領域通常有用的自我。由於理想的git工作流程預計衝突會保持較小並及時處理,因此似乎沒有辦法與其他團隊共享合作努力。

這將是理想的。爲了能夠提交文件而不是剝離它們的衝突狀態。這樣,其他開發人員可以檢查正在進行的合併分支,並幫助消除他們各方的衝突,每個開發人員都會處理他們已經工作過的並且最熟悉的文件。

這似乎不可能,雖然...不是我能夠找到。

因此這個問題。有沒有人知道是否有辦法在不分期的情況下提交衝突的文件(從而將其標記爲技術上已解決,以後再難以找到)?

我希望能夠檢查出衝突的分支,看看那裏的衝突,並在有人遇到麻煩時幫助解決問題,或者在這種情況下幫助開發人員幫助他們等着我盡我所能完成解決衝突,沒有很多上下文信息繼續下去,所以他們以後可以進入並依靠合併提交消息中的衝突註釋來嘗試找出他們的工作可能具有的位置被覆蓋。

一如既往,非常感謝任何想法/想法/ brainfarts。任何事情都可以幫助,至少可以解除必須解決400個文件衝突的沮喪情緒。

乾杯


好吧,至少一個跟進,我能夠通過所有衝突對我自己的工作在這裏......花了公平幾個小時,但它得到了做。

然後,在我得到的(非常期望的)編譯錯誤的攻擊之後,我用diff工具(與另一個檢出到其中一個源分支的repo進行比較)檢查項目中的所有代碼文件,以及糾正了重組操作(以及隨後的衝突解決馬拉松)失敗的任何問題。

即順利到凌晨,但我設法終止與我的工作項目中的修訂項目資產的文件和它們的聯繫是編制了項目:)

今天的日子。這很簡單,遊戲看起來就像它的正常自我,所以絕望的程度按比例下降。如果有人知道共享一個大沖突操作的方式(一些提交方式不需要停止衝突狀態,或者可能是一種方法來檢索技術上已解決但仍然衝突的文件),那麼這將是最重要的歡迎信息,如果這(不寒而慄)在未來再次發生,給任何人。

感謝您的回覆!

乾杯

+0

祝你好運我的朋友。我對這樣一個漂亮的工具感到驚訝,有些人仍然遵循反模式。 Git manta「小變化頻繁合併/重組」 –

+0

這不是我們的選擇,相信我......我們被迫陷入了一種情況,我們分歧,或者一半的團隊會癱瘓。誠然,可能會有更頻繁的合併來保持健康,但沒有人希望檢修團隊能夠像我們那樣拖延許多延誤......而事後看來是一件美妙的事情,不是嗎? – HarvesteR

回答

0

你絕對可以提交已標記了由混帳作爲衝突是文件。我建議你創建一個新的分支,並將你當前的兩個分支合併到一個分支中。這樣,當您和您的隊友在第三個merge分支上解決問題時,人們可以繼續在當前分支上工作。

你是對的注意到,這是一個多人的問題。如果它是一個足夠大的項目,那麼通常會有團隊參與更改代碼的某些部分,因此這些人員將負責解決merge分支上代碼的這些部分中的合併衝突。

將所有內容合併後,您只需將開發切換至merge分支或將其合併回您的master分支。

+0

是的,我能夠'git commit -a'並推送衝突的文件,但是它們不會在'status'調用中顯示爲衝突(在團隊中的每個人都使用的smartgit客戶端上) 。 我能夠使用rebase而不是merge來最小化文件在被移動的一個分支中被視爲增加/移除的問題,並且在另一個分支上被修改。 – HarvesteR

+0

@HarvesteR我不明白你的發言的第二部分。至於第一個,一旦你添加並提交一個文件,git將不再將其標記爲衝突。這很正常。這就是爲什麼它應該在一個單獨的分支。這取決於你什麼時候將文件固定到'merge'/'rebase'然後回到'master' – houtanb