36

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

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

    • 将 release-2 合并到 master 和cherry-pick 功能相关的提交到 release-3？
    • 樱桃挑选功能相关的提交给主人，而不是挑选它到发布-3？
    • 其他？

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

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

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

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

4

3 回答 3

17

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

还请查看gitworkflows手册页。

于 2009-06-25T12:30:44.977 回答
7

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

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

当有人克隆您的存储库时，“master”分支尤其是默认可见的分支，这意味着它应该引用您认为对该用户/开发人员最有用的内容。（因为默认本地不引用其他分支）

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

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

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，一个简单的合并就足够了。
于 2009-06-25T06:47:51.143 回答
0

我会做：

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

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

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

4) 合并到主控

我认为合并比樱桃采摘更干净，并且认为只有当您需要将功能或错误修复反向移植到提交时您没想到的旧分支时才应该选择樱桃（否则在最旧的分支上提交/释放您想要代码）。

于 2011-07-21T12:04:11.013 回答