Git 大家用 git rebase 频繁吗？
比如两个人工作在一个特性分支上，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 就好了，没有遇到问题
个人感觉这个要看你在做的事情值不值得单独分一个 branch 出来 如果都在解决同样的问题，就做成一条直线比较清晰 如果是在做新功能里面的一个独立的小功能，就分支出来
pull 时想要不出现 merge commit，只要保证 master 始终与代码库中是 fast-forward 的即可。 本地分支开发完后，切换到 master 分支 pull 代码库 (已经其他人的提交)，然后在切换到本地分支 rebase，最后再 merge 回 master 分支，push。 如果是两个人同时在一个特性分支上开发，道理一样。
我的看法是，如果是比较小规模的合并，比如只有几个 commit 的，就用 rebase，反之则用 merge，并显式指定 --no-ff。这样主分支的时间线会比较清晰
开发 | 特性 1 | 特性 2
左边是开发分支，中间是特性分支 1，右边是特性分支 2。特性分支 1 和 2 都是 3 个 commit，1 进行了 rebase 清理，是线性的，2 没有清理，代码审阅的时候就会很别扭。
#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 ...
将分支划分为两类：主干（dev/master）和功能（featureXX）
不同开发人员之间通过主干分支交换代码。比如我写了 featureA，另一个人在写 featureB，如果他依赖我在 featureA 里新写的代码，必须按照以下流程合并进度：
- 我 git merge featureA 到 dev，然后
- 另一个开发者在 featureB 分支执行 git rebase dev
- featureB 完成之后再 git merge featureB 到 dev
跟 11 楼的比较相似。
#12 楼 @Rei 我们团队就是按照这个作为 git 的开发统一约定 http://nvie.com/posts/a-successful-git-branching-model/
git flow 的分支策略可以减少 git rebase 的使用，个人认为，git pull --rebase 是必须的用法，合并分支就用 git-flow 就可以了，不用太在意细节。
git rebase 的强大功能就是改写历史 rebase -i 可以做很多事。
