关于 Gitlab 中多个分支/开发人员的问题

Question

我仍在学习 Git 最佳实践的过程中，我正在尝试找出我在哪里出错了......

我们有一个“主”分支连接到我们的“暂存”环境。对该分支的任何提交都会触发更新该环境的管道。

我们有一个“生产”分支，这是我们的受保护分支，反映了实际生产中的内容。

所有其他工作都发生在我们从生产中克隆的各个功能分支中。

所以这是工作流程：

开发人员 A 创建一个名为“NewFeature1”的分支（从生产中克隆）。

开发人员 B 创建了一个名为“BugFix1”的分支（从生产中克隆）。

开发者 B 将代码推送给“master”进行测试。

开发人员 A 尝试将代码推送到“master”，但遇到了冲突。开发人员 A 解决了冲突，但这会导致“NewFeature1”分支从“master”获得大量提交历史记录，这并不理想？

当开发人员 A 对“NewFeature1”中的更改感到满意时，将为“生产”分支打开合并请求。但是，他们不仅看到与 NewFeature1 相关的 1 或 2 个提交，还看到来自 master 被合并的巨大提交历史。唯一真正更改的文件是相关文件，但来自 master 的提交仍在其中，这让我感到害怕。

总的来说，我们对 Git 都很陌生，所以我可能在这里遗漏了一个核心概念。

Answer 1

有许多方法可用于使用 Git 合并和管理分支。这代表了一种可能的方法，可能有助于减少问题中提到的合并困难。

最后提供了一个数字供参考。

1. 从主分支创建次要和非关键错误修复分支和新功能分支。这样可以更轻松地开发新代码并将其与并行开发的其他代码集成。
2. 在将这些类型的分支合并回主分支之前，使分支与主分支保持同步。这方面的一个示例是将提交 5 合并到提交 8 中，如图所示。生成的合并提交可用于使用并行开发的任何功能重新测试程序。
3. 重要的错误修正分支从生产分支创建并合并到生产分支。这些应用于修复对产品功能有重大影响的错误，并且应尽可能减少更改以避免影响生产分支的稳定性并包含所需的回归测试量。
4. 对生产分支的任何更新都会合并到主分支以使其保持最新。这方面的一个示例是将提交 10 合并到提交 11 中，如图所示。这些应该不太频繁，但可能会很复杂，具体取决于自上次发布以来对主分支所做的更改程度。
5. 在将更改从主分支拉到生产分支之前，从主分支创建发布分支。此分支可用于测试生产版本，并可根据需要进行更新以解决任何错误。
6. 生产测试完成后，发布分支将合并到生产分支。这可能是一个快进合并。
7. 在生产测试中所做的任何更改也应合并到主分支中。这方面的一个示例是将提交 12 合并到提交 13 中，如图所示。

下图作为示例提供。箭头从父提交指向子提交。常规提交为蓝色，合并提交为红色。提交编号是为了便于阅读而提供的，并将表示为 SHA-1 哈希