如何解释" git pull --rebase&"简单来说? [英] How to explain "git pull --rebase" in simple terms?

问题描述

我想我了解 git pull ，这就是我用简单术语"进行解释的方式:

1. 通常来说， git pull 是关于合并一个远程"分支到一个本地"分支.
2. 更详细地讲，git使用远程"分支的内容来更新"/修改"本地"分支的内容.
3. 更详细地讲，如果在本地"分支中修改了文件，但在远程"分支中没有修改，则合并后，文件的内容将与本地"中的内容相同"分支.反之亦然.如果在远程"分支上修改了文件，但在本地"分支上没有修改，则内容将从远程"分支上获取.
4. 如果在两个分支(本地"和远程")中都修改了文件，则git将尝试从两个分支中进行修改.如果更改发生在文件的不同位置，则合并后两个更改都将应用并显示在文件内容中.
5. 如果更改发生在同一地方，那么我们将其称为合并冲突"，为简单起见，我将不涉及这种情况.
6. 由于合并，我们修改了本地"存储库，因此我们需要提交".

现在，我想对 git pull --rebase 获得相同的解释.我不想使用诸如"head"，"index"，"fetch"，"upstream"之类的术语，因为这些术语/概念只会使像我这样的初学者感到困惑.我知道我需要学习这些高级"概念，并且通过阅读教程来做到这一点，但是目前，作为学习过程的一部分，我想了解 git pull --rebase .

添加

我认为在某个时候我听到了以下解释.通过 git pull --rebase .如上所述，合并时，我们不会以对称"方式进行合并.相反，我们首先忘记"本地"存储库中的更改，仅应用远程"存储库中的更改.通过这样做，我们基本上按原样复制"了远程存储库.之后，我们将应用顶部中的本地"存储库中的更改.但是，我仍然不清楚这到底是什么意思.特别地，在顶部"是什么意思.

解决方案

我看到可以澄清的两件事:您正在关注两个分支中文件的状态，但是可以更好地考虑正在发生的事情根据已发生的变更集.第二个问题是 git pull 是两个操作的简写: git fetch 和 git merge .是的，您写道您不想使用诸如 fetch 之类的词"，但这不是一个高级概念".如果您想了解发生了什么，则需要从那里开始.

• git fetch 本质上通知它不知道的本地更改回购.

• git merge 将新到达的更改与本地更改统一起来.

要注意的是，如果两个存储库上发生的事情都没有同步，则它们可能会发散:

  ... b--o--o--o--o(远程)\x--x--x(本地) 

上面显示的是从左到右的时间；最右边的点是最新的.因此，新到达的更改是对文件较旧状态的修改，标记为"b".

• git pull ，即普通的 git merge ，将尽可能地合并两个分支的最新状态.

• git pull --rebase 将假装您所做的更改不是针对标记为"b"的状态，而是针对最新的远程状态.换句话说，它将尝试重写历史记录，使其看起来像这样:

    ... b--o--o--o--o(远程)\x--x--x(本地) 

那是区别.结果之一是，如果不重新设置基准，则回购的历史记录会包含一些状态(如果需要，您可以在将来回退到其中)应用了"x"更改而没有"o"更改的状态.重新基准化后，存储库中没有这样的位置.

I think I understand git pull and this is how I explain it in, what I call, "simple terms":

1. Generally speaking, git pull is about merging a "remote" branch into a "local" branch.
2. In more detail, git uses the content of the "remote" branch to "update" / "modify" content of the "local" branch.
3. In even more detail, if a file has been modified in the "local" branch but not in the "remote" branch, then after the merge, the content of the file will be the same as the content in the "local" branch. The opposite is also true. If a file was modified on the "remote" branch but not in the "local" branch, the content will be taken from the "remote" branch.
4. If a file was modified in both branches ("local" and "remote") than git will try to take modifications from both branches. If the changes happen on different places of the file, both changes will be applied and be present in the content of the file after the merge.
5. If the changes happen on the same place we have what is know as a "merge conflict" and I am not going to touch this case for simplicity.
6. As a result of the merge, we modify the "local" repository and therefore we need to "commit".

Now I want to get the same kind of explanation for git pull --rebase. I do not want to use such terms as "head", "index", "fetch", "upstream" because these terms / concept only confuse beginners like me. I know that I need to learn these "advanced" concepts and I do it by reading tutorials but for now, as a part of my learning process, I want to understand git pull --rebase.

ADDED

I think at some point I heard the following explanation. By git pull --rebase. When we merge, we do it not in a "symmetric" way, as described above. Instead, we first "forget" the changes in the "local" repository and apply only the changes from the "remote" repository. By doing that we basically "copy" the remote repository as it is. After that we apply the changes from the "local" repository on top. However, it is still not clear to me what exactly it means. In particular, what "on top" means.

解决方案

I see two things that could be clarified: You are focusing on the state of a file in the two branches, but a better way to consider what is going on is in terms of the changesets that have occurred. The second issue is that git pull is shorthand for two operations: git fetch, and git merge. Yes, you write that you "don't want to use words like fetch", but that's not an "advanced concept". If you want to understand what's going on, you need to start there.

• git fetch essentially informs the local repo of changes that it did not know about.

• git merge unifies the newly arrived changes with your local changes.

The catch is that if things have been happening on both repos without synchronization, they may have diverged:

... b--o--o--o--o  (remote)
     \
      x--x--x      (local)

The above shows time left to right; the rightmost point is the most recent. So the newly arrived changes are modifications to an older state of the files, the one marked "b".

• git pull, i.e. plain git merge, will merge the most recent state of the two branches as best as it can.

• git pull --rebase will pretend that your changes were made not to the state marked "b", but to the most current remote state. In other words it will try to rewrite history so that it looks like this:

  ... b--o--o--o--o              (remote)
                   \
                    x--x--x      (local)
  

That's the difference. One consequence is that if you don't rebase, the history of your repo contains some states (which you can rewind to in the future, if you want) where the "x" changes were applied but the "o" changes are absent. After rebasing, there is no such place in the repository.

这篇关于如何解释" git pull --rebase&"简单来说?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！