git发布管理

Question

我找不到用git管理发行版的“正确”方法。比如说，我有主，释放-1，释放-2和释放-3分支。版本1已经发布了，我只做错误修复和发布版本的标签。第2版将很快发布，我主要是在这个分支上开发的，而在第3版中，我开发了将来需要的东西。

1. 当我在版本2上添加一些特性时，它也应该是3，但不是1，我应该：

- merge release-2 to master and cherry-pick feature related commit to release-3?
- cherry-pick feature related commit to master and than cherry-pick it to release-3?
- sth else?

​

1. 当我需要改变所有版本的某物时，我应该在师父身上做，然后把它摘到所有的枝条上吗？
2. 我是否应该更新最新版本(版本-3分支)，或者更确切地说，是在版本-3上进行开发，并在我需要版本-4分支之前合并到主服务器？
3. 当我修正某物的版本-1或版本-2，我应该合并还是樱桃-选择它掌握，或者更确切地说？

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

Answer 1

请参阅Junio C Hamano (git维护者)博客上的以下文章：

• 完成合并
• 永不归并 (关于不合并的分支)
• 尽早解决主题分支之间的冲突/依赖关系
• 远程分支的乐趣(1)
• 远程分支的乐趣(2)

还可以查看gitworkflows手册页面。

Answer 2

您要问的是一个典型的合并工作流问题:从哪里到哪里合并什么。

但是，您还需要记住，在DVCS中，合并也将受到出版考虑的影响(是将这些分支推到本地存储库，还是公共存储库)

特别是当有人克隆您的回购时，"master“分支是默认可见的，这意味着它应该引用您认为对用户/开发人员最有用的内容。(自默认情况下，其他分支不会在本地引用。以来)

1/当我在版本-2上添加一些特性时，它也应该是3，但不是1。

在对r2进行了多次提交之后，您确实可以将r2合并为master，以便实现必要的发展。这样，只有有限数量的提交在主人中可见，避免了“提交混乱”。

然而，对于r3，如果r3被推送和发布，您可以从r2中挑选您需要的内容。否则，您可以在r3的基础上重新设置r2。见"git工作流和重基与合并“问题

当我需要改变所有版本的某物时，我是否应该在师父身上做它，并把它摘到所有的枝条上？

您应该在r2上这样做，然后在Masterandr1和r3上合并。这样，在这些分支中只添加了一个提交。

3/我是否应该更新最新版本(版本-3分支)，或者更确切地说，是在版本-3上进行开发，并在我需要版本-4分支之前合并到主服务器？

这取决于你希望你的另一位同事在克隆回购时看到什么。

但是从1/开始，我想主人代表的是r2 (当前开发)，而不是r3 (未来的、长期的重构)。

当我将某物固定在第1版或第2版时，我应该合并还是挑选它来掌握呢？

• r1: cherry:并不是所有您在r1上修复的东西都要合并到当前的开发中。 实际上，我宁愿选择固定在r1上的r2，确保所有东西都在那里工作，然后在Master上合并。
• r2:合并。如果主服务器表示r2，那么一个简单的合并就足够了。

Answer 3

我会这样做：

1)将r2合并为master，然后将master合并为r3 (r3应能够接受对主的所有更改)

2)提交到r1，合并到r2，合并r2到主控，然后合并到r3

3)也许您应该使用master而不是r3，并且只在准备发行版时在r3上进行开发，并将这里的所有更改合并到主(这将是下一个版本)。或者使用“主”和“下一步”分支作为Linux。

4)合并为主人

我认为合并比摘樱桃更干净，并且认为只有当您需要将一个特性或did移植到一个您在提交时没有想到的旧分支(否则提交到最老的分支/发布您希望使用的代码)时，您才应该选择它。