[GIT实践]git实践系列之-- 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/**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机制开发的评审功能,有兴趣的同学可以关注百度效率云公众号了解产品更多信息:

百度效率云入口: 请点击这里


百度效率云官方公众号

 

收藏 评论(2)
分享到:
共2条回复 最后由筱Myselfkv 回复于2019-09-06 09:46
#2 乐观的徐小小 回复于2019-09-02

棒棒哒

0
#3 筱Myselfkv 回复于2019-09-06

0