0

所以我在 github 上有两个分支——master 和 refactor。我在本地检查了重构，然后去了城里。在某些时候，我搞砸了并做了一个git push origin master而不是推送到原始重构，此外，直到两周后对 master 进行了进一步的有效更改后才注意到这个问题。

/我的脸

为了尝试解决问题，我在本地检查了 master ，并做了一个git revert <some tag>，它通过删除我添加的各种文件来修复 master ，依此类推。美好的结局！推给起源大师，一切都很好。继续在我的本地重构分支上工作，偶尔推动原始重构。

今天，我完成了重构的第一遍，并希望将我的更改推送到 master。我git add，，，。git commit_ git push origin refactor一切都很好。然后我尝试推送到原始大师。失败！不足为奇，由于恶作剧需要手动合并，对吧？所以我git pull origin master在我当地的重构分支中......而且一切都变得松散了。我所有的新文件都被删除了，到处都是冲突。

我认为正在发生的事情是试图应用恢复推送，并且与我应该干净地应用在主人之上的完美快乐的变化相冲突，如果只是。

所以，由于我仍然是一个 git newb，关于如何拯救我的跛足有什么建议吗？如果您可以就如何在我未来的工作流程中避免此类错误提供一些一般性指导/教育，则可以加分。谢谢！

4

2 回答 2

3

关于将来如何避免这种情况：设置push.default为upstream并且仅在git push没有进一步参数的情况下运行，除非您明确想要推送到不同的分支（我个人从未这样做过）。不要推到其他分支。签出master、合并refactor、推送。

您可能还想考虑合并中的父顺序。您的工作流程导致那里一团糟。

关于解决你的问题：你猜对了：你正在合并你的回复提交，所以这就是 git 所做的。以下是防止这种情况的方法：

  • 创建一个新的分支master-fix-revert并master检查它：

    git checkout -b master-fix-revert master

  • 还原你还原：

    git revert **SHA-of-revert-commit**

  • 检查您的refactor分支并合并您的master-fix-revert：

    git checkout refactor
git merge master-fix-revert

  • 删除临时分支：

    git branch -d master-fix-revert
于 2013-07-16T21:38:07.120 回答
0

git revert通过添加新提交来撤消更改，这些新提交应用了先前提交中所做的反向更改。当您想要撤消更改而不重写您公开推送的分支的历史记录以及其他可能已经拉入他们自己的存储库的分支时，它很有用。

如果这不是您的情况，我建议使用更直观的技术撤消更改，例如git reset. 假设您的主分支提交了 A、B、C，而您在此之上不小心提交了 D 和 E。

                       master
 A <-- B <-- C <-- D <-- E

如果 D 和 E 是您不需要的、多余的提交，您可以简单地执行以下操作：

转到本地主分支：

git checkout master

使它指向一个特定的提交，使用--hard. 这是一个非常通用的命令，提交可以是你的对象库中的任何东西，它不一定是主历史中的提交。在你的情况下：

git reset --hard <sha1 of C>

           master           
 A <-- B <-- C

然后使用强制推送到您的仓库，因为您已经重写了历史记录，因此它不是快进的：

git push origin master -f

然后，结帐重构并继续努力。如果你想从你的主分支指向的地方拾取（即额外多余的提交），你可以使用git reset它来设置它：

git checkout refactor
git reset --hard <sha1 of E>

           master      refactor
 A <-- B <-- C <-- D <-- E

这是可选的，当然，您可以决定使用其他方式，例如从新 master 分支重构并手动添加以前的修改，或者通过樱桃挑选等。

然后继续添加提交refactor，然后合并到 master 并推送 master：

git checkout master
git merge refactor
git push origin master

                            master  
                            refactor
 A <-- B <-- C <-- D <-- E <-- F

在那里，它仍然是一个非常基本的工作流程。我的建议是使用如下工具gitk：

gitk --all

尽可能多地查看不同分支上发生的情况。

于 2013-07-16T21:47:39.767 回答