如何使用git发布版本控制版本

我有一个小小的项目，用Git维护它的版本控制。这里的术语版本控制指的是你可以想象到的最简单的形式：只在主分支上并且在一天结束时产生提交，将所有提交推送到远程。目前为止这么好。只需要一个主分支就足够了，因为应用程序的最新状态一直都是需要的。如何使用git发布版本控制版本

然后，采购员告诉我他们需要v1.1和v1.2。问题是最新的主提交包含v1.1的所有内容，以及v1.2的一些撤消内容。

我的第一意图是找到两个'功能包'分歧的基础提交。我从那个提交创建了两个分支，我开始逐个挑选基础上的提交。幸运的是，其中并没有太多。这导致两个分支（V1.1和V1.2）保持在适当的合适的东西，除了我，因为在1.1版的功能还需要在V1.2变基V1.2到V1.1

这一切后，我有以下病史：

enter image description here

正如你所看到的，我有一个“悬”分支，它是主，其实，我并不需要这些提交，因为所有的他们被挑选到正确的地方。

问题简单的是：如何优雅地处理这种情况（基本上除去那些不必要的提交）而不会造成任何伤害，或者有没有其他办法可以达到同样的效果？

来源

2013-09-24 Szilárd Németh

Mercurial VCS项目使用一个单独的'stable'分支，其中用于下一发行版本的所有提交都合并到该分支中。任何旨在用于发布版本的修补程序都将被提交给该“稳定”分支，并最终被合并到主干（或“默认”分支）中。所有新的，可能是后向不兼容的变化都被转移到主干上。（请注意：我*不*建议使用汞;我通知用户部分他们的工作流程如何。） – Isxek

今年在ThatConference上有一个非常好的演讲（幻灯片可在链接中）：http://www.thatconference.com/sessions/speaker_188主持人有这个问题，并描述了她如何用git解决它。

基本上，你真的不应该在你描述的工作流中工作以达到你想要的。更好的方法是让存储库中的每个分支代表单个功能。然后，您将这些功能绑定到主合并分支或合并分支的合并提交中，并使用您的版本号对其进行标记。由于这听起来毫无帮助（显然你已经用你当前的工作流程创建了你的历史记录），它可能对未来有用。

来源

2013-09-24 21:59:56

我认为，最好的解决方案，我希望我已经unterstand它正确是git rebase

以下是关于rebase分支的一些信息。

另一个很酷的解决方案来获得工作流程，你应该看看gitflow。

来源

2013-09-24 22:00:18 Stony

+1 for gitflow。但您忘记链接主要文章：http://nvie.com/posts/a-successful-git-branching-model/ – eckes

这听起来像你看到这不是一个理想的情况下。不用担心，但解决方案很简单。

如果能够拿出一把斧头，然后开始砍掉主控器上的大量不同提交，然后将您的工作重新合并到主控中，那将是非常好的。不幸的是，我怀疑这对任何同事都会很好，因为当他们尝试将他们的更改合并到主分支时，这会导致冲突（可能甚至是字面上的冲突）。因此，不要重写历史记录，最好是制作新提交。

首先通过运行git checkout master移动到主分支。
然后，从您项目的根目录运行git checkout -f <commit> .，其中<commit>表示提交的SHA哈希值，其中消息“测量列表单元格渲染器中的活动pst颜色已更改”（例如类似于：7cd052c）。注意最后一点，它表示从指定的提交中检出当前目录的版本。
最后一步改变了工作目录中的文件，以反映它们在共同祖先发生分歧的地方所处的状态。现在，让我们通过git commit -a来承诺。
此时，您应该可以无任何冲突地合并回主人：git merge v12。

从现在开始，您可以合并您对主分支所做的任何其他更改！

来源

2013-10-15 07:43:21

如何使用git发布版本控制版本

回答

相关问题