2012-10-22 55 views
0

我正在一個小團隊中使用Git/Gerrit作爲源代碼控制/代碼審查。
當團隊中的開發人員想要提交他們的工作時,他們會投入/推動gerrit並開始研究新功能。
此外,鼓勵開發人員儘可能地推動他們的工作,他們通常在已提交的變更(通過挑選相關更改)上進行工作,這些變更目前正在審查中。如何將未更改的補丁集推送到gerrit並避免創建新版本?

問題是,當開發人員嘗試推動更改時,他們也會推動更改的歷史記錄。作爲副作用,這些更改會得到新版本,與以前版本的相同更改沒有區別。此外,開發人員現在必須獲得'僞造'許可(假設某些挑選的更改不是他的)

例如: 假設Adam的一個分支的歷史看起來像這樣(更高的變化是最新):

更改3(作者:亞當,目前在工作)
變化2(Ahthor:查理)
變化1(作者:巴斯)

現在,改變了1,2從gerrit挑選櫻桃,並沒有改變。
當亞當推他的補丁,他必須能夠建立在變化1,2提交者,他們得到新版本(沒有從以前的推任何區別)

可有人請告知如何避免這種情況?我們做錯了什麼?

謝謝!

回答

1

格里特創造這些補丁集的新版本,因爲有變化 - 當開發商櫻桃採摘爲up的變化審查,修改git提交。現在提交具有不同的父級和不同的SHA1。

有2種方法來避免這種情況:

  1. 花時間來正確檢查/檢驗/合併仍在審查做更多的工作在他們頂部
  2. 不是cherry-之前改變在本地選擇更改,使用結帳。這將保持現有的補丁集保持不變,所以任何提交上的提交都會正常上傳,而不會修改現有的補丁集。但是,這會將您在存儲庫中的位置移動到創建補丁集時的位置 - 您將不會提交自該補丁集上傳以來已合併的任何提交。

在dayjob,我們根據情況使用這兩種方法的組合。祝你好運!

+0

如果在我想要提交我的更改的TOP上有兩個gerrit更改會怎麼樣?結賬會在這種情況下工作嗎?有沒有其他解決方法? – mrutyunjay

+0

在這種情況下,結帳通常是一個很好的解決方案。 – Brad

1

我們公司有類似的問題。 Gerrit附帶一個腳本,您應該將其添加到您的本地存儲庫(它在Windows,Mac和Linux下工作)。它在向本地存儲庫提交時會自動運行,並生成一個提交ID(在提交消息的末尾添加它)。

如果稍後提交的SHA1發生更改(例如由於修改),Gerrit將看到它是相同的提交,並且不會創建新的入口點,它只會在提交時更新文件仍在審查中。

要複製腳本到你的資料庫並執行以下操作:

scp -p -P 29418 [email protected]:hooks/commit-msg .git/hooks/ 
相關問題