git发布管理

Question

我找不到任何使用git管理版本的“正确”方法。说，我有master，release-1，release-2和release-3分支。版本1已经发布，我只对其进行了错误修正和发布版本标记。第2版​​将很快发布，我主要在这个分支上发展，而在3年我开发了将来需要的东西。

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

   • 将release-2合并到master-cherry-pick功能相关提交到release-3？
   • 樱桃挑选功能相关提交掌握而不是樱桃挑选它发布-3？
   • 还是吗？

2. 当我需要在所有版本中进行更改时，我是否应该在master上进行更改并将其挑选到所有分支中？

3. 我是否应该让最新的（第3版分支）或者第3版的开发人员更新并在我需要发布4分支之前合并到主服务器？

4. 当我修复发行版1或发行版2时，我应该合并或者选择它来掌握或者更确切地说？

我不太确定我什么时候应该挑选，什么时候应该合并，如果分支之间的代码流正确的话。

Answer 1

请参阅Junio C Hamano（git maintainer）博客上的以下文章：

• 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”分支特别是当有人克隆你的repo时默认可见的分支，这意味着它应该引用你认为对该用户/开发者最有用的东西。 （自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 /我应该掌握最新的（第3版分支）或者第3版的开发人员，并在我需要第4版分支之前合并到主服务器吗？

这取决于您希望其他同事在克隆回购时看到的内容 但从1 /，我收集主人代表r2（当前发展）而不是r3（未来，长期重构）

  

4 /当我修复发行版1或发行版2时，我应该合并或者选择它来掌握它还是更确切地说？

• r1：cherry-pick：并非所有你在r1上修复的东西都要合并到当前的开发中。
  实际上，我宁愿在r2上挑选r1，确保一切都在那里工作，然后在主人身上合并。
• r2：合并。如果master代表r2，那么简单的合并就足够了。

Answer 3

我愿意：

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

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

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

4）合并到主人

我认为合并比采摘樱桃更清晰，并认为当你需要将一个功能或错误修复后退到一个你提交时没想到的旧分支时，你应该只挑选一个（否则在最旧的分支上提交） /释放你想要的代码。）