Git 大家用 git rebase 频繁吗?

Rei · November 22, 2011 · Last by chengcheng222e replied at January 09, 2016 · 31000 hits

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

git pull

还是

git pull --rebase

呢?

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

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

基本没用过,我们都是这样的 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 楼 @huacnlee 我这因为一个新功能可能要开发 2 周,要两个人协作,所以需要经常 push 到代码库备份。而这两个人如果经常 pull 的话,就会出现很多

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

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

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

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

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

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

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

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

#7 楼 @iwinux 主要是好看

开发 | 特性 1 | 特性 2

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

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

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

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

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

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

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

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

#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 楼的比较相似。

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

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

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

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

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

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

You need to Sign in before reply, if you don't have an account, please Sign up first.