我们借助sourcetree的树状图来进行讲解（git命令行查看树状图命令：git log --graph）
需求：把开发分支 develop 代码，合入到 master 分支
直接 sourcetree 从master分支上检出 develop 分支
merge
创建完分支后，分别在master分支和develop分支修改代码并提交。
-
在master分支提交更改1
-
在 develop 分支提交更改 2 3
-
直接合入到master分支，此时主流程多出一条 merge 记录，，（合入的三条命令）
切换到master分支，
git checkout master合入develop，
git merge develop解决冲突后，
git push，推送到远程一条带有merge记录的提交 -
如果develop分支需要继续开发，并且需要master中新提交的代码
执行
git merge master把 master 合并到 develop 分支
rebase
本地的两个分支rebase
新建如下提交，master提交两次，dev提交两次
在master分支上执行 rebase
-
git checkout master切换到master分支 -
git rebase develop执行 rebase -
解决冲突，
git add . -
git rebase --continue继续执行 rebase -
重复上述rebase步骤，直到 REBASE 消失
日常开发中与远程代码冲突rebase操作
如小明没有拉取远端最新代码 就 push，，（直接拉取则merge）
-
执行
git pull --rebase操作 （git pull的默认行为是git fetch + git merge，git pull --rebase则是git fetch + git rebase.）重复上述动作
整体流程图如下：
备注：
git rebase --abort 会放弃合并，回到rebase操作之前的状态，之前的提交的不会丢弃；即回到撤销 rebase，回到没有 pull 时的状态
git rebase --skip 则会将引起冲突的commits丢弃掉（慎用！！）；
git rebase --continue 合并冲突，结合"git add 文件"命令一起用与修复冲突，提示开发者，一步一步地有没有解决冲突。（fix conflicts and then run “git rebase --continue”）
git pull -r 即 git pull --rebase，相当于 git fetch + fit rebase
merge和rebase有什么区别
-
merge可以准确的体现出时间线，rebase时间线容易混乱
-
rebase看起来简洁，可以做到只有一条树状图，而merge不会
