电影和电视把节目描绘成一种疯狂的活动。**的计时器倒计时，那个书呆子的伙伴在那之前一直是个累赘，他在笔记本电脑上狂热地工作。代码在屏幕上飞过，直到她用一个令人满意的咔嗒声敲响了最后一个回车键！计时器停了，世界又恢复了正常。但编程不是这样的。它包括设计文档、UI模型和代码评审。最重要的是，它涉及到反复试验，尤其是如果你是一个初学者（像我一样）。

现在，您可能已经确信将编码项目保持在源代码控制中的价值。将所有这些尝试和错误提交到您的存储库将导致一个庞大而不整洁的项目，并且有许多修订。你所做的大多数承诺都会包含已损坏的内容，那么为什么要保存它呢？git分支特性有助于将所有这些混乱的代码与您所知道的有用的东西隔离开来。

在本文中，我们将研究代码分支的含义、方法以及管理“main”分支更新的方法。

创建git分支

通过对源代码管理的介绍，我们了解到您可以在终端中使用以下命令创建新的存储库：

git init

当您这样做时，它会在您当前的路径中创建一个名为“.git”的隐藏目录。如果您看不到它，请参阅我们之前关于查看隐藏文件的一些文章。此目录包含保存文件修订历史记录所需的所有信息。一旦您将文件管理器设置为显示隐藏文件，就可以打开.git文件夹并看到许多子目录。其中一个称为“refs”（如下图所示），其“heads”子目录包含项目中所有分支的列表。一开始你只有一个，叫做“大师”

refs目录保存分支的记录，但不保存分支本身。至少，不是你现在使用的分支。这些文件保存在工作目录中（在上面的例子中是“~/Temp/post-programming git-branch”），因此您可以以正常的方式访问它们。正是这样，我们创建了第一个文件（名为“first-文件.txt），即在.git目录之外。使用上一篇git简介文章中的trusty命令检查这一点：

现在我们可以看到工作目录有两个文件，一个是我们提交的，另一个是git自动创建的（它包含我们刚刚输入的提交消息）。

现在，让我们创建一个名为“testing”的新git分支：

git branch testing

检查分支机构，并在其中工作

我们可以在不使用任何名称的情况下发出上述命令，以获取所有分支的列表，以及当前正在使用的分支（即“签出”的分支）：

现在，如果我们检查目录结构，我们将看到“.git/refs/heads”现在有两个文件，分别用于“master”和“testing”

每一个都是组成分支的提交列表。例如，如果我们使用“gitlog”命令检查“master”分支，我们可以看到对该分支的每个提交都有一行。

“签出”分支的过程意味着您对文件所做的更改将是该分支的一部分，而不是其他分支的一部分。例如，假设我们使用以下命令签出测试git分支：

git checkout testing

然后我们在第一行中添加一行文本-文件.txt，当然是事后提交。如果切换回主分支，您会发现文件仍然为空（cat命令在终端中显示文件的内容）：

但是回到“testing”分支，该文件仍然有添加的文本：

但是我们在目录中看到的只是一个文件“first”-文件.txt“那么，同一个文件的这两个备用版本在哪里呢？.git目录解释了这些更改，但不是您所期望的那样。

git如何存储东西

如果您要检查其他版本控制系统（如Subversion）的存储库，您会发现它们为每个单独的文件维护每个版本的一个副本。这意味着如果您拥有一个文件的存储库，然后创建两个分支，则repo包含该文件的两个不同副本。实际上，您实际上使用“svn copy”作为命令在Subversion中创建分支！另一方面，git基于“变化”的概念进行操作

上面的输出告诉我们“trunk”（SVN版本的“master”）的全部内容都被复制了。查看文件管理器可以确认这一点：

“.git/objects”目录保存了所有这些小更改，每个更改都用一个ID进行跟踪。例如，在下图中，您将看到具有长ID样式名称的文件。每个文件夹都位于一个名为两个十六进制字符（下面是8c和8d）的文件夹中。

这些文件夹和文件名一起构成了特定更改的ID（实际上是SHA1散列）。您可以使用git cat file命令浏览它们的内容。根据他们修改过的日期，我们可以看到以“8d”开头的那个先出现了，它什么也没有显示。而以“8c”开头的包含我们在“testing”分支中添加到文件中的文本行。

要点是git分支（包括默认的“master”）不是包含文件副本的单独的“文件夹”。相反，它们是随着时间推移对文件所做更改的列表。这在存储方面效率更高，但结果是一样的。你做了什么（打破？）在git中，分支会一直保留在那里，直到您合并它。

合并回主分支的策略（删除还是不删除？）

假设您有一个现有的项目，其中包含许多文件，然后您将这些文件扩展到“测试”，并对其进行了一些工作。现在您需要将这些更改返回到“主”分支中。您可以从“主”分支执行以下操作：

git merge testing

如果没有冲突，由新文本组成的更改将应用于“master”，结果是“first”-文件.txt“在两个分支中都是相同的。然而，从来没有真正的替代版本的文件。

现在问题来了，怎么处理这个分支？与分支机构打交道有两种常见的策略。

1. 一种是保留一个git分支，比如“testing”，以便在中运行（如上图所示）。你试着做一些事情，如果你能让它们工作的话，把修改合并回“master”中，然后你就可以结束对那个分支的工作，甚至完全摆脱它。这意味着您的“master”是最稳定的代码版本，因为它应该只包含您知道可以工作的内容。您也可以将这种方法视为使用“功能分支”，这是因为它们的目的是细化代码中的一个（或多个）特定的附加内容。
2. 另一种方法是在“主”分支中完成所有的主要工作，并在此过程中做出承诺。一旦你对这个功能满意了，你就可以在里面创建一个分支来修复bug等等。这将导致更多的“发布分支”（如下所示），因为它们以发布结束。这也意味着“主”分支通常是最不稳定的代码版本。

用最适合你的方法

这里的第一种方法在使用git时更为常见。它的其他特性（特别是标记）使得将代码的特定快照标记为“稳定”变得很容易，它也更适合于更大的协作项目。但是当你在自己的个人项目上工作时，请随意使用其中对你最有意义的一个。使用git最大的好处是，您可以捕获所有更改，这样您就可以随时返回并找到一些东西。用git分支组织你的项目会让这变得更容易。

你如何在你的项目中接近分支机构？你用它们做实验，然后再把它们扔掉吗？或者它们代表了你在这个项目上工作的详细历史？

如果你在git项目中有任何处理分支的聪明方法，请在下面的评论中告诉我们！