通常，开发人员可以在“合并”（merge）和“重建基准”（rebase）（重定位）之间进行选择。 在Google中您会看到不同的意见，建议许多人不要使用Rebase，因为这可能会导致严重的问题。 在本文中，我将解释什么是合并和移动，为什么要（或不应该）使用它们以及如何做到这一点。
Git Merge和Git Rebase拥有相同的目标。 它们旨在集成从一个分支到另一个分支的更改。 尽管最终目标是相同的，但操作原理却不同。
有些人认为您应该始终使用Rebase；其他人则喜欢Merge。 这有其优点和缺点。
Git合并
对于使用版本控制系统的开发人员而言，合并是一种常见做法。 无论创建分支是为了测试，错误修复还是出于其他原因，合并都会在其他地方捕获更改。 合并将获取源分支的内容，并将其与目标分支合并。 在此过程中，仅目标分支被更改。 源分支的历史记录保持不变。
优点：- 简单
- 保留完整的历史记录和时间顺序；
- 维护分支上下文。
缺点：- 提交的历史记录可以用很多提交来填充（污染）；
- 使用git bisect进行调试可能会更加棘手。
怎么做使用
checkout和
merge命令将master分支合并到feature分支。
$ git checkout feature $ git merge master (or) $ git merge master feature
这将在功能分支中创建一个新的“合并提交”，其中包含两个分支的历史记录。
git rebase
变基是将更改从一个分支推送到另一个分支的另一种方法。 Rebase将所有更改压缩到单个补丁中。 然后将补丁集成到目标分支中。
与合并不同，移动会覆盖历史记录，因为它会将完成的工作从一个分支转移到另一个分支。 该过程消除了不需要的故事。
优点：- 简化一个可能复杂的故事
- 一次提交即可简化操作
- 避免在繁忙的存储库和分支中合并提交
- 清理中间提交，使它们成为单个提交，这对于DevOps命令很有用
缺点：- 将功能压缩到几次提交可能会隐藏上下文
- 在团队中工作时，移动公共存储库可能很危险
- 出现更多工作
- 若要使用已删除的分支进行恢复，则需要进行推送。 这导致本地和远程具有相同名称的所有分支的更新，这很糟糕。
如果您错误地采取了行动，那么故事将会改变，这可能会导致严重的问题，因此请确保您做到了！
怎么做使用以下命令将Feature分支移至main分支。
$ git checkout feature $ git rebase master
这会将整个功能分支移至主分支。 项目的历史记录正在更改，将在主分支中为每个提交创建新的提交。
互动运动
这允许您在将提交移动到新分支时更改提交。 这比自动移动更好，因为它可以完全控制提交的历史记录。 通常用于在合并功能分支到母版之前清除历史记录。
$ git checkout feature $ git rebase -i master
这将打开编辑器，列出所有将被移动的提交。
pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3
这将确定分支在移动后的外观。 通过布置对象，可以根据需要制作故事。 您可以使用
fixup ，
squash ，
edit等命令。
使用哪一个？
那有什么更好的呢？ 专家推荐什么？由于所有团队都不相同，因此很难就哪个更好使用做出唯一正确的决定。 这完全取决于团队的需求和传统。
根据Git的团队能力做出决定。 简单性或重写历史记录对您来说很重要，还是其他？
我有什么建议？随着团队的成长，使用合并管理或跟踪开发变更变得越来越困难。 为了获得清晰可理解的提交历史记录，使用Rebase是明智的。
变基的好处：- 您在本地发展：如果您尚未与其他人共享您的工作。 现在，您应该更喜欢合并以使故事井井有条。 如果您有一个不与其他开发人员共享的个人存储库分支，则即使移至分支机构也可以重新设置基础。
- 您的代码已准备好进行检查：您已创建拉取请求。 其他人会分析您的工作，并可能将其插入本地进行审查。 目前，您不应该移动工作。 您必须创建“重做”提交并更新分支。 这有助于跟踪请求请求，并防止意外中断故事。
- 审查已完成，可以集成到目标分支中。 恭喜你！ 您将要删除功能分支。 鉴于从现在开始，其他开发人员将不会提取并合并这些更改，这是您改变故事的机会。 此时，您可以重写历史记录并重置原始提交，这些烦人的“变更”和“合并”合并为一小组目标提交。 为这些提交创建显式合并是可选的，但这很重要。 它记录功能何时达到主状态。
现在您知道了，尽管微不足道，但是Merge和Rebase之间的区别。 我相信您会做出正确的决定，并会使用适合您的东西。
不要忘记： code = coffee + developer