Git分支模型：几个问题

我们已经接近分支模型，我们有一个代表生产代码的master分支和代表未来版本的release-x.x分支。Git分支模型：几个问题

然而，也有少数情况下，我们不知道如何有效地解决：

直播bug修复是不相关的当前版本

新feature是支链的release-2.0的并完成模块A的重写。
新的feature已完成并合并在release-2.0。
当前活动模块A中的错误在master上找到并修复。

在这一点上，我们推测有2种可能：

我们变基上masterrelease-2.0带来错误修复和解决冲突（丢弃错误修复代码也就是现在无关）。最终，我们在master版本准备好后合并release-2.0。
我们摘樱桃只有bug修正是相关的释放到release-2.0，当释放准备就绪，我们覆盖了整个master历史与release-2.0历史。

解决方案＃1迫使我们解决合并与我们知道是不是需要提交冲突，但解决方案＃2迫使我们擦拭全master分支，由release-2.0分支的历史上每一个版本替换它。这引入了一些丢失错误修复的机会，我们忘记了在release-2.0上的选择，并且还可以打破在发布之前支持master的错误修复。

一个功能不使其进入发行毕竟

我们创建了一个新的feature，重订上release-2.0，并与--no-ff合并为release-2.0。
发现了一些错误，所以我们在feature上修复它们并重新执行上述合并过程。
客户再次审查该功能，决定他们想要改变很多事情 - 没有这些功能，该功能没有价值，但我们无法对release-2.0进行这些更改，并且必须等到release-3.0。

什么是处理这种情况的正确方法？我们是否应该恢复与在release-2.0中完成的功能相关的所有提交，并显示一条消息，如“恢复功能X - 推回到3.0”，然后再合并feature到release-3.0？

来源

2017-08-03 plalx

好像这里有多个问题，这两者都是主要处理意见。是否有可能缩小问题的焦点并将其作为一个技术问题重新说明？ – larsks

@plalx你有答案解决你的问题吗？如果是，您可以将其标记为答案。这将有利于其他有类似问题的人。 –

首先，如果你无论是在release-2.0和master分行变更模块A，并且要在master应用模块A的更改您的release-2.0分支。

除了列出的解决方案1和解决方案2之外，还有另一种方法可以将模块A的更改从master更改为release-2.0。即直接从master结算到release-2.0的相关文件，然后提交更改。如下具体步骤：

git checkout release-2.0 
git checkout master /path/to/moduleA 
# Such as git checkout master moduleA/* 
# Now module A is what you changed in master 
git commit

二，在大多数情况下，如果你使用的版本格式x.y（MAJOR.MINOR），x（主要）表示由客户所要求的主/显著的变化， y（次要）意味着我们修复错误或客户在审核您所做的工作时不需要做任何修改。

因此，如果您的客户在审核2.0版本时提出大的更改请求，则可以将该项目开发为版本3.0。完成作品后，您的客户将会查看3.0的版本。如果他们报告3.0版本的bug或微小更改，则可以将版本更改为3.1（在完成更改后，将release-3.0分支重命名为release-3.1或添加标记3.1）。

此外，有another different branching module你可以参考：适用于develop分支 - >当完成工作 - >合并develop到release分支 - >的release分行获得批准后/审查 - >合并release为master分支 - >在标签中记录发布版本。

来源

2017-08-04 02:00:44

我会建议使用标签而不是分支来表示什么是生产。这样，您可以简单地检出一个新的修补程序分支并修复错误，然后直接部署该提交并将其标记为当前生产代码，如果知道所有内容都将更改下一个版本，则无需将其合并。

* 54c82e0 - (HEAD -> master) Commit6 
* bb6db8e - Commit5 
* 5156c9f - Commit4 
| * 630a150 - (tag: v1.1) Hotfix commit 
|/ 
* db5c984 - (tag: v1.0) Commit3 
* 00c6c5c - Commit2 
* 715412a - Commit1

你会用你是有计谋的分支模型，但主反而是你的“主干”，在那里所有的工作合并，而目前生产的代码将始终有一个标签，你可以检出您是否需要修补程序。

我会小心的选择一个像GitFlow这样的“已被证实”的分支模型，所以我认为你是在正确的轨道上，试图找出适合你的需求的东西。欲了解更多，可以参阅：

来源

2017-08-04 05:48:54 sp1nakr

嗯，我实际上试图实现基于主干的开发，而不是GitFlow;） – plalx

听起来不错！尽管如果您试图实现更流畅的分支模型，释放分支并不是必需的。基于Trunk的几乎删除了所有多余的分支，例外是用于pull请求和代码审查等的功能分支。 – sp1nakr

在我的情况下，我们只需要短暂的发布分支来准备发布本身（例如，我们可能需要删除一些功能在掌握，但应该只在未来的版本中以某种方式部署 - 类似的事情）。 – plalx

Git分支模型：几个问题

回答

相关问题