Git的使用者会由于Rebase和Merge 哪个更适合他们的工作流而被划分为两个群体。 Git rebase的倡导者之所以喜欢它，因为它简化了他们的审查过程。Git merge的倡导者喜欢这种方式，因为它保留了支的历史。那么对您和您的团队来说，最佳方案会是什么？

        Merge是使用版本控制系统的开发人员的常见做法。不关分支是由于测试需要、修复bug需要、或者其他原因而被创建的，Merge操作会把改动放到另外的位置。更具体地说，合并将获取源分支的内容并将其

        与目标分支集成。在此过程中，仅更改目标分支，源分支历史记录仍然存在。

        但是对于Git，还有第二种Rebase的选择。这是将更改从一个分支集成到另一个分支的一种方法。Rebase将所有更改压缩为单个“补丁”。然后它将补丁集成到目标分支上。与Merge不同，Rebase会使历史记录变平整，因为它将已完成的工作从一个分支转移到另一个分支在此过程中，消除了不需要的历史记录。 

Git Rebase VS Git Merge

        这个问题甚至导致Git社区群体两极分化了。有些人觉得最好使用Rebase而有些人认为最好用Merge。每一方都有自己深信不疑的理由。

Git Rebase

• 简化较为复杂的历史版本记录

• 避免在繁多的存储库中频繁使用分支Merge带来不必要的干扰

• 通过单一的Commit来消除中间Commit，这对DevOps团队很有帮助

Git Merge

• 简单而熟悉

• 保留完整的历史和时间顺序

• 维护分支的上下结构

 那么你的团队应该使用哪一个？

Git Rebase对个人很有帮助 – 团队成员如是说

        像生活中的许多事情一样，Git rebase与merge工作流程问题的答案是“这得看情况再说”。在Perforce，我们认为没有必要存在“永远Merge”和“总是Rebase”这两个极端。两者都有同时存在的使用价值。

我们来看看Git rebase问题：

• 个人的Rebase只影响个人（在推动工作之前）

• 公共的Rebase操作会影响他人

• 在要进行团队工作时，Rebase的简洁和优雅不复存在

• 团队决定至关重要，取代个人偏好

• 不论从可回溯性，兼容性还是其他方面，版本历史对其他团队来说非常重要

        对于个人来说，Rebase很有意义。Git的魅力在于能够随心所欲地为每个工作单元进行分支。此外，当您在本地（单独）进行工作时，您可以，并且确实会经常进行Commit，Rebase允许您在审核之前进行清理。但在与他人合作时，我们建议坚持Merge以避免混淆。

Merge 和 Rebase策略

        在设置Gitrebase与merge策略时，团队需要考虑几个问题。因为事实证明一种工作流程策略并不就比另一种更好。这取决于您的团队。考虑整个团队组织的Rebase和Git的能力水平。与版本可追溯性和merge历史相比，您更应该重视Rebase的简单程度。

        最后，应在明确的分支策略的背景下考虑Merge或Rebase的决策。一个成功的分支策略是围绕您的团队组织来做出的。开发人员应该以并行开发的形式，允许他们按照自己的进度进行工作，而不受其他人的影响。

例如，您可以拥有一个开发分支，每个团队都是分隔开来的。只有情况差不多了才开始进行工作。这使得可以清楚地将工作单元与主分支隔离。它还使其与QA隔离，QA是与预发布环境隔离的，等等。简而言之，您的分支策略反映了您组织的结构，其中的角色和任务目标等。

Perforce改进你的Git策略

        Perforce解决方案允许开发人员以他们想要的方式使用Git，同时提高生产力。他们可以没有延误地进行Merge或者Rebase。

        借助Perforce的Git平台Helix4Git，您可以轻松扩展Git以处理大型文件和与全球团队合作。Helix4Git在单一管理平台下集成多个仓库项目，以提高安全性，加快持续集成/交付（CI / CD）性能，并使构建速度提高80％。