git 我需要在变基后执行提交吗？

Do I need to perform a commit after a rebase?

提问by Benjol

I've just rebased a feature branch onto another feature branch (in preparation for rebasing everything to the head of my master), and it involved quite a few tricky merge resolutions.

我刚刚将一个功能分支重新定位到另一个功能分支上（准备将所有内容重新定位到我的主人的头部），并且它涉及很多棘手的合并解决方案。

Is the rebase automatically saved as a commit somewhere?

变基是否自动保存为某处的提交？

Just where do those modifications live? I can't see anything in gitk, or git log --oneline.

这些修改在哪里？我在 gitk 或git log --oneline.

(Same question for when I merge back my branch after rebasing.)

（当我在 rebase 后合并我的分支时，同样的问题。）

采纳答案by P Shved

Rebase is moving commits on top of another branch. If a commit that is moved causes merge conflict, this commit is changed to reflect merge resolution.

Rebase 正在将提交移动到另一个分支之上。如果移动的提交导致合并冲突，则会更改此提交以反映合并解决方案。

The purpose of rebase is make your commits look as if they were changes to the branch you rebase onto. So the most logical way is to incorporate merge conflicts into these commits. No additional commits is required thus.

变基的目的是使您的提交看起来好像是对变基到的分支的更改。所以最合乎逻辑的方法是将合并冲突合并到这些提交中。因此不需要额外的提交。

Merge is different, because it's an explicit action of merging diverged branches together. No commits in each of branches is changed. Conflict resolution is reflected in the merge commit.

合并是不同的，因为它是将发散的分支合并在一起的显式操作。每个分支中的提交都没有改变。冲突解决反映在合并提交中。

回答by CB Bailey

Yes, successful rebases and merges make commits. They only won't make a commit of there are conflicts that need resolving, but then the output of the rebase (or merge) will tell you that this has happened and how to resolve it.

是的，成功的变基和合并会提交。他们只是不会提交需要解决的冲突，但是 rebase（或合并）的输出会告诉你这已经发生了以及如何解决它。

For a rebase, you just need to resolve the conflicts in the index and then git rebase --continue.

对于变基，您只需要解决索引中的冲突，然后git rebase --continue.

For a merge, you need to make the commit (git commit), but the fact that it's a merge will be remembered and a suitable default commit message will be supplied for you to edit.

对于合并，您需要进行提交 ( git commit)，但会记住合并这一事实，并会提供合适的默认提交消息供您编辑。

回答by VonC

In the old days (2006, before 1.5.3 and its user manual), git rebasewas presented like so:

在过去（2006，1.5.3和之前的用户手册），git rebase被提出，像这样：

A special case of cherry-pickingis if you want to move a whole branch to a newer "base" commit.
This is done by git-rebase.
You specify the branch to move (default HEAD) and where to move it to (no default), and:

• git cherry-picksevery patch out of that branch,
• applies it on top of the target,
• and moves the refs/heads/<branch>pointer to the newly created commits.

挑选樱桃的一个特例是，如果您想将整个分支移动到更新的“基础”提交。
这是由git-rebase.
您指定要移动的分支（默认HEAD）以及将其移动到的位置（无默认），并且：

• git cherry-picks那个分支的每个补丁，
• 将其应用到目标之上，
• 并将refs/heads/<branch>指针移动到新创建的提交。

So by definition, commits will be made (and no commit need to be done)

因此，根据定义，将进行提交（无需提交）

A special case of rebase is when you want to divide your work, moving (and recreating new) commits.
From the same tutorial (as an illustration of not needing any further commit after a rebase):

rebase 的一个特例是当你想要划分你的工作、移动（和重新创建新的）提交时。
来自同一个教程（作为说明在 rebase 后不需要任何进一步提交）：

Suppose you've mixed up development of two features in the current HEAD, a branch called "dev".

假设您在当前 HEAD 中混合了两个功能的开发，一个名为“dev”的分支。

x-x-x-x  (master)
       \ 
        -f1a-f1b-f1c-f2a-f2b-f2c (dev, HEAD)

You want to divide them up into "dev1" and "dev2". Assuming that HEADis a branch off master, then you can either look through

你想把它们分成“dev1”和“dev2”。假设那HEAD是 master 的分支，那么您可以查看

git log master..HEAD

or just get a raw list of the commits with

或者只是获取提交的原始列表

git rev-list master..HEAD

Either way, suppose you figure out a list of commits that you want in dev1and create that branch:

无论哪种方式，假设您找出您想要的提交列表dev1并创建该分支：

git checkout -b dev1 master
for i in `cat commit_list`; do
    git-cherry-pick $i
done

        -f1a'-f1b'-f1c' (dev1, HEAD)
       /
x-x-x-x  (master)
       \ 
        -f1a-f1b-f1c-f2a-f2b-f2c (dev)

You can use the other half of the list you edited to generate the dev2branch, but if you're not sure if you forgot something, or just don't feel like doing that manual work, then you can use git-rebase to do it for you.

您可以使用您编辑的列表的另一半来生成dev2分支，但是如果您不确定是否忘记了某些东西，或者只是不想做那些手动工作，那么您可以使用 git-rebase 来完成为你。

git checkout -b dev2 dev    # Create dev2 branch
git-rebase --onto master dev1   # Subreact dev1 and rebase

This will find all patches that are in devand not in dev1, apply them on top of master, and call the result dev2.

这将找到所有在dev和不在 中的补丁dev1，将它们应用到 master 之上，并调用 result dev2。

        -f1a'-f1b'-f1c' (dev1, HEAD)
       /
x-x-x-x  (master)
       \ 
        -f2a-f2b-f2c (dev2, HEAD)