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

Question

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

同样，当我执行 git fetch 而不是 git pull 时，这意味着什么？

另外，与 merge 相比，rebase 意味着什么？

我怎样才能将个人的承诺压缩在一起？

它们如何使用、为什么使用以及它们代表什么？

GitHub 如何发挥作用？

Answer 1

Git

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

本地存储库

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

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

Git 根本不会“锁定”文件，从而避免了编辑时的“独占锁定”功能（例如 pvcs 之类的旧系统），因此所有文件始终可以编辑，即使在离线状态下也是如此。实际上，它在拉取或获取/推送到远程存储库（例如 GitHub）期间将文件更改（在同一文件内！）合并在一起方面做得非常出色。唯一需要手动更改（实际编辑文件）的情况是两个更改涉及相同的代码行。

---

分支

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

分叉：使用分支，您可以控制和管理分支，而使用分叉，其他人可以控制接受代码返回。

一般来说，有两种主要的方法来执行分支。第一个是将大部分更改保留在主分支上，仅将分支用于更大且运行时间更长的事情，例如版本更改，您希望有两个分支可用于不同的需求。第二种方法是，您基本上为每个功能请求、错误修复或杂务创建一个分支，然后手动决定何时实际将这些分支合并到主主分支中。虽然这听起来很乏味，但这是一种常见的方法，也是我目前使用和推荐的方法，因为这可以使主分支保持干净，并且它是我们升级到生产的主分支，所以我们只需要通过变基和测试完成的、经过测试的代码分支的合并。

将分支引入 master 的标准方法是进行合并。分支也可以“重新定位”以“清理”历史记录。它不会影响当前状态，而是为了提供“更干净”的历史记录。

基本上，这个想法是你从某个点（通常是从master）分支。自从你分支以来，“master”本身就从那个分支点向前移动了。如果您在分支中所做的所有更改都与 master 的当前状态及其所有最新更改相对应，那么它将变得“更干净”（更容易解决问题，历史记录也更容易理解）。所以，过程是：保存更改；获取“新”主控，然后再次应用（这是变基部分）更改。请注意，变基就像合并一样，可能会导致您必须手动解决（即编辑和修复）的冲突。

需要注意的一项准则：
仅当分支是本地且您尚未将其推送到远程时才进行变基！
这主要是因为变基可以改变其他人看到的历史记录，其中可能包括他们自己的提交。

跟踪分支

这些是名为 origin/branch_name 的分支（而不是仅 branch_name）。当您将代码推送到远程存储库或从远程存储库拉取代码时，这实际上就是发生这种情况的机制。例如，当您git Push一个名为building_groups的分支时，您的分支首先进入origin/building_groups，然后进入远程存储库。同样，如果您执行 git fetchbuilding_groups，检索到的文件将放置在您的 origin/building_groups 分支中。然后，您可以选择将此分支合并到本地副本中。我们的做法是始终执行 git fetch 和手动合并，而不仅仅是 git pull （一步完成上述两项操作）。

获取新分支。

获取新分支：在克隆的初始点，您将拥有所有分支。但是，如果其他开发人员添加分支并将它们推送到远程，则需要有一种方法来“了解”这些分支及其名称，以便能够在本地将它们拉下来。这是通过 git fetch 完成的，它将使用跟踪分支（例如，origin/）将所有新的和更改的分支获取到本地存储库中。一旦fetched，人们可以gitbranch --remote列出跟踪分支，并git checkout [branch]实际切换到任何给定的分支。

合并

合并是合并来自不同分支或同一分支的不同版本的代码更改的过程（例如，当本地分支和远程分支不同步时）。如果一个人在一个分支中开发了工作，并且该工作已经完成、准备就绪并经过测试，那么它可以合并到master分支中。这是通过 git checkout master 切换到 master 分支，然后 git merge your_branch 来完成的。合并会将所有不同的文件以及甚至同一文件的不同更改合并在一起。这意味着它实际上会更改文件内的代码以合并所有更改。

在执行 master 的 checkout 时，还建议执行 git pull origin master 将远程 master 的最新版本合并到您的本地大师。如果远程主服务器发生变化，即向前移动，您将在 git pull 期间看到反映这一情况的信息。如果是这种情况（master 已更改），建议您git checkout your_branch，然后将其rebase 为 master，以便您的更改实际上在 '新的主人。然后，您将继续使 master 保持最新状态，如下一段所示。

如果不存在冲突，那么 master 将添加新的更改。如果存在冲突，则意味着相同的文件在相似的代码行周围有更改，因此无法自动合并。在这种情况下，git merge new_branch 将报告存在需要解决的冲突。您可以通过编辑文件（其中将包含两个更改），选择所需的更改，逐字删除不需要的更改行，然后保存文件来“解决”它们。更改用分隔符标记，例如 ======== 和 <<<<<<<<<<<<。

解决所有冲突后，您将再次 git add 和 git commit 这些更改以继续合并（在此过程中您将获得 git 的反馈来指导您） 。

当该过程无法正常工作时，您会发现 git merge --abort 可以非常方便地重置内容。

交互式变基和压缩/重新排序/删除提交

如果您已经完成了许多小步骤的工作，例如，您每天将代码作为“正在进行的工作”提交，您可能希望将这些许多小提交“压缩”为一个很少有较大的提交。当您想与同事一起进行代码审查时，这尤其有用。您不想重播您采取的所有“步骤”（通过提交），您只想说这是我在一次提交中对这项工作所做的所有更改的最终效果（差异）。

在考虑是否这样做时要评估的关键因素是多次提交是否针对同一文件或多个文件（在这种情况下最好压缩提交）。这是通过交互式变基工具完成的。该工具可让您压缩提交、删除提交、改写消息等。例如，git rebase -i HEAD~10（注意：这是 ~，而不是a -) 会显示以下内容：

但要小心并“小心”地使用这个工具。一次执行一个压缩/删除/重新排序，退出并保存该提交，然后重新输入该工具。如果提交不连续，您可以对它们重新排序（然后根据需要进行压缩）。实际上，您也可以在这里删除提交，但是当您这样做时，您确实需要确定自己在做什么！

分叉

Git 存储库中有两种主要的协作方法。第一个，如上所述，是直接通过人们拉动和推入的分支。这些协作者的 SSH 密钥已在远程存储库中注册。这将使他们直接推送到该存储库。缺点是您必须维护用户列表。
另一种方法 - 分叉 - 允许任何人“分叉”存储库，基本上是在自己的 Git 存储库帐户中制作本地副本。然后，他们可以进行更改，并在完成后发送“拉取请求”（实际上，这更多的是来自他们的“推”和对实际存储库维护者的“拉”请求）以使代码被接受。

第二种方法使用分叉，不需要某人维护存储库的用户列表。

---

GitHub

GitHub（远程存储库）是一个远程源，如果您拥有（或添加到）这样的存储库，您通常会推送和拉取这些已提交的更改，因此本地和远程实际上是截然不同的。考虑远程存储库的另一种方式是，它是位于远程服务器上的 .git 目录结构。

当您“分叉”时 - 在 GitHub Web 浏览器 GUI 中，您可以单击此按钮 - 您创建一个复制（“克隆”）您的 GitHub 帐户中的代码。第一次执行此操作时可能会有点微妙，因此请务必查看代码库列在谁的存储库下 - 原始所有者或“分叉自”以及您，例如，如下所示：

一旦您拥有本地副本，您就可以根据需要进行更改（通过将它们拉取并推送到本地计算机） 。完成后，您向原始存储库所有者/管理员提交“拉取请求”（听起来很花哨，但实际上您只需单击此： ），然后他们将其“拉”进去。

