[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: