如何解释“git pull --rebase”简单来说？

问题描述

我想我理解 git pull ，这就是我如何解释它，我称之为简单术语：

1. 一般而言， git pull 是关于合并远程分支到本地
   
2. 更详细地说，git使用远程分支的内容来更新/修改本地分支的内容。


3. 更详细地说，如果文件在本地分支中被修改，但在远程分支中没有被修改，则在合并之后，文件的内容将与本地分支。相反的情况也是如此。如果文件在远程分支上被修改，但在本地分支中不被修改，则内容将从远程分支中获取。


4. 如果两个文件都被修改分支（本地和远程）比git 尝试从两个分支进行修改。如果更改发生在文件的不同位置，那么这两个更改将被应用并且在合并后出现在文件的内容中。


5. 如果更改发生在同一个地方，所谓的合并冲突，我不会轻易触及这种情况。


6. 由于合并，我们修改了本地存储库，因此我们需要
   

现在我想对> git pull --rebase 。我不想使用头，索引，获取，上游等术语，因为这些术语/概念只会混淆像我这样的初学者。我知道我需要学习这些高级概念，而且我通过阅读教程来做到这一点，但现在，作为学习过程的一部分，我想了解 git pull --rebase


ADDED

我认为在某些时候我听到下面的解释。由 git pull --rebase 。如上所述，当我们合并时，我们不是以对称方式进行合并。相反，我们首先忘记本地存储库中的更改，并仅应用远程存储库中的更改。通过这样做，我们基本上复制了远程存储库。之后，我们将本地存储库上的更改应用于顶部。然而，我仍然不清楚它究竟意味着什么。特别是，上面意味着什么。

解决方案

我看到两件事情可以澄清：你关注的是状态在两个分支中的一个文件，但更好的方式来考虑发生的变化集。第二个问题是 git pull 是两个操作的缩写： git fetch 和 git合并。是的，你写你不想使用像 fetch 这样的词，但这不是高级概念。如果你想知道发生了什么，你需要从那里开始。

• git fetch 本质上通知它不知道的变化的本地回购。




• git merge 将新到达的更改与本地更改统一。

如果事情在两个回购站都没有同步的情况下发生，他们可能会发生分歧：

  ... b  -  o  -  o --o  -  o（远程）
 \ 
 x  -  x  -  x（本地）
  

以上显示时间从左到右;最右边的点是最近的点。因此，新到达的更改是对较旧状态的文件（标记为b的文件）的修改。

• git pull ，即plain git合并，将尽可能合并两个分支的最新状态。




• git拉--rebase 会假装您的更改不是标记为b的状态，而是最新的远程状态。换句话说，它会尝试重写历史记录，使其如下所示： --o - o（remote）
\
x - x - x（local）


这是区别。其中一个后果是，如果您不重新绑定，那么您的回购历史包含一些状态（如果您愿意，您可以在未来回滚），其中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”简单来说？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！