对于一起处理代码的团队来说，更常见的是“克隆”存储库（单击存储库主屏幕上的“复制”图标）。然后，在本地输入 git clone 并粘贴。这将在本地进行设置，您还可以推送和拉取到（共享）GitHub 位置。

克隆

正如 GitHub 上的部分所示，克隆是存储库的副本。当您拥有远程存储库时，您可以针对其 URL 发出 git clone 命令，然后您最终会得到该存储库的本地副本或克隆。这个克隆拥有一切，文件、主分支、其他分支、所有现有的提交、整个 shebang。您可以针对此克隆进行添加和提交，然后将这些提交推送到远程存储库本身。正是这种本地/远程概念使 Git（以及类似的系统，例如 Mercurial）成为 DVCS（分布式版本控制系统），而不是更传统的 CVS（代码版本控制系统），例如 SVN， PVCS、CVS 等，您可以在其中直接提交到远程存储库。

可视化

核心概念的可视化可以参见
http://marklodato.github.com/visual-git-guide/index -en.html 和
http://ndpsoftware.com/git-cheatsheet.html#loc=index

如果您想要直观地显示更改的效果，那么您无法击败可视化工具 gitg（适用于 macOS 的 gitx），它的 GUI 被我称为“地铁”地图”（尤其是伦敦地铁），非常适合显示谁做了什么、事物如何变化、分歧和合并等。

您还可以使用它来添加、提交和管理您的更改！

尽管 gitg/gitx 相当小，但 GUI 工具的数量仍在不断增加。许多 Mac 用户使用 Brotherbard 的 gitx 分支，而对于 Linux，smart-git 是一个不错的选择，它具有直观而强大的界面：

请注意，即使使用 GUI 工具，您也可能会做很多事情命令行中的命令。

为此，我的 ~/.bash_aliases 文件中有以下别名（从每个终端会话的 ~/.bashrc 文件中调用）：

# git
alias g='git status'
alias gcob='git checkout -b '
alias gcom='git checkout master'
alias gd='git diff'
alias gf='git fetch'
alias gfrm='git fetch; git reset --hard origin/master'
alias gg='git grep '
alias gits='alias | grep "^alias g.*git.*$"'
alias gl='git log'
alias gl1='git log --oneline'
alias glf='git log --name-status'
alias glp='git log -p'
alias gpull='git pull '
alias gpush='git push '

并且我有在我的 ~/.gitconfig 文件中遵循“git aliases” - 为什么有这些？
这样分支完成（使用 TAB 键）就可以工作了！

这些是：

[alias]
  co = checkout
  cob = checkout -b

用法示例：git co [branch] <- 分支的制表符补全功能将起作用。

GUI 学习工具

您可能会发现 https://learngitbranching.js.org/ 对于学习一些基本概念很有用。屏幕截图：
视频：https://youtu.be/23JqqcLPss0

最后，7 个关键救星！

1. 您进行更改、添加并提交它们（但不要推送），然后哦！你意识到你已经掌握了！

    git reset [文件名]
    git checkout -b [新分支的名称]
    git add [文件]
    git commit -m“一条有用的消息”
   
    瞧！您已将“master”提交移至其自己的分支！
   

2. 您在本地分支工作时弄乱了一些文件，只想返回到上次执行 git pull 时的状态：

    git reset --hard origin/master # 您需要轻松地执行此操作！
   

3. 您开始在本地进行更改，您编辑了半个文件十几个文件，然后，哦，糟糕，你仍然在主（或另一个）分支中：

    git checkout -b new_branch_name # 创建一个新分支
    git 添加 . # 添加更改文件
    git commit -m"your message" # 并提交它们
   

4. 你搞乱了当前分支中的一个特定文件，并且想要基本上“重置” ' 该文件（丢失更改）为您上次从远程存储库中提取它时的样子：

    git checkout your/directories/filename
   

   这实际上会重置文件（像许多 Git 命令一样，它的名称并没有很好地说明它在这里所做的事情）。

