3

我对以下场景的最佳工作流程有疑问。

目前有2个分店：

  • 掌握
  • 发展

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

鉴于 2 位开发人员致力于相同的功能，不同的部分，为该功能创建合并请求的最佳方式是什么：

  1. 每个开发人员都创建自己的？（他们都有彼此的代码，因为为了进步，他们直接相互推拉）
    • 这不会引起问题，因为第一次创建合并请求会使其他更改？一次推送一个提交将非常乏味。也许只保留本地更改的分支并创建集成分支？但是合并请求本身不起作用，也没有多大意义。
  2. 其中一个为两者创建一个“完整”的合并请求？
    • 审查它成为一项更大的工作，因为它有更多的代码，而且我们不能同时拥有 2 个合并请求的所有者
4

3 回答 3

2

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

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

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

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

于 2016-06-13T17:15:48.377 回答
1

创建一个功能分支（来自 master），两个程序员都在处理。两位工程师都应该使用“原子提交”，以便审阅者的工作简单明了。如果在此功能开发期间有许多其他工程师合并到 master，请定期从 master 执行rebase以确保构建完整性。

于 2016-06-13T17:14:40.460 回答
1

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

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

假设开发人员有一个名为“i903-description-of-issue”的分支（903 是我们的 github 问题编号），他们需要针对开发进行 rebase：

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（和其他工具）中的这种拉取请求模型允许在接受 PR 之前进行代码审查。

如果它是一个破坏性的功能分支，会破坏将“开发”分支持续部署到 QA 服务器的能力，那么您可能需要将新功能分解为破坏性较小的较小部分。

于 2016-06-16T09:44:55.380 回答