[GIT實踐]git實踐系列之-- refs/for/branch和refs/head/branch

本文做者：francisk84

git的誕生歷史 -- 摘選自《Pro git》

Linux 內核開源項目有着爲數衆多的參與者。 絕大多數的 Linux 內核維護工做都花在了提交補丁和保存歸檔的繁雜事務上（1991－2002年間）。 到 2002 年，整個項目組開始啓用一個專有的分佈式版本控制系統 BitKeeper 來管理和維護代碼。

到了 2005 年，開發 BitKeeper 的商業公司同 Linux 內核開源社區的合做關係結束，他們收回了 Linux 內核社區無償使用 BitKeeper 的權力。 這就迫使 Linux 開源社區（特別是 Linux 的締造者 Linus Torvalds）基於使用 BitKeeper 時的經驗教訓，開發出本身的版本系統。 他們對新的系統制訂了若干目標：

1. 速度 

2. 簡單的設計

3. 對非線性開發模式的強力支持（容許成千上萬個並行開發的分支） 

4. 徹底分佈式 

5. 有能力高效管理相似 Linux 內核同樣的超大規模項目（速度和數據量）

git push時的refs/for/[branch_name]和refs/head/[branch_name]

談到git push時的refs/for/[branch_name]指令，其實它是Gerrit工具的一種機制。簡單的說，Gerrit爲了保證每次代碼提交都強制開啓代碼評審,要求研發人員在提交代碼的時候統一使用:

git push [REPO_NAME] HEAD:refs/for/[BRANCH_NAME]

在Gerrit的官方文檔裏是這麼描述的:

Gerrit uses the**refs/for/**prefix to map the concept of 「Pushing for Review」 to the git protocol.

也許有人會問說，若是我每次都是向同一個分支push代碼，那麼Gerrit怎麼知道我每次提交的diff呢？下面還有解釋:

For the git client, it looks like every push goes to the same branch, such as refs/for/master. In fact, for each commit pushed to this ref, Gerrit creates a new ref under a refs/changes/ namespace, which Gerrit uses to track these commits. These references use the following format:

refs/changes/[CD]/[ABCD]/[EF]

Where:

[CD] is the last two digits of the change number

[ABCD] is the change number

[EF] is the patch set number

For example:refs/changes/20/884120/1

也就是說，Gerrit在服務端已經保存了你每次的changeID, pachset。

那麼，再來講說refs/head/[BRANCH_NAME]，和前面對應的，這條命令的意思就是提交代碼，可是不開啓代碼評審。對於一部分開啓了強制代碼評審的工具來講，研發人員在本地提交代碼時會報錯。以百度效率雲的代碼管理icode爲例:

1. 代碼提交時執行refs/for/branch:

refs/for/branch提交

此時在iCode評審界面會看到一條新的評審，此時這部分代碼還未入庫,所以評審狀態屬於開發中

 

2. 代碼提交時執行refs/head/branch:

執行refs/head/branch

從最後一行能夠看到，本次提交被Gerrit禁止了，進入到iCode評審界面,咱們發現剛纔的提交併無生效

 

總結: 對於那些但願將Code Review粒度控制在單次提交級別的研發團隊，使用基於Gerrit機制的工具是比較合適的。而百度效率雲的iCode，正是基於Gerrit機制開發的評審功能，有興趣的同窗能夠關注百度效率雲公衆號瞭解產品更多信息:

百度效率雲入口: 請點擊這裏

百度效率雲官方公衆號

 

原文連接地址：https://developer.baidu.com/topic/show/290277