在git中，提取与拉取有何不同，合并与变基有何不同？

我只是不明白这一点。我在网上和书籍上看了很多书，只是有些事情一直在我脑海中浮现。有人可以给我以下的虚拟版本：

• git fetch vs拉
• git merge vs rebase

获取与拉动

fetch 将从remote *分支下载所有更改，更新存储库数据，但保持local *分支不变。

pull将执行fetch，merge并将更改附加到您的本地分支机构。

有什么不同？ pull使用拉出的分支中的更改更新您的本地分支。A fetch不会提升您的本地分支机构。

合并与变基

根据以下历史记录：

          C --- D --- E当地
         /
    A --- B --- F --- G遥控器

merge将两个发展历史联系在一起。它通过重放分支在远程分支顶部之后在本地分支上发生的更改来完成此操作，并将结果记录在新提交中。此操作保留每次提交的祖先。

a的效果merge将是：

          C --- D --- E当地
         / \
    A --- B --- F --- G --- H遥控器

rebase将接受本地分支中存在的提交，然后将其重新应用到远程分支的顶部。该操作将重写本地提交的祖先。

a的效果rebase将是：

                  本地C'-D'-E'
                 /
    A --- B --- F --- G遥控器

有什么不同？A merge不会更改提交的祖先。A rebase 重写了本地提交的祖先。

*本说明假定当前分支是本地分支，该分支指定为参数fetch，pull，merge，或rebase是一个远程分支。这是通常的情况。pull，例如，将从指定分支下载所有更改，更新您的存储库并将merge更改添加到当前分支。

提取与拉取

Git提取只是更新您的回购数据，但是git pull基本上会执行提取，然后合并提取的分支

'git pull'和'git fetch'有什么区别？

合并与变基

来自Atlassian SourceTree博客，合并或变基：

合并将两条发展线放在一起，同时保留了每次提交历史的血统。

相比之下，重新定基础通过重写源分支中的更改来统一开发线，从而使它们显示为目标分支的子级，从而有效地假装这些提交始终写在目标分支的顶部。

另外，请查看Learn Git Branching，这是一个不错的游戏，刚刚发布到HackerNews（链接到post），并讲授了许多分支和合并技巧。我相信这将在此问题上非常有帮助。

拉取与提取：

我的理解方式是，git pull只需git fetch跟在后面即可git merge。即，您从远程分支获取更改，然后将其合并到当前分支。

合并与变基：

合并将按照命令的说明进行；合并当前分支和指定分支之间的差异（合并到当前分支中）。即该命令git merge another_branch将合并another_branch到当前分支中。

rebase的工作方式略有不同，有点酷。假设您执行命令git rebase another_branch。Git首先会在当前分支和之间找到最新的通用版本another_branch。即分支分支之前的点。然后git会将这个发散点移动到another_branch。最后，从新的分歧点开始重播自原始分歧点以来当前分支中的所有提交。这将创建一个非常干净的历史记录，并且分支和合并较少。

但是，这并非没有陷阱！由于版本历史记录是“重写的”，因此仅当提交仅存在于本地git存储库中时，才应执行此操作。也就是说：如果您已将提交推送到远程仓库，则永远不要这样做。

这本在线书中对重新定基的解释非常好，并带有易于理解的插图。

拉底基而不是合并

我实际上在使用rebase很多，但通常将其与pull结合使用：

git pull --rebase

将获取远程更改，然后重新设置基础，而不是合并。即，它将重播上次执行拉取后的所有本地提交。我发现这比使用合并进行普通拉动要干净得多，这将为合并创建一个额外的提交。

合并 -HEAD分支将生成一个新的提交，并保留每个提交历史记录的祖先。如果在同一分支上并行工作的多个人进行合并提交，则历史可能会受到污染。

变基 -重新写一个分支到另一个的变化，而无需创建一个新的提交。代码历史记录是简化的，线性的和可读的，但不适用于请求请求，因为您无法看到某人进行了哪些较小的更改。

git merge在处理基于功能的工作流程或不熟悉变基的情况下，我会使用它。但是，如果我想要更干净，线性的历史记录git rebase，则更合适。有关更多详细信息，请确保查看此合并或变基文章。