Git 大家用 git rebase 频繁吗?

Rei · 发布于 2011年11月22日 · 最后由 chengcheng222e 回复于 2016年1月09日 · 25543 次阅读
1

比如两个人工作在一个特性分支上,push 的时候出现冲突,那么要用

git pull

还是

git pull --rebase

呢?

我个人是偏好 pull --rebase,因为这样可以得到一个线性的特性分支,虽然丢失了并行开发的信息,而且 commit 较多的话解决冲突会变麻烦(解决方案是频繁 rebase && push)。

保持线性的特性分支,查阅很多资料都只看见“管理者的喜好”这样的描述,而没有描述优缺点。不知道大家怎么看?

共收到 19 条回复
2

基本没用过,我们都是这样的 master 用于发布 devel 用户主要开发点 新功能,开个功能名的分支,这个分支不 push,写好后:

(my_branch) $ git add .
(my_branch) $ git commit -m "..."
(my_branch) $ git checkout devel
(devel) $ git pull origin devel
(devel) $ git merge my_branch 
(devel) $ git push origin devel

自己合并到 devel 分支,合并只是简单的 merge 就好了,没有遇到问题

1

#1楼 @huacnlee 我这因为一个新功能可能要开发2周,要两个人协作,所以需要经常push到代码库备份。而这两个人如果经常 pull 的话,就会出现很多

Merge branch 'aaa' of git.xxx.xxx/xxx/xxx into aaa

这样的 merge commit,这些 commit 在审阅代码的时候很干扰,如果 pull 得频繁就会变成波浪状

96

个人感觉这个要看你在做的事情值不值得单独分一个branch出来 如果都在解决同样的问题,就做成一条直线比较清晰 如果是在做新功能里面的一个独立的小功能,就分支出来

2

#2楼 @Rei 我们这边现在3个人同时开发,其实大部分时间都是在同一个分支上面开发的,感觉这样也没问题

96

#2楼 @Rei 用fetch 下来以后手动合并或者重新checkout -B 丢弃本地分支, 我总觉得pull 容易出问题

79

pull时想要不出现merge commit,只要保证master始终与代码库中是fast-forward的即可。 本地分支开发完后,切换到master分支pull代码库(已经其他人的提交),然后在切换到本地分支rebase,最后再merge回master分支,push。 如果是两个人同时在一个特性分支上开发,道理一样。

96

我的看法是,如果是比较小规模的合并,比如只有几个commit的,就用 rebase,反之则用 merge,并显式指定 --no-ff。这样主分支的时间线会比较清晰

#2楼 @Rei 不明白保持线性的提交记录有什么意义?

1

#7楼 @iwinux 主要是好看

[img]http://k.minus.com/jukgulxeeUpWK.png/img][

开发 | 特性1 | 特性2

左边是开发分支,中间是特性分支1,右边是特性分支2。特性分支1和2都是3个commit,1进行了rebase清理,是线性的,2没有清理,代码审阅的时候就会很别扭。

77

#8楼 @Rei 我同意@iwinux 的说法,我和他合作时一直是这么做的

一开始时我也喜欢总是用rebase,后来发觉过份追求线性提交记录有没必要的,保留merge信息更容易code review

1

#9楼 @HungYuHei 我遇到个现实问题。之前检查到一个5月份的代码有bug,已经知道它的commit是哪一个,接着要检查它什么时候进入master(线上运行),以进行数据恢复。

然后检查的途中一直在 merge preview of xxx to preview 这样的合并中左拐右拐,非常干扰,想直接找到到达特性分支合并到master的时刻,这时候线性分支就好找了。

96

这样的 network 最漂亮: 同分支总是 git pull --rebase origin xxx, 合并分支总是 git merge --no-ff xxx 禁止 rebase

柱子之前还向我推销 grb 的 pull 可以少打 rebase ...

1

#11楼 @night_song 我就是要这个!

96

#8楼 @Rei 我觉得是一开始没有协调好……

将分支划分为两类:主干(dev/master)和功能(featureXX)

不同开发人员之间通过主干分支交换代码。比如我写了 featureA,另一个人在写 featureB,如果他依赖我在 featureA 里新写的代码,必须按照以下流程合并进度:

  1. 我 git merge featureA 到 dev,然后
  2. 另一个开发者在 featureB 分支执行 git rebase dev
  3. featureB 完成之后再 git merge featureB 到 dev

跟 11 楼的比较相似。

77

#12楼 @Rei 我们团队就是按照这个作为git的开发统一约定 http://nvie.com/posts/a-successful-git-branching-model/

96

基本只用 git rebase master 其他时候都merge

96

其实git rebase的另一个强大功能在于改写历史。

96

git flow的分支策略可以减少git rebase的使用,个人认为,git pull --rebase是必须的用法,合并分支就用git-flow就可以了,不用太在意细节。

git rebase的强大功能就是改写历史 rebase -i可以做很多事。

90

#8楼 @Rei 呃...表示和同事讨论结果也被用好看来搪塞.. 结果没法继续讨论下去.. 我从前的 Git 使用流程, 追踪坏代码仅仅通过线性的 commit history 的 blame 来查找, 相对来说, "好看"带来的好处远不如放任随意 merge 来得好, 除非对于历史的管理和追踪真的精确到了什么地步... 难以理解啊

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册