logo标签列表

Git发布管理

gitrelease
35

我找不到管理使用Git进行发布的“正确”方法。比如，我有master、release-1、release-2和release-3分支。Release 1已经发布，并且我只在其上进行错误修复和版本标记。Release 2即将发布，我主要在这个分支上开发，而在3上则开发未来需要的功能。

  1. 当我在release-2上添加一些功能并且它也应该出现在3中，但不应该出现在1中时，我应该：

    • 将release-2合并到master，然后将与功能相关的提交cherry-pick到release-3吗？
    • 将与功能相关的提交cherry-pick到master，然后再cherry-pick到release-3中吗？
    • 还是其他方法？

  2. 当我需要更改所有版本的某些内容时，我应该在master上进行更改，然后将其cherry-pick到所有分支上吗？

  3. 我应该将master保持最新（使用最新的release-3分支），还是在release-3上进行开发，并在我需要release-4分支之前将其合并到master上？

  4. 当我在release-1或release-2上进行修复时，应该将其合并或者cherry-pick到master上还是其他的方式？

我不确定何时应该使用cherry-pick，何时应该使用合并，以及代码在分支之间的流动是否正确。

1
另请参阅http://www.golden-gryphon.com/software/misc/packaging.html以获取更多想法。 - VonC
3个回答
17
7
你所询问的通常是一个关于合并工作流问题：从哪里合并到哪里。但你也需要记住，在分布式版本控制系统中，合并也会受到发布考虑因素的影响（这些分支是推送到本地存储库还是公共存储库）。
特别是“主”分支是默认情况下克隆存储库时可见的分支，这意味着它应该引用你认为对用户/开发人员最有用的内容。（因为其他分支在默认情况下不被本地引用）

1/ 当我在release-2中添加一些功能，它也应该进入到3中，但不应该进入到1中

您确实可以将r2合并到主分支中，在r2中进行一些提交以实现所需的演变。这样，只有有限数量的提交会出现在主分支中，避免了“提交混乱”的情况。
对于r3，如果正在推送和发布，则可以从r2中挑选所需内容。否则，您可以在r2上进行rebase操作。请参阅 "git workflow and rebase vs merge" 问题。

2/ 当我需要在所有版本中更改某些内容时，我应该在主分支上进行，并将其cherry-pick到所有分支上吗？

您应该在r2上进行操作，然后将其合并到主分支、r1和r3上。这样，这些分支只会添加一个提交。

3/ 我应该让主分支与最新的（release-3分支）保持最新状态，还是应该让开发者在release-3上工作，并在需要release-4分支之前将其合并到主分支？

这取决于您希望其他同事在克隆存储库时看到什么。但是从1/中可以得出，master代表r2（当前开发），而不是r3（未来的长期重构）。
4/当我修复release-1或release-2上的问题时，我应该将其合并或cherry-pick到主分支还是其他方式？
  • r1: cherry-pick：并非您在r1上修复的所有内容都意味着要合并到当前开发中。实际上，我宁愿在r2上cherry-pick r1修复的内容，并确保一切正常，然后再合并到master分支。
  • r2: 合并。如果master代表r2，则简单的合并就足够了。
0

我会这样做：

1）将r2合并到master，然后将master合并到r3（r3应该能够接受master的所有更改）

2）提交到r1，合并到r2，将r2合并到master，然后将master合并到r3

3）也许你应该使用master而不是r3，并且只有在准备发布时从r3分支开发，并将所有更改合并到master（这将是下一个版本）。或者像Linux一样使用“master”和“next”分支。

4）将其合并到master

我认为合并比挑选更干净，而且我认为只有在需要将功能或错误修复回溯到旧分支时才应该挑选（否则，请在您想要代码的最旧分支/发布上提交）。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接