哪些工具和流程可用于有效的基于干线的开发？

Question

在我的公司，我们正在使用git-flow，并且拥有许多分支机构和PR通常会令人困惑，并且会降低开发速度。在项目的启动阶段尤其没必要。

一个问题是大多数功能需要超过1或2天才能完成。如果存在代码审核流程，则可能需要一两天的时间。如果在不成熟（快速变化的）代码库中有多个开发人员在不同的分支上工作了好几天，那么分支机构就有很多分歧的机会，导致合并冲突，重复工作等。有时会创建分支机构由于某种原因尚未合并的另一个功能分支。这也容易出错，例如PR可能有错误的＆＃34;基础分支＆＃34;。有时在合并PR之后，我尝试将trunk / master合并到我的功能分支中，这导致了痛苦的合并，其中每个修改的文件都显示为冲突。

但是，某种代码审查实践是必要的，所以我想知道其他团队和公司使用了什么。

我可以想象一个系统，其中功能由提交消息中的标记标识。例如＆＃34; [XYZ-1234]添加了新组件＆＃34;。标签标识票证，消息提供更多详细信息。所以每个人都可以致力于开发一个开发人员。分支，并经常同步，当确定一个功能完成时，与该功能相关的所有提交都可以进行代码审查，然后合并到＆＃34; master＆＃34; （通过搜索提交消息）。这对我来说似乎更简单，更好，所以我不确定为什么不创建和使用这样的系统。

Answer 1

根据您的描述，似乎所有开发人员都拥有自己的功能分支，然后创建PR以将功能分支合并到主分支。

对于这些建议，您应该为所有开发人员创建一个分支，例如dev，以便在分支机构上共同工作。工作流程如下：

• 所有开发人员都在他们自己的feature分支机构工作。
• 当开发人员完成工作时，他们应该将feature分支合并到dev分支。
• 然后创建一个PR以将dev合并到master分支。
• 下次开发人员开发新作品时，他们可以从feature分支创建新的dev分支。由于某些feature分支可能会存在几周，并且在这几周内dev分支上可能会有新的更改，因此开发人员可以在最新{{1}之上重新定位这些feature分支通过在dev分支上执行git pull origin dev --rebase命令进行分支。

Answer 2

正常的干线流量应该适用于您的情况。

您面临的问题可能会被一些额外的做法所缓解。

1. 合并冲突中的痛苦

   • 这里我们假设功能分支不共享
   • 开发人员应经常将master（假设您使用master作为trunk）合并到其功能分支中，或经常在最新master上重新绑定其功能分支。
   • 在拉取请求真正合并回主人之前，尝试重新绑定/压缩到最新的主人。这使主历史更加线性化。

2. 基于另一个功能分支的功能分支

   • 我希望你在这里共享一个功能分支。尽可能避免使用它。它使您的合并和处理更容易

3. 功能分支命名

   • 我有功能分支名称和提交消息都包含票号。功能完成后，Coz功能分支将消失，因此您只能参考您的提交消息，以确定哪些更改与哪个问题相关。

不确定是否有帮助