目录

0.回顾

1.ff模式

2.no-ff模式

3.ff模式转no-ff模式

---

• 先提交再合并再提交 

0.回顾

前面介绍了两种情况总结如下： 

1. master没有修改提交，在dev中修改提交，master和dev合并顺利
2. master修改提交的同时dev也修改提交了，产生合并冲突☞手动解决☞并再次提交

这两次merge操作分别对应git给我们提供了两次的merge模式。ff模式和no-ff模式。

git log --graph --abbrev-commit 

1.ff模式

Faster forward：git提供的第一种模式（faster forward模式）

• 将master分支中的内容commit id修改为dev2分支中最新一次提交的commit id
• 在这种 Fast forward 模式下，删除分⽀后，查看分⽀历史时，会丢掉分⽀信息，看不出来最新提交到底是 merge 进来的还是正常提交的。
• 此次merge用到是faster-forward模式：看不出是master提交的，还是dev2提交的合并的

2.no-ff模式

no-faster-forward模式：git提供的第二种模式（非faster forward模式）

• 合并冲突之后，手动解决之后，又进行一次提交。
• 可以明显看出是合并之后提交的。
• 这样的好处是，从分⽀历史上就可以看出分⽀信息。例如我们现在已经删除了在合并冲突部分创建的 dev1 分⽀，但依旧能看到 master 其实是由其他分⽀合并得到。

3.ff模式转no-ff模式

git merge --no-ff -m "merge再次提交描述提交的详细信息"  dev2（合并的分支名称）

git merge --no-ff -m "merge with no-ff" dev2

本质是为了回溯历史的时候：到底是直接master提交，还在别的分支上dev2提交了再合并的