[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
以上是 [GIT实践]git实践系列之refs/for/branch和refs/head/branch 的全部内容， 来源链接： utcz.com/z/509622.html
