git 发布管理

Question

我找不到任何使用 git 管理版本的“正确”方法。比如说，我有 master、release-1、release-2 和 release-3 分支。 Release 1 已经发布，我只做错误修复和发布版本标记。第 2 版即将发布，我主要在此分支上进行开发，而在第 3 版中，我将开发未来需要的东西。

1. 当我在第 2 版上添加一些功能时，它也应该达到 3，但不是 1，我应该：

   • 将 release-2 合并到 master 并将cherry-pick 功能相关的提交合并到 release-3？
   • cherry-pick 功能相关的提交到 master，而不是cherry-pick 到 release-3？
   • 还有别的吗？

2. 当我需要在所有版本中更改某事时，我应该在 master 上进行并在所有分支中进行挑选吗？

3. 我应该让 master 与最新的（release-3 分支）保持同步，还是应该让 release-3 上的开发人员在我需要 release-4 分支之前合并到 master？

4. 当我在 release-1 或 release-2 上修复某事时，我应该合并还是挑选它来掌握它还是更确切地说？

我不太确定什么时候应该挑选，什么时候应该合并，以及分支之间的代码流是否正确。

Answer 1

请参阅 Junio C Hamano（git 维护者）博客上的以下帖子：

• Completing a merge
• Never merging back（关于不合并的分支）
• Resolving conflicts/dependencies between topic branches early
• Fun with remote branches (1)
• Fun with remote branches (2)

另请参阅 gitworkflows 手册页。

Answer 2

您要问的是一个典型的 merge workflow 问题：从哪里合并到哪里。

但您还需要记住，在 DVCS 中，合并也会受到 publication considerations 的影响（这些分支是推送到本地存储库还是公共存储库）

“master”分支尤其是在有人克隆您的存储库时默认可见的分支，这意味着它应该引用您认为对该用户/开发人员最有用的内容。 （自other branches are not referenced locally by default）

---

1/ 当我在 release-2 上添加一些功能时，它也应该到 3，但不是 1

在对 r2 进行多次提交后，您确实可以将 r2 合并到 master 以实现必要的演变。这样，在 master 中只能看到有限数量的提交，避免“提交混乱”。
但是，对于 r3，如果正在推送和发布 r3，您可以从 r2 中挑选您需要的内容。否则，您可以在 r2 上重新设置 r3。见“git workflow and rebase vs merge”问题

2/ 当我需要在所有版本中进行更改时，我应该在 master 上进行更改并在所有分支上进行挑选吗？

你应该在 r2 上做，然后在 master 和 r1 和 r3 上合并。这样，这些分支中只会添加一个提交。

3/ 我应该让 master 与最新的（release-3 分支）保持同步，还是让开发人员在 release-3 上并在我需要 release-4 分支之前合并到 master？

这取决于您希望其他同事在克隆存储库时看到什么。
但从 1/ 开始，我认为 master 代表 r2（当前开发）而不是 r3（未来，长期重构）

4/ 当我在 release-1 或 release-2 上修复某事时，我应该合并还是挑选它来掌握或更确切地说？

• r1：cherry-pick：并非您在 r1 上修复的所有内容都将合并到当前开发中。
  实际上，我更愿意将 r1 固定在 r2 上，确保一切正常，然后在 master 上合并。
• r2：合并。如果master代表r2，一个简单的合并就足够了。

Answer 3

我愿意：

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

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

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

4) 合并到主控

我认为合并比樱桃挑选更干净，并且认为只有在需要将功能或错误修复反向移植到提交时未预料到的旧分支时才应该挑选樱桃（否则在最旧的分支上提交/release 你想要的代码）。