・龙智ALM方案      ・Perforce      ・Atlassian      ・JetBrains      ・IC-Manage

Git的使用者会由于RebaseMerge 哪个更适合他们的工作流而被划分为两个群体。 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%。