5. 您在本地进行了一些更改，您希望确保在执行git重置或rebase时不会丢失它们：我经常手动复制当我不确定我是否会在 Git 中搞砸或丢失重要更改时，整个项目（cp -r ../my_project ~/）。

6. 你正在变基，但事情变得一团糟：

    git rebase --abort # 放弃交互式变基和合并问题
   

7. 将 Git 分支添加到 PS1 提示符中（请参阅 https://unix.stackexchange.com/a/127800/10043），例如

   

   分支是selenium_rspec_conversion。

Answer 2

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

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

http://eagain.net/articles/git-for-computer-scientists/

分叉不是Git 概念实际上，它更多的是一个政治/社会想法。也就是说，如果有些人对项目的进展方式不满意，他们可以获取源代码并独立于原始开发人员进行处理。那将被视为一个叉子。 Git 使分叉变得容易，因为每个人都已经拥有自己的源代码“主”副本，因此就像切断与原始项目开发人员的联系一样简单，并且不需要像使用 SVN 那样从共享存储库导出历史记录。

编辑：由于我不知道 GitHub 等网站使用的“fork”的现代定义，请查看评论以及

Answer 3

这是 Oliver Steele 的图像，展示了它们如何组合在一起：

Answer 4

叉子与叉子的对比克隆 - 两个词都表示复制

请参阅此图表。 _{< sup>（最初来自 http://www.dataschool.io/content/ images/2014/Mar/github1.png).}

.-------------------------.     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')

Fork

• 一个到远程仓库（云）的副本，将其链接到 Joe 的
• 一个副本，然后您就可以克隆到您的本地存储库并 F*%$-up
• 完成后，您可以推送回远程
• 来询问 Joe 是否想在他的项目中使用它

您可以通过单击拉取请求克隆

• 复制到您的本地存储库（硬盘）

Answer 5

只是为了向其他人添加一个专门针对分叉的注释。

很高兴认识到从技术上讲，克隆存储库和分叉存储库是同一件事。做：

git clone $some_other_repo

你可以拍拍自己的背——你刚刚分叉了一些其他的仓库。

Git 作为一个 VCS，实际上就是关于克隆分叉。除了使用远程 UI（例如 cgit）“只是浏览”之外，与 git 存储库没有什么关系，不涉及在某些时候 forking 克隆存储库。

然而，

• 当有人说我分叉了 repo X 时，他们的意思是他们已经创建了
  其他地方的存储库克隆，旨在将其公开
  其他，例如展示一些实验，或应用不同的
  访问控制机制（例如允许没有 Github 访问权限但
  与公司内部帐户进行协作）。

  事实：该存储库很可能是使用其他命令创建的
  git clone，它很可能托管在服务器上的某个位置
  与某人的笔记本电脑相反，并且很可能略有不同
  格式（它是一个“裸存储库”，即没有工作树）都只是
  技术细节。

  事实上，它很可能包含不同的分支集，
  标签或提交很可能是他们第一次这样做的原因
  地点。

  （当你点击“fork”时，Github 所做的只是克隆并添加了
  Sugar：它为您克隆存储库，将其放在您的帐户下，记录
  从某处“分叉”，添加名为“上游”的远程，并且大多数
  重要的是，播放漂亮的动画。）

• 当有人说我克隆了存储库 X 时，他们的意思是他们已经创建了
  有意在笔记本电脑或台式机上本地克隆存储库
  研究它、使用它、为它做出贡献或从源代码构建一些东西
  代码。

Git 的美妙之处在于它使这一切完美地结合在一起：所有这些存储库共享 block 提交链的公共部分，因此可以安全地（参见下面的注释）在所有这些存储库之间来回合并更改您认为合适的回购协议。

---

注意：“安全”，只要您不重写链的公共部分，并且只要更改不冲突。