问题描述
git整合分支一般有两种方法——变基操作(git rebase)和合并操作(git merge)，但是在你们实际的团队开发中，哪种方式用的最多，或者你们觉得那个好呢？
问题解答
回答1：我猜现实中的情况是这样的：
使用 git 的人群中，不会用 rebase（哪怕是基础功能的）的至少一半（这个估计恐怕很保守了）
剩下一半里真正理解何时应该正确 rebase 的恐怕也就一半……
merge 还是 rebase 并不是一个二者选其一的问题，而是应该根据具体情况来选择使用，而这个“具体情况”在现实中实在是不好一一列举出来了，对于大多数开发者来说在团队中的职能比较单一，也不是经常有机会遇到，所以在这里我只总结两个人人都应该理解并遵守的准则：
当你从 remote 去 pull 的时候，永远使用 rebase（除了一个例外，后面会讲）
当你完成了一个功能（假定你是单独开本地分支去做的）后打算合并到主干分支的时候，永远使用 merge
开发者应当理解：不同的合并策略影响的或许不是最终的代码结果，但却会影响 git 如何记录提交的历史（尽管很多时候这种理解只对个别人受益，而对自己没有什么影响）。其他的人在使用这些历史的时候（比如 code review 的时候，或者 bisect 的时候等等）会因为过去你做过的事情而感到无比幸福或痛苦。
第二点比较容易理解，把开发一个功能的具体细节隐藏在本地分支中，而把最终的结果作为一条完整的记录合并（merge）到主干分支去。
关键是第一点。大多数情况下大家会选择默认的 pull，也就是 fetch + merge，于是我们会看到主干上不停的出现 Merge commit xxx into xxx 之类的干扰信息。如果所有的人都图方便这么干，那就永远都别想有干净漂亮的历史树了，取而代之是类似这样的东西：
如果你去 clone 一个正确使用 git 的项目，你绝对不会看到上图这样乱七八糟的 master。为什么呢？答案就是：git pull --rebase，这条命令会使用 rebase 来代替默认的 pull 对合并的历史树进行变基处理，就可以避免因为无法快进（fast forward）而产生的额外合并记录。
现在绝大多数的 git 客户端都允许设置 git pull 的默认行为是 --rebase，所以掌握了这个诀窍可以让大部分的日常拉取操作都产生清爽漂亮的历史记录，但这并不是完美的结局。有一种例外是这样的：
在你使用 git merge 完成了一个功能分支向主干分支的合并之后（当然是 --no-ff 的）
在你运行 git fetch 发现远程主干又领先你若干提交
此时你若 git pull --rebase，你会发现你刚才合并功能分支的记录没了……
这是因为变基会忽略合并记录，因此变基命令会有一个特别的参数叫做：--preserve-merges 用于重建被忽略的合并记录。所以比 git pull --rebase 更好的方案就是用 git fetch + git rebase -p 代替之。
当然这个仅针对上面提到的特殊情况，随着 git 的升级说不好哪一天就不存在这种问题了也不一定。我一般都不会遇到这种情况，因为我都是这么做的：
完成功能分支之后先不 merge，而是回到主干分支去 git pull --rebase
如果主干有更新，rebase 更新的内容到功能分支来预检一下，看看在加入了最近别人的改动之后我的功能是否依然 OK（在这个过程中可能会有冲突处理，别怪我没提醒哦）
一切就绪之后再次 git fetch 主干看看有没有变动（因为在第二步的进行期间没准又有人 push 了新的变化），有的话重复第二步，没有则——
合并功能分支到主干然后 push，收工。
我这么做可以避免前面提到的意外，看似复杂了些但其实做熟练了之后也没什么难度，更重要的原因是 git rebase -p 是有缺陷的：
不能和 git pull 连用，一条命令分成俩，怎么都觉得“亏”了（虽说你可以写脚本，但最好不要因为习惯了之后反而有时候会害了你）
由于无法和 git pull 配合使用，所以你必须指明目标分支给 rebase，这一点比较烦人，特别是很多 GUI 客户端压根不支持 git rebase -p 的时候（我经常会在 CLI／GUI 之间切换环境使用 git）
ORIG_HEAD 会被破坏。
ORIG_HEAD 在很多情形下非常有用，比如说你可以用 git log -p -reverse ORIG_HEAD 来回看最近一次合并所产生的所有变化等等。--preserve-merges 会让它失去本来应该指向的位置，你不得不先找到正确的 hash 来代替它，这会有点烦。
以上答案最终说明一件事情，现实的复杂性永远超出你在菜鸟时期所能做出的想象，真想把 git 用好那就要在日常工作的基础上好好理解 git 的工作原理吧，可以去看官方网站电子书（中文版），里面的 git internal 一节仔细看懂之后，该用什么命令心里就有数了。
补充一点：如果你的团队不在乎主干分支上有很多不重要的干扰提交记录，那你可以始终使用 rebase，这样至少可以不会出现很多分岔，处理得当也可以得到干净（但是啰嗦）的主干分支历史记录。
回答2：不強制, 但是要求push後所有測試是綠的
(我們沒有特別長的分支, 大部分在2-3天內合併, 很少超過一周)
一般是大家根據merge難度自己選, 沒差別時優先rebase... 因為好看一點
