如何使用Git分支来构造您的编程项目

现在，您可能已经确信将编码项目保留在源代码管理中的价值。将所有这些尝试和错误提交到您的存储库将使项目变得庞大而混乱，并进行了许多修订。您所做的大多数提交都会包含损坏的内容，那么为什么要保存它呢？ git branch 功能可以帮助使所有这些凌乱的代码远离您所知道的工作。

在本文中，我们将研究分支代码的含义，如何执行

我们从源代码管理入门中学到，您可以在终端中使用以下命令创建新的存储库：

执行此操作时，它将在当前路径中创建一个隐藏目录，称为“ .git"。如果看不到该目录，请查阅我们先前有关查看hidden的文章。该目录包含保留文件修订历史记录所需的所有信息。将文件管理器设置为显示隐藏文件后，您可以打开.git文件夹并查看许多子目录。其中之一称为“ 引用"（如下图所示），其“ heads "子目录包含项目中所有分支的列表。一开始，您只有一个被称为“ master"。

refs目录保留分支的记录，而不保留分支本身的记录。至少不是您当前正在使用的分支。这些文件保存在工作目录中（在上例中为“〜/ Temp / post-programming-git-branch" ），因此您可以通过常规方式访问它们。为此，我们在工作目录即.git目录的 outside 中创建了我们的第一个文件（名为“ first-file.txt"）。使用前面的git简介中的可信赖命令检查此内容：

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

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

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

每个文件都是构成分支的提交列表。例如，如果我们使用“ git log "命令检查“ master"分支，则可以看到对该分支所做的每个提交的一行。

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

然后将一行文本添加到first-file.txt中，然后再提交。如果切换回master分支，则会发现文件仍为空白（ cat 命令在终端中显示文件的内容）：

，但返回到在“测试"分支中，该文件仍然具有添加的文本：

但是，我们在目录中仅看到的是单个文件“ first-file.txt"。那么，这两个替代版本在哪里相同的文件？ .git目录说明了这些更改，但不是您期望的那样。

如果要检查其他版本控制系统（例如Subversion）的存储库，您会发现它们每个维护一个副本。每个文件的修订版。这意味着，如果您有一个文件的存储库，然后创建两个分支，则回购包含该文件的两个不同副本。实际上，您实际上使用“ svn copy"作为命令在Subversion中创建分支！另一方面，git在“更改"的概念上运行。

上面的输出告诉我们“ trunk"（SVN的“ master"版本）的全部内容已被复制。在文件管理器中查看时可以确认：

“ .git / objects "目录包含所有这些小的更改，并且每个跟踪都有一个ID。例如，在下图中，您将看到具有长ID样式名称的文件。每个文件夹都位于一个以两个十六进制字符命名的文件夹中（以下为 8c 和 8d ）。

这些文件夹和文件名共同构成了ID进行特定更改（实际上是SHA1哈希）。您可以使用 git cat-file 命令浏览它们的内容。根据他们的修改日期，我们可以看到第一个开始的“ 8d"出现了，但没有任何显示。虽然开头的“ 8c"包含我们在“测试"分支中添加到文件中的文本行。

要点是，git分支（包括默认的“ master"）不是分开的包含文件副本的“文件夹"。相反，它们是随时间对文件进行的更改的列表。这是更有效的存储方式，但结果是相同的。您在git分支中所做的任何操作（中断？）都将保留在该位置，直到您将其合并为止。在...上下功夫。现在，您要将这些更改返回到“ master"分支中。您可以在“主"分支中执行以下操作：

如果没有冲突，则将应用由新文本组成的更改 >转到“ master"。结果是“ first-file.txt"在两个分支中都相同。但是从来没有真正替代过文件的版本。

现在是一个问题，如何处理分支？有两种常见的处理分支的策略。

  • 一种方法是保持git分支（如“测试"）在其中玩耍（如上所示）。您可以尝试一些方法，如果可以使它们起作用，则将更改合并回“ master"。然后，您可以结束该分支上的工作，甚至完全摆脱它。这意味着您的“母版"是该代码的最稳定的版本，因为它仅包含您知道的工作内容。您还可以将这种方法视为使用“功能分支"。这是因为它们的目的是优化代码中的一个（或几个）特定附加内容。
  • 另一种方法是完成所有主要工作在“ master"分支中，一路提交。对功能满意后，您可以在其中创建一个分支，进行错误修复等。这导致更多的“发布分支"（如下所示），因为它们以发布结束。这也意味着您的“主"分支通常是代码的最不稳定版本。

    • 使用最适合您的方法

    第一种方法这在使用git时更常见。它的其他功能（特别是标签）使将代码的特定快照标记为“稳定"变得容易。它也更适合大型协作项目。但是，当您处理自己的个人项目时，请随意使用对您而言最有意义的任何一种。使用git的好处是，您可以捕获所有更改，因此您随时可以返回并找到一些东西。并且使用git分支来组织项目使事情变得更容易。

    您如何在项目中使用分支？您是否使用它们进行实验，然后将其丢弃？还是它们代表了您在该项目上工作的详细历史？

    标签: