[GIT实践]如何开启一个团队的CR机制-refs/for/branch和refs/head/branch

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/*pr