GIT：多个开发人员在使用同一功能

对于以下场景，我有一个关于什么是最佳工作流的问题

目前有两个分支机构：

• 主人
• 发展

master仅通过批准的合并请求接受代码

考虑到两名开发人员使用相同的功能、不同的部分，为该功能创建合并请求的最佳方式是什么：

每个开发人员都创建自己的？（他们都有彼此的代码，因为为了进步，他们直接从对方身上推拉）

• 由于第一次创建合并请求时会对其他请求进行更改，这不会导致问题吗？一次推进一个提交将非常乏味。也许保留一个只进行本地更改的分支，然后创建一个集成分支？但是合并请求本身不起作用，也没有多大意义

其中一个为两者创建“完整”合并请求？

• 审查它成为一项更大的工作，因为它需要更多的代码，而且我们不能同时拥有合并请求的两个所有者

---

创建一个功能分支（来自master），供两个程序员使用。两位工程师都应该使用，这样评审员的工作就简单明了了。如果在该功能的开发过程中有许多其他工程师合并到master，请定期从master执行，以确保构建完整性。

如果两个开发人员的部分不是独立的，我建议您采用第2种方法，一个开发人员创建一个包含两个作业的合并请求。但是，您可以通过以下方式稍微降低难度：

-让每个开发人员对他们工作中的一部分进行代码审查。虽然这并不能避免对主分支的整个工作进行代码审查，但它肯定会减少拒绝

-对于大型功能，只要有可能，每个开发人员都应该生成不依赖于其他工作的较小的工作片段（“原子提交”），然后可以将该片段合并到开发分支中，并从其他开发人员处提取以继续其工作。这样，当特性完成时，它已经存在于开发分支中，而不是开发人员的主题分支中

根据您的描述，我相信您的开发人员将拥有包含所有工作的主题分支。从主题分支的角度来看，不能轻易地将两者分开。因此，选择第2种方法，并由两位开发人员签字。

在这种情况下非常有吸引力（并且与Github配合良好），它使用拉式请求将更改从开发人员的个人分叉发送回主存储库的存储库

• “源”远程点位于服务器上开发人员的个人项目分支（通常存储在Github上的个人区域等）
• “上游”远程点位于某些服务器上的官方存储库
• “开发”定期合并到官方存储库中的“master”中（而不是相反）
• 官方存储库中的“开发”和“主”都应始终干净地构建/测试
• 开发人员基于开发创建一个本地分支，以处理特定的问题/故事子集
• 当代码准备好进行审查并通过所有测试时，他们会再次将其本地分支的开发重新定基，然后

  git将分支推送到其私有分支库，并创建一个从其私有分支库/分支到主存储库/开发分支的拉取请求

假设开发人员有一个名为“i903问题描述”的分支（903是我们的github问题编号），并且他们需要根据开发重新设定基础：

git fetch upstream
git checkout development
git merge --ff-only upstream/development
git checkout i903-description-of-issue
git rebase development
git push origin i903-description-of-issue

因此，开发人员负责确保他们的个人分支始终与主存储库上的官方“开发”分支保持一致（通过重定基址）。它使用拉请求将多个提交合并到主“开发”分支中。Github（和其他工具）中的pull请求模型允许在接受PR之前进行代码审查

---

如果它是一个破坏性的特性分支，将破坏持续将“开发”分支部署到QA服务器的能力，然后，您可能需要将新功能分解为更小的部分，从而减少中断。

最好为两个开发人员提供两个不同的分支，并且在通过所有测试后，允许不同的合并请求进行不同的提交。您的选项#2在理论上很好，但在实际开发中（不同的开发人员）这真的不可能或至少不容易。因此，是的，我的选择2似乎是最好的。想看看别人有没有更好的主意！谢谢，如果功能不能在原子提交中划分，那么它应该在单独的主题分支中开发，然后合并为一个单位提交。回顾一下噩梦，我过去经常经历这种情况。但这如何解决孤立的合并请求问题呢？这是我最初的问题，不是工作方式。这是本地的，他们可以使用他们想要的功能分支，对于合并请求来说，这真的没有任何区别。如果单个（较大）合并请求的问题是所需审查的规模过大，并且单个审查者必须审查单个合并请求，然后，我看到的唯一其他选项是通过分区这个故事来创建单独的功能分支和合并请求，或者让单个审阅者在审阅期间与另一个审阅者配对。