git发布管理 [英] git releases management

问题描述

我找不到什么是使用git管理发布的正确方法。比方说，我有master，release-1，release-2和release-3分支。版本1已经发布，我只修正并发布标签。第二版即将发布，我在这个分支上进行大部分开发，而第三期则开发未来需要的东西。

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

   
   
   • 合并release-2到master和cherry-pick功能相关的提交到release-3？
   
   
   • cherry-pick功能相关的提交到master和cherry-pick到release-3
   
   
   • sth else？
   
   



2. 当我需要改变所有版本，我应该在master上完成并将其选择到所有分支吗？

我应该让master掌握最新版本（release-3分支），还是开发人员在release-3上，并在我需要release-4分支之前合并到master？

当我修正版本1或版本2时，我应该合并还是挑选它来掌握或者更确切地说？

li>

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

解决方案

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

• 完成合并


• 永不合并（关于意图不合并的分支）


• 早日解决主题分支之间的冲突/依赖关系


• 与远程分支的乐趣（1）
>

• 有趣的远程分行（2）
  

另请参阅 gitworkflows 手册页推荐的工作流程概述。

I couldn't find anything what is the "right" approach to manage the releases using git. Say, I have master, release-1, release-2 and release-3 branches. Release 1 is already released and I do only bugfixing and released versions tagging on it. Release 2 is going to be released soon and I develop mostly on this branch while on 3 I develop things which will be needed in the further future.

1. When I add some feature on release-2 and it should go to 3 as well, but not to 1, should I:

   • 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?

2. When I need to changes sth in all the versions, should I do it on master and cherry-pick it to all the branches?

3. Should I keep master up to date with the newest(release-3 branch) or rather developer on release-3 and merge to the master just before I will need release-4 branch?

4. When I fix sth on release-1 or release-2, should I merge or cherry-pick it to master or rather?

I'm not quite sure when should I cherry-pick, when should I merge and if the flow of the code between the branches it right.

解决方案

See the following posts on Junio C Hamano (git maintainer) blog:

• Completing a merge
• Never merging back (about branches forked with intention of not merging back)
• Resolving conflicts/dependencies between topic branches early
• Fun with remote branches (1)
• Fun with remote branches (2)

Take also look at gitworkflows manual page.

这篇关于git发布管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！