这是我参与「第五届青训营 」伴学笔记创作活动的第 3 天
最近在写项目开发规范的约定文档，正好看到有在做 Github 开源项目的 UP 分享了自己的 Github 工作流，并且使用的是 rebase 而非 merge，所以今天做个实验并整理下二者的区别。
先写一个 Go 的 Demo。
import "fmt"
func main() {
fmt.Println("初始化")
}
然后在命令行依次输入以下命令。
git init
git add .
git commit -m "init"
再查看下 git 的日志
git log
commit 4057cdafbda63554c835c72a1569f05ea0cd7954 (HEAD -> master)
写点代码
func main() {
fmt.Println("初始化")
fmt.Println("master分支更新1")
}
提交，重复的命令这里就不演示了。
然后创建两个新分支出来，分别进行两次更新提交
git checkout -b merge
进行 merge
git merge merge
运行结果
Updating 3ada9b8..2b63009
Fast-forward
main.go | 2 ++
1 file changed, 2 insertions(+)
可以看到 master 的指针和 merge 的合并了，整体分支结构还是没有变化。
再执行 rebase
git rebase rebase
代码会提示有冲突，按照提示信息解决完冲突再提交一次即可。
"git add/rm <conflicted_files>", then run "git rebase --continue".
然后点击右下角的提示的继续 Rebase
可以发现整个 rebase 分支的结构已经被接在了 master 分支之后。
当然因为是在 master 分支下执行的，可能看不太出来，我们切换到 merge 分支后再 rebase 一下 master。
git rebase master
可以看到原来的 merge 分支结构已经消失了，merge 分支接在了 master 分支之后。
总结：
如果当前分支为个人分支 branch，执行 git merge/rebase master 命令。
merge 会保留 branch 的结构，仅将两个分支的最新节点进行合并。
rebase 会将当前分支的提交完全复制 master 的最新提交之后，branch 的分支结构会消失。
也就是说，实际选用哪个命令，就看需不需要保留原来的分支结构。
由于团队协作中想保留分支结构方便回溯，最后还是觉得使用 merge 更好。
