如何更好地处理污染git中“封闭”分支的提交？

问题描述

| 我们是公司的git的新手，来自Subversion的git，上周末我们遇到了这样的情况：存储库中有一个分支，在该分支中提交了我们未发布的分支的公共版本想要在那里。我们有：

A -> B

然后得到错误的提交将分支放在：

A -> B -> C -> D

C和D不应在该分支上。麻烦的是该分支被“关闭了”-这是我们软件的发行版本，并且不应该对该分支进行任何新的提交。 在Subversion中，摆脱这种情况的唯一方法是提交！D和！C，因此最终导致：

A -> B -> C -> D -> !D -> !C

这让我回到了B，但让我在分支的时间轴上前进，因此与分支远程存储库同步并与主存储库同步的任何人都将获得C和D，然后撤消它们以得到逻辑上相似的版本B（但不是B-称为B \'）。 我遇到了这个解决方案，它可以还原git中的提交，这似乎很理想：它将使我们的公共存储库回到

A -> B

。但这意味着在任何人的工作计算机上对该分支的任何克隆都是非常不正确的，每个人都需要重新克隆。我的修复总计为：

git checkout thebranch
git reset --hard <<commit # associated with commit B>>
git push --force

我最终走了以上链接的路线，这引起了不小的轰动： a）您可以像这样用git丢弃公共存储库中的提交历史记录，从字面上重写重写现实； b）每个人都必须重新克隆，以免冒将5英镑重新注入分支（或我们要创建的分支的新分支）的风险。 我想我应该做的：

git revert HEAD~2
git commit
git push

但是，这将使分支保留为ѭ7really，并且实际上不应在其上具有

C -> D -> E

，因为它应该关闭了。 我有三个问题： 我如何更好地进行清理？使用

revert

代替

reset

？分支机构污染的最佳实践是什么？ 恢复分支的“ 11”是否真的破坏了公共存储库中的历史记录？还是git回滚到B但保留了

C -> D

的记录，而我在某个时候恢复了回B？它肯定不会在提交日志中显示还原，但是也许我的操作记录还保存在其他地方？ 您如何处理git中的\“ closed \”分支，以使这些更改最初不会放在那儿？我们确实在提交B处将一个标签应用于存储库，并且人们应该使用branch +标签来获取发布的源，但这仍然是一件令人恐惧的事情，要使更改显示在不应包含的分支行上在提交B之后对它进行更改。从分支分支进行补丁发布的某人可能很容易错过了标签，并将

C -> D

也拉入了新分支。     

解决方法

您应该将标签用于发布（\“封闭分支\”）和用于开发的分支（\“开放分支\”）。这既是解决问题的替代解决方案（您可以仅将标记用于发布的代码），也可以作为将来防止此问题的方法。 在开发v3.1时，您可以拥有v3.1分支。 v3.1完成后，标记上一次提交，并将分支重命名为您的下一个开发分支（v3.2）。切记：Git不是Svn！分支只是指向提交的指针。删除分支不会删除提交（但是，如果这些提交未包含在另一个分支中，它们将悬挂在一起，因此在删除分支之前，您应该先做一个标签）。 如果要开发v3.1（v3.1.1）的修补程序，则可以在标记v3.1处创建分支：

git checkout -b v3.1.1 v3.1

这对于您的开发人员将更加清楚（分支用于开发，标签用于发行版），并防止再次出现此问题。   还原分支的推动力是否真的破坏了公共存储库中的历史记录？ 否。如果您已经为提交D创建了标签或分支，那么该分支仍然可以。用

git reflog

查看头部最近的变化。这些提交应该在那里。 （或

git fsck

。） 要对不使用其他版本控制系统作为理解基础的git进行很好的讨论，请尝试使用PeepCode的Git Internals。它不是免费的，但我认为除了集中式版本控制之外，了解git更好。 （Git Community Book看起来是一个不错的免费替代品。）     ,关于第二点：否；重置分支（本地或在服务器上）永远不会破坏历史记录。在git中，分支类似于仅指向特定提交的标签（当签出分支并进行新提交时，标签会自动向前移动）。重置分支仅意味着标签向后移动；提交本身将保留，但是如果没有其他分支指向它们，则它们变为“不可见”。在这种情况下，可以使用

git reflog

恢复它们，这将向您显示所有提交的哈希，即使没有分支的哈希也是如此。然后，您将看到“已删除”提交仍然存在。唯一可以破坏它们的是

git gc

（也由git本身偶尔运行），它会删除未引用的提交。 当您将分支重置到较早的位置并强制将其推入时，其他开发人员可以使用

git fetch -f origin branchname:branchname

重置其分支；无需重新克隆（但是，它们应该首先签出另一个分支，以防止索引被强制获取弄乱）。但是，如果他们对分支的提交超出了您无意间推过的提交，这将导致它们“丢失”提交（同样，可以用

git reflog

找到）。对于您来说，这可能不是问题，因为分支本来应该是关闭的，但是如果发生了，他们可以在强制提取之前创建一个新分支。那么新分支仍将指向其最新提交，,21ѭ可以将提交移植到正确的分支上。