2013-07-11 28 views
2

我在我的團隊中使用Phabricator和Arcanist進行代碼審查。 「弧地」命令非常棒,但有一種情況對我們不起作用。我們有一個單獨的xml文件,其中包含一個鏈接列表(每個元素指向一個前一個元素)。我們不會經常更改這個文件,但偶爾我們會做。如果兩個人在同一時間進行更改發生「無聲的衝突」,意味着鏈接列表被破壞,因爲這兩個新元素鏈接到相同的前一個元素。這不是很難解決。但是git沒有引發合併衝突。Phabricator奧術師弧地vs弧修正

所以當我們運行弧地,不正確的xml文件被自動推送。我們不希望這樣。

會正確的動作是使用弧形修改,然後解決衝突手動後跟一個混帳推(像我們今天這樣做,沒有任何麻煩),或者你會如何建議與此前進?

回答

7

一些可能的想法:

  • 可以arc land --hold停止運行的git push之前,檢查更改,然後手動運行git push
  • 在Git允許提交之前,您可以添加一個本地Git預提交鉤子來驗證XML文件。
  • 您可以在服務器上添加一個預接收掛鉤,以在將XML文件推送到遠程設備之前對其進行驗證。
  • 您可以使用gitattributes中的merge指令覆蓋Git的合併行爲,並將默認合併替換爲正確合併(或無法合併)的合併行爲。
  • 您可以嘗試用某種格式的數據替換XML文件,該格式不具有這些不合意的合併屬性,因爲此問題是一般性問題。
  • 您可以通過在文件中包含一些始終發生衝突的字符串來強制合併失敗。例如,像lastNode="whatever"新增屬性的容器元素(即,總是在1號線或其他),這樣兩個編輯將被命名不同的最後節點(以確保這是編輯在該行總是衝突,你可以檢查在運行時lastNode是正確的)。如果文件是自動生成的,你可以簡單地在一個衆所周知的線上發表評論。
+0

太棒了! 「arc land --hold」現在是有意義的。預先接收的鉤子(太多不同的本地設置依賴於預提交鉤子),驗證XML文件是合乎邏輯的下一步驟。這從來沒有成爲一個大問題,因爲該文件是手動編輯,即使是新員工也無需任何介紹即可輕鬆理解和修復。但是在弧形的土地上,我看到人們忘記了這一點。 –