我正在寻找合并代码时可能出现的以下场景的解决方案:
- 在代码中有一个基本的冲突，团队a和团队B都更新同一个文件，然后它报告为冲突。
- 团队a开发的特定功能与团队B的功能发生冲突
- 有一个性能问题，a团队开发了一个可以正常工作的更改，但是B团队的更改导致了a团队功能内的性能下降。
在最终发布方面，谁负责双方集成包的最终交付?
在发布期间，双方都将面临交付的压力。如果发生代码冲突，解决它们的过程是什么?如果团队A先签入，然后团队B确定一些代码冲突，基于下面的标准方法，他们将解决冲突。既然双方都在系统测试环境中测试了他们的代码并验证了更改，那么谁对更改负责呢?然而，这两个变化的集成测试直到SIT(系统集成测试)才会发生。因此，如果团队B更改了代码来解决团队A更改中的冲突，那么这将使已经发生的任何测试无效，并且他们可能无法跨越需求来正确地完全测试需求。
当前的最佳实践是拥有一个自动化的测试套件，它可以彻底测试整个应用程序的所有功能。(将测试推迟到开发之后的集成测试阶段，这绝对不是最佳实践。)
-
当任何开发人员更新代码时，更新测试(在同一提交中)以测试她的更改并确保所有测试通过是开发人员的责任。包括性能测试。
-
在任何更新之后，对于所有使用代码的开发人员来说，将更新尽快拉入他们的工作区是当前的最佳实践。每个开发人员都有责任解决他们的变更和存储库中最新版本的代码之间的任何源代码冲突，并确保所有测试都通过。通常不同的开发人员在代码的不同部分工作，不会有冲突。如果存在重要的冲突，则可能意味着两个开发人员应该一起工作。他们应该下决心下次做得更好。
关于交付，当前的最佳实践是让主分支在任何时候都可以交付。如果所有的测试都通过了，我们就知道软件已经准备好交付了。所以在开发方面不需要做什么来交付软件。如果软件要交付给客户，最好的决定人是产品所有者或产品经理，他们将根据业务需求做出决定。事实上，在可能的环境中(例如web应用程序)，最佳实践是自动交付所有测试通过的软件的每个版本。