我怎样才能使用git rebase完全按照我想要的方式转换我的工作树?

时间:2011-09-27 15:08:38

标签: git git-rebase

* 080dc7a (HEAD, origin/master, origin/HEAD, master)
*   bfeee2f
|\  
| * 16e94ff (origin/McLongNumber, McLongNumber)
| *   f50319b
| |\  

这是我工作树的最后4次提交。我想重新绑定,以便我的工作树看起来像下面的例子,通过压缩最后一次提交到合并,保持树的其余部分完全按照它的方式:

*   bfeee2f (HEAD, origin/master, origin/HEAD, master)
|\  
| * 16e94ff (origin/McLongNumber, McLongNumber)
| *   f50319b
| |\  

我已尝试使用--onto -p-i但没有成功。即使在我成功压缩最后一次提交时使用-p选项,显示McLongNumber合并到主分支的树线也从日志中丢失。所以我猜一个更熟悉rebase命令的人可以帮助我解决这个问题。

1 个答案:

答案 0 :(得分:1)

你可以这样做:

# make 'master' point to it's parent commit,
# but don't modify the index or working directory
git reset --soft HEAD^

# rewrite the commit using the stuff in the index
git commit --amend

# publish the modified commit (see WARNING below)
git push -f

注意SHA1会改变;它将不再是bfeee2f

警告

重写已发布到共享存储库的历史记录几乎总是一个非常糟糕的想法。大多数共享存储库都配置为拒绝历史记录修改,即使使用-f git push选项也是如此。因此,无论如何,你可能无法做到你想做的事。

重写已发布历史记录的唯一时间是:

  • 您是唯一使用上游存储库的人,并且您知道如何从其他克隆中的历史记录重写中恢复。
  • 共享存储库的其他用户知道如何从重写的历史记录中恢复并且您已经警告他们您已经重写了历史记录并且您已经注意确保在强制推送时不会丢弃重要的更改。即便如此,重写历史对其他人来说也是极具破坏性的;这是严重惹恼你的同事/合作者/贡献者的好方法。