git分支、fork、fetch、merge、rebase和clone之间有什么区别？

我想了解Git中分支、分支和克隆之间的区别

类似地，当我执行

git fetch

而不是

git pull

时，这意味着什么

另外，与合并相比，

rebase

意味着什么

我怎样才能把他们挤在一起

它们是如何使用的，为什么使用，它们代表什么

---

GitHub的作用是什么？

克隆只是存储库的副本。表面上看，它的结果相当于

svn checkout

，您可以从其他存储库下载源代码。像Subversion这样的集中式VCS和像Git这样的DVCSs的区别在于，在Git中，当您克隆时，实际上是在复制整个源存储库，包括所有历史记录和分支。现在，您的计算机上有一个新的存储库，您所做的任何提交都将进入该存储库。在您将这些提交推送到另一个存储库（或原始存储库）之前，或者在有人从您的存储库（如果可以公开访问）中提取提交之前，没有人会看到任何更改

分支是存储库中的东西。从概念上讲，它代表了一条发展的线索。您通常有一个主分支，但也可能有一个分支正在处理某些功能xyz，还有一个分支用于修复bug abc。签出分支后，所做的任何提交都将保留在该分支上，并且不会与其他分支共享，直到您将其与相关分支合并或重新设置其基础。当然，Git在谈到分支时似乎有点奇怪，除非您了解如何实现分支的底层模型。与其自己解释（我想我已经说得太多了），我将链接到Git如何建模分支和提交的“计算机科学”解释，该解释摘自Git网站：

叉子实际上不是Git概念，它更像是一个政治/社会概念。也就是说，如果一些人对项目进行的方式不满意，他们可以将源代码与原始开发人员分离，自己进行开发。这将被视为一个叉子。Git使分叉变得容易，因为每个人都有自己的源代码“主”副本，所以它只需与原始项目开发人员断开联系，而不需要像SVN那样从共享存储库导出历史

编辑：由于我不知道GitHub等网站使用的“fork”的现代定义，请查看评论以及我下面的评论以了解更多信息。

Git 这个答案包括GitHub，因为很多人也问过这个问题

本地存储库 Git（本地）有一个目录（

.Git

），您可以将文件提交到该目录，这是您的“本地存储库”。这与SVN等系统不同，在SVN中，您可以立即添加并提交到远程存储库

Git存储通过保存整个文件而更改的文件的每个版本。在这方面，它也不同于SVN，因为您可以访问任何单个版本，而无需通过增量更改“重新创建”它

Git根本不“锁定”文件，因此避免了编辑时的“独占锁定”功能（想到了pvcs等较旧的系统），因此所有文件都可以随时编辑，即使在脱机时也是如此。实际上，它在将文件更改（在同一个文件中！）合并到一个远程存储库（如GitHub）的拉取或抓取/推送过程中做了一项惊人的工作。唯一需要手动更改（实际编辑文件）的时间是两次更改涉及同一行代码

---

分支机构 分支允许您保留主代码（“主”分支），制作副本（新分支），然后在新分支内工作。如果工作需要一段时间，或者自分支创建以来主分支得到了大量更新，那么应该针对主分支进行合并或重定基址（通常是更好的历史记录和更容易解决冲突的首选）。完成后，将分支中所做的更改合并回主存储库。许多组织对每一项工作都使用分支，无论它是特性、bug还是琐事。其他组织仅将分支机构用于重大更改，如版本升级

Fork：使用一个分支，您可以控制和管理该分支，而使用Fork，其他人可以控制接受返回的代码

广义地说，有两种主要的方法来做分支。第一种方法是将大多数更改保留在主分支上，仅将分支用于更大、运行时间更长的事情，如版本更改，其中您希望有两个分支可用于不同的需要。第二种方法是，基本上为每个特性请求、bug修复或杂务创建一个分支，然后手动决定何时将这些分支合并到主分支中。虽然这听起来很枯燥，但这是一种常见的方法，也是我目前使用和推荐的方法，因为这样可以保持主分支更干净，并且我们将主分支提升到生产中，因此我们只希望通过分支的重定基址和合并来获得完整、经过测试的代码

将分支“引入”到master的标准方法是执行

合并

。分支机构也可以“重新设置”以“清理”历史记录。它不会影响当前状态，并提供“更干净”的历史记录

基本上，这个想法是从某个点（通常是从主节点）分支。自从你分支，“主”本身就从那个分支点向前移动。如果您在分支中所做的所有更改都与master的当前状态及其所有最新更改相比较，那么它将“更干净”（更容易解决问题，历史也更容易理解）。因此，流程是：保存更改；获取“新”主控形状，然后重新应用（这是重基部分）更改

git clone $some_other_repo

.-------------------------.     1. Fork     .-------------------------.
| Your GitHub repo        | <-------------- | Joe's GitHub repo       |
| github.com/you/coolgame |                 | github.com/joe/coolgame |
| ----------------------- | 7. Pull Request | ----------------------- |
| master -> c224ff7       | --------------> | master -> c224ff7 (c)   |
| anidea -> 884faa1 (a)   |                 | anidea -> 884faa1 (b)   |
'-------------------------'                 '-------------------------'
    |                 ^
    | 2. Clone        |
    |                 |
    |                 |
    |                 |
    |                 |
    |                 | 6. Push (anidea => origin/anidea)
    v                 |
.-------------------------.
| Your computer           |  3. Create branch 'anidea'
| $HOME/coolgame          |
| ----------------------- |  4. Update a file
| master -> c224ff7       |
| anidea -> 884faa1       |  5. Commit (to 'anidea')
'-------------------------'

(a) - after you have pushed it
(b) - after Joe has accepted it
(c) - eventually Joe might merge 'anidea' (make 'master -> 884faa1')