标签:ast 区别 提交 gem view 自动 就是 imageview 意义
$ git checkout master
$ git merge dev
这是最基本的 merge,会把分支的提交历史原封不动地拷贝过来,如果 master 此后已经有了新的提交,那么本次 merge 时还会额外自动创建一条 commit 信息用于记录本次 merge 操作。
$ git checkout master
$ git merge --squash dev
字面意思,相比?merge?来说会减少分支合并的记录,会被压缩为一条 commit 记录。squash merge 本质是把 dev 分支的改动保存到 master 本地,接下来还需要手动提交一下,因此最终提交者变成了操作 master 分支的人,这可能是个弊端。
$ git checkout dev
$ git rebase -i master
$ git checkout master
$ git merge dev
rebase merge 可以完美解决 squash merge 可能会变更原始提交者的问题。
首先 rebase 这个概念如果不懂可以先去了解下,这里先进行 rebase 的意义,个人认为,一方面是为了和 master 分支同步一下信息,以免 master 在和 dev 分叉之后又有了额外的更新;另一方面,能真正解决 squash merge 痛点的是 -i
交互模式,会进入文本编辑框,由自己指定 dev 相对于 master 新产生的这些“补丁” 在 rebase 时具体该如何应用到当前 dev 分支上。
所以 rebase merge 是非常灵活的,你可以什么都不干,采用默认策略:
pick xxxxxxx A
pick xxxxxxx B
pick xxxxxxx C
也可以把所有 commit 合为一条,保存退出后,会再次进入一个用于编辑合并后提交信息的文本编辑框:
pick xxxxxxx A
squash xxxxxxx B
squash xxxxxxx C
还可以不合为一条,而只合并其中某几条,比如把 A,B,C 三条提交记录整合为 AB,C 两条记录:
pick xxxxxxx A
fixup xxxxxxx B
pick xxxxxxx C
文本编辑框中定义的指令合理的话,应该会顺利 rebase 成功,之后可以 git log 查看一下是否如愿。
最后,在 master 分支上进行 git merge dev 就是常规操作了。
所以 squash merge 和 rebase merge 在多条合并为一条时的区别是,前者在 merge 时才合并为一条,而后者在提前 rebase 时就顺便整合了多条 commit 信息。
参考:
git merge时merge/squash merge/rebase merge的区别
标签:ast 区别 提交 gem view 自动 就是 imageview 意义
原文地址:https://www.cnblogs.com/nicholaswang/p/11801563.html