我怎样才能将多个Git提交（已经推送到）发布的存储库？ [英] How can I revert multiple Git commits (already pushed) to a published repository?

问题描述

新来的git，已经搞乱了。

我已经提交并将一些更改推送到远程开发机器。
我需要恢复一个较旧的版本，但保持糟糕的进度到目前为止继续在单独的分支上工作;

我正在考虑这样做像这样：
$ b

1. 创建名为tested-thing的本地分支


2. 将本地存储库还原到其工作的状态（希望有意义的提交将有所帮助）; strong>推送到远程
$ b
3. 合并被测试的东西到开发
li>

在第3步和第5步之间，其他开发者可能会犯并推动，恐怕这可能导致合并悲剧 - 无论如何，这可能是一种合适的方式吗？

更新：
$ b 主要问题在于2）

在这里，关于主题：将工作分解为主题br锚
http://learn.github.com/p/undoing.html

他们建议：
$ b $ ol
$ git分支测试

$ git reset --hard a6b4c974

通过这样做，其他开发者仍然可以：

$ git commit （在开发分支上）

，我可以结帐合并时间。

尽管您有所有的选择，但感觉这是一种很好的方法来测试跟随。
但是，我们没有说明是否可以在推送后完成这项工作？

请注意以下几点：因为我做了这些修改，总之，迄今为止没有其他人在存储库上工作过。所以，如果我还原了工作目录，没有人会注意到。 b
$ b

您可以使用多种工作流程。重点不在于破除发布的分支中的历史记录，除非您与可能使用该分支并愿意为每个人的克隆做手术的每个人进行沟通。最好不要这样做，如果你可以避免它。

已发布分支的解决方案

值得。如果你需要开发分支马上稳定，那就这样做。您有许多工具可用于使用Git进行调试将帮助您找到正确的分支点，然后您可以还原上次稳定提交和HEAD之间的所有提交。

要么一次还原一个提交订单或使用< first_bad_commit> ..< last_bad_commit> 范围。哈希是指定提交范围的最简单方法，但还有其他符号。例如，如果您推送了5个错误提交，您可以使用以下方法恢复它们：

 ＃使用祖先表示法还原系列。 
 git revert --no-edit dev〜5..dev 
 
＃使用提交哈希恢复一个系列。 
 git revert --no-edit ffffffff..12345678 
  

这会将反转的补丁应用于你的工作目录按顺序进行，向着你熟知的提交方向倒退。使用 - no-edit 标志，在应用每个反向修补程序后，工作目录的更改将自动提交。

code> man 1 git-revert 获取更多选项， man 7 gitrevisions 指定要恢复的提交的不同方式。 / p>

或者，您可以分出HEAD，按需要的方式修复问题，然后重新合并。在此期间您的构建将被破坏，但在某些情况下这可能是有意义的。

危险区域

当然，如果您绝对确信自您的坏推送以来没有人从存储库中取出，并且如果远程是裸存储库，那么您可以执行一个非快进提交。

  git reset --hard< last_good_commit> 
 git push --force 
  

这会使reflog完整地保留在您的系统上，主机，但你的不良提交将从可直接访问的历史记录中消失，并且不会在提取时传播。您的旧修改会一直存在，直到修改版本库，但只有Git ninjas才能看到或恢复您错误提交的提交。

New to git, and already messing up.

I've commited and pushed some changes to a remote dev machine. I need to recover an older version, but keep the "bad progress" doing so far to keep working on a separate branch;

I was thinking doing it like this:

1. Create a local branch named: "tested-thing"
2. Revert local repository to the state where it worked (hopefully meaningful commits will help);

3. Push to remote

4. finish tests on tested-thing

5. Merge "tested-thing" into dev
6. Push to remote

Between steps 3 and 5 other developers may commit and push, and I'm afraid this may result on a "merge tragedy" - Anyway, may this be a proper way to go ?

UPDATE:

The main problem here resides on 2)

Here, on topic: "breaking work into a topic branch" http://learn.github.com/p/undoing.html

They suggest:

1. $ git branch test
2. $ git reset --hard a6b4c974

By doing so, other developers could still:

$ git commit (on the dev branch)

and I can checkout to test and work it out until merge time.

Despite all your options, this feels like to be a nice approach to follow. However, it's not stated if this can be done after we have pushed ?

Please note the following: Since I made those changes and I mess up the all thing, no one else have worked on the repository so far. So, if I revert the working directory, no one will notice.

解决方案

The Problem

There are a number of work-flows you can use. The main point is not to break history in a published branch unless you've communicated with everyone who might consume the branch and are willing to do surgery on everyone's clones. It's best not to do that if you can avoid it.

Solutions for Published Branches

Your outlined steps have merit. If you need the dev branch to be stable right away, do it that way. You have a number of tools for Debugging with Git that will help you find the right branch point, and then you can revert all the commits between your last stable commit and HEAD.

Either revert commits one at a time, in reverse order, or use the <first_bad_commit>..<last_bad_commit> range. Hashes are the simplest way to specify the commit range, but there are other notations. For example, if you've pushed 5 bad commits, you could revert them with:

# Revert a series using ancestor notation.
git revert --no-edit dev~5..dev

# Revert a series using commit hashes.
git revert --no-edit ffffffff..12345678

This will apply reversed patches to your working directory in sequence, working backwards towards your known-good commit. With the --no-edit flag, the changes to your working directory will be automatically committed after each reversed patch is applied.

See man 1 git-revert for more options, and man 7 gitrevisions for different ways to specify the commits to be reverted.

Alternatively, you can branch off your HEAD, fix things the way they need to be, and re-merge. Your build will be broken in the meantime, but this may make sense in some situations.

The Danger Zone

Of course, if you're absolutely sure that no one has pulled from the repository since your bad pushes, and if the remote is a bare repository, then you can do a non-fast-forward commit.

git reset --hard <last_good_commit>
git push --force

This will leave the reflog intact on your system and the upstream host, but your bad commits will disappear from the directly-accessible history and won't propagate on pulls. Your old changes will hang around until the repositories are pruned, but only Git ninjas will be able to see or recover the commits you made by mistake.

这篇关于我怎样才能将多个Git提交（已经推送到）发布的存储库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！