【发布时间】:2020-05-04 18:48:37
【问题描述】:
我在一家目前只有两名开发人员的小公司工作。我不是 GitHub 专家,我知道我们当前的工作流程不一定是标准的。我不打算重新设计我们的整个工作流程,只是针对这一特定挑战的合理解决方案:
我们有两个主要分支:Development 和 Master。我们使用 Master 分支进行客户端安装,因此它始终位于开发之后,直到我们在主要版本之前将两者合并。
由于我们的软件和目标市场的性质,重要的是我们能够在发布之间定期将特定客户的自定义代码应用到主分支,以便在我们安装时可以使用它们。我们还需要将这些更改应用到 Development 分支,以便它们包含在下一个版本中。此自定义代码包含在所有未来的客户端安装/更新中,但只有基于配置设置的特定客户端才能访问。
我目前的解决方案是基于 Master 分支创建“自定义功能”分支。完成自定义工作后,我们将为 Master 分支和 Development 分支创建一个拉取请求。由于 Master 分支始终具有与开发相同的代码,只是处于早期状态 - 在我看来,它应该可以工作。但就像我说的,我不是 GitHub 方面的专家,我确信这可能出于各种原因很危险。
我知道将这些类型的定期更改应用于实时发布分支是有风险的。然而,由于我们软件的性质,我们的大多数客户在为他们安装时都希望至少进行少量定制。
编辑
我知道这与这个问题非常相似: Avoid merging master into development branch
但我提议从发布分支而不是开发分支分支,所以我认为这是一个不同的情况(我承认该问题中的一些概念让我无法理解)。如果这被认为是重复的,我深表歉意。
【问题讨论】:
标签: github deployment version-control branch release