是否可以在执行git-commit之后执行git-rebase

Question

我开始从NASM源文件重写一些Perl程序。我已经对自己的working copy做了一些提交，我在想，如果我应该做git pull，我是否应该这样做而不是做git rebase。

我几乎已经决定我应该做一个git rebase，但是我不知道如何修改我的存储库来实现这个效果，或者即使它是可能的。

​

​

Answer 1

这是可能的，Git Magic教程将解释如何做到这一点。但是，如果其他人看到了你的分支，那么它就是不安全的。即使没有人见过您的分支，我也要敦促您重新考虑。

为什么要改变基数？为什么不直接拉/合并呢？

rebasing的目的是重写历史，以便您的存储库反映您认为您的软件应该发展的方式，而不是它实际发展的方式。什么时候这很重要？当您是分布式开发团队的初级成员时，您没有提交权限-相反，您所能做的就是将补丁提交给看门人，并希望它们被接受。为了最大化接受的机会，您希望重写历史，以使您的补丁尽可能干净和清晰。开发模型听起来熟悉吗？

Manoj Srivastava写了一个fairly thoughtful analysis of rebase-vs-merge。

Answer 2

在过去，我已经成功地使用了以下方法：

对于此方法，我添加了以下别名：

up = pull --rebase origin

1. 当您完成添加和提交更改时，将您的主分支分支到类似'dev‘或任何
2. 在开发
3. 中工作的内容
4. git up主

<代码>H110切换到主<代码>H211<代码>H112git合并开发<代码>H213<代码>H114git推送<代码>H215<代码>G216

从远程存储库引入更改时：

1. switch to master
2. git up
3. switch to dev
4. git up master

<代码>G226

YMMV

Answer 3

Head^确保当前提交是合并提交：git log

• First我们将主节点重新设置为前一次提交(合并前的提交)：git reset HEAD^
• HEAD^表示：‘HEAD'

引用的提交之前的提交

​

现在你可以做一个普通的rebase了: git rebase origin/master

下一次，我建议做一个git fetch，然后按照步骤3进行rebase。

我建议为你当前的git repo创建一个小的tarball，以防rebase出错。当你感觉更自信的时候，你就不会经常这样做了(通常你可以用git解决几乎所有的问题，但有时tarball会更快)。