使用git pull(merge)后压缩提交合入master会引发重复提交等问题吗？

是否会出现A、B、C提交重复的情况 #

不会。Git中每个提交的唯一标识是基于提交内容、父提交、提交时间等信息生成的哈希值，origin/master上已经存在的A、B、C、D、E提交和你的功能分支中引用的这几个提交哈希完全一致，Git只会在仓库中存储一份这些提交的内容，不管有多少分支引用它们，都不会出现重复存储或者提交历史重复展示的问题。

是否应该用rebase替代当前merge流程 #

这取决于你们团队对提交历史的偏好，两种方案都没有本质错误，适用场景不同：

• 如果你们团队希望保持线性、无冗余的提交历史，推荐使用rebase替代当前的merge流程：
  你可以将git pull origin master替换为git pull --rebase origin master，执行后你的本地提交X、Y会被迁移到origin/master最新的E提交之后，分支结构会变为：

  A---B---C---D---E origin/master
                       \
                        X'---Y' feature/branch
  

  后续再压缩为Z提交后，功能分支的历史完全没有多余的合并提交，合并到master时只会新增一条Z提交，整体历史可读性更高。
• 如果你们团队偏好保留完整的开发时序、希望能看到功能分支合入上游变更的时间点，当前的merge流程可以正常使用，不会有功能问题。

操作注意事项 #

• rebase操作只能在仅你自己使用的本地功能分支上执行，绝对不要对已经推送到远程的公共分支（比如master）执行rebase，否则会导致其他开发者的本地分支和远程分支冲突
• 压缩提交的操作建议在rebase完成后执行，避免将中间的合并提交M也纳入压缩范围
• 执行rebase前建议先通过git stash暂存本地未提交的修改，避免冲突时内容丢失

内容的提问来源于stack exchange，提问作者Travis Peterson