我的上一家公司用Github管理代码。每个人在实现一个新功能的时候都会开一个featurebranch，做完就提交pullrequest，代码审核完之后就merge到develop分支。这是一组标准动

蛋先生：那就聊聊 git merge 吧。丹尼尔：git merge 我倒是经常用，不过却从未关心过它内部是怎么实现的。那你跟我讲一下它的工作原理呗。

diff 是我们每天都要使用的一个功能，每次提交时，我都习惯先用 git diff --cached 看看这次提交更改了些什么，确定没问题，然后再 git commit。git 生成的 diff 非常直观，直观到我从来都没有去思考过 diff 是怎么生成的，觉得这应该是很简单的一件事，两个文件做个对比，不就行了。

我闯过，我闯的第一个祸就是使用git rebase造成的，虽然后来最终还是解决了，但是还是给我吓得不轻。当时的事情是这样的。 简单解释一下这张图当中的内容，C1节点是所有分支的最小公共祖先。可以理解成是最早的master版本，之后我们checkout出来了两个分支，分别是bug…

实际开发工作的时候，我们都是在自己的分支开发，然后将自己的分合并到主分支，那合并分支用2种操作，这2种操作有什么区别呢？ git上新建一个项目，默认是有master分支的，将项目克隆到本地，我们的准备