git git_dir分支_快速入门Git：在Git中分支

Bertha 。 2022-12-03 01:57 261阅读 0赞

git git\_dir分支

![jsgit][]

*The following is a short extract from our book, [Jump Start Git][], available for free to [SitePoint Premium members][]. Print copies are sold in stores worldwide, or you can [order them here][]. We hope you enjoy this extract and find it useful.*

*以下是我们的书[Jump Start Git][]的简短摘录， [SitePoint Premium会员][SitePoint Premium members]可以免费获得。* *印刷版在世界各地的商店都有出售，您也可以[在此处订购][order them here] 。* *我们希望您喜欢此摘录并觉得有用。*

In Chapter 1, I talked about my one-time fear of trying out new things in a project. What if I tried something ambitious and it broke everything that was working earlier? This problem is solved by the use of branches in Git.

在第1章中，我谈到了我曾经一次尝试在项目中尝试新事物的恐惧。 如果我尝试了一些雄心勃勃的尝试，但又破坏了之前所有的工作，该怎么办？ 通过在Git中使用分支解决了这个问题。

##  什么是分支机构？ **(**What Are Branches?**)** ##

Creating a new **branch** in a project essentially means creating a new copy of that project. You can experiment with this copy without affecting the original. So if the experiment fails, you can just abandon it and return to the original—the `master` branch.

在项目中创建新**分支**实质上意味着创建该项目的新副本。 您可以尝试使用此副本，而不会影响原始副本。 因此，如果实验失败，您可以放弃它并返回原来的`master`分支。

But if the experiment is successful, Git makes it easy to incorporate the experimental elements into the `master`. And if, at a later stage, you change your mind, you can easily revert back to the state of the project before this merger.

但是，如果实验成功，Git可以轻松地将实验元素整合到`master` 。 而且，如果在稍后阶段改变主意，则可以轻松地恢复到合并之前的项目状态。

So a branch in Git is an independent path of development. You can create new commits in a branch while not affecting other branches. This ease of working with branches is one of the best features of Git. (Although other version control options like CVS had this branching option, the experience of merging branches on [CVS][] was a very tedious one. If you’ve had experience with branches in other version control systems, be assured that working with branches in Git is quite different.)

因此，Git中的分支机构是独立的发展道路。 您可以在不影响其他分支的情况下在分支中创建新的提交。 与分支机构的这种易用性是Git的最佳功能之一。 (尽管其他版本控制选项(例如CVS)具有此分支选项，但是在[CVS][]上合并分支的经验非常繁琐。如果您曾经在其他版本控制系统中拥有分支的经验，请确保在Git中使用分支是相当不错的。不同。)

In Git, you find yourself in the `master` branch by default. The name “master” doesn’t imply that it’s superior in any way. It’s just the convention to call it that.

在Git中，默认情况下您会发现自己位于`master`分支中。 “大师”这个名字并不意味着它在任何方面都是优越的。 这只是惯例。

### 注意：分支约定 **(**Note: Branch Conventions**)** ###

Although you’re free to use a different branch as your base branch in Git, people usually expect to find the latest, up-to-date code on a particular project in the `master` branch.

尽管您可以随意使用其他分支作为Git的基础分支，但是人们通常希望在`master`分支中找到特定项目的最新代码。

You might argue that, with the ability to go back to any commit, there’s no need for branches. However, imagine a situation where you need to show your work to your superior, while also working on a new, cool feature which is not a part of your completed work. As branching is used to separate different ideas, it makes the code in your repository easy to understand. Further, branching enables you to keep only the important commits in the `master` branch or the main branch.

您可能会争辩说，由于能够返回到任何提交，因此不需要分支。 但是，请设想一种情况，您需要向上级展示您的作品，同时还要开发一项新的，很酷的功能，而这并不是您完成的工作的一部分。 由于分支用于分隔不同的想法，因此使存储库中的代码易于理解。 此外，分支使您可以仅将重要的提交保留在`master`分支或main分支中。

Yet another use of branches is that they give you the ability to work on multiple things at the same time, without them interfering with each other. Let’s say you submit `feature 1` for review, but your supervisor needs some time before reviewing it. Meanwhile, you need to work on `feature 2`. In this scenario, branches come into play. If you work on your new idea on a separate branch, you can always switch back to your earlier branch to return the repository to its previous state, which does not contain any code related to your idea.

分支的另一种用途是，它们使您能够同时处理多个事物，而不会彼此干扰。 假设您将`feature 1`提交进行审核，但您的主管需要一些时间才能对其进行审核。 同时，您需要研究`feature 2` 。 在这种情况下，分支开始起作用。 如果您在单独的分支上处理新想法，则始终可以切换回先前的分支，以使存储库恢复到之前的状态，该状态不包含与您的想法相关的任何代码。

Let’s now start working with branches in Git. To see the list of branches and the current branch you’re working on, run the following command:

现在让我们开始使用Git中的分支。 要查看分支列表和您正在使用的当前分支，请运行以下命令：

git branch

If you have cloned your repository or set a remote, you can see the remote branches too. Just postfix `-a` to the command above:

如果克隆了存储库或设置了远程，则也可以看到远程分支。 只需在上面的命令后缀`-a`即可：

git branch -a

![Command showing the branches in the local copy as well as the origin branch][]

Command showing the branches in the local copy as well as the origin branch

该命令显示本地副本中的分支以及原始分支

As shown above, the branches that colored red signify that they are on a remote. In our case, we can see the various branches that are present in the `origin` remote.

如上所示，红色的分支表示它们在远程上。 在我们的案例中，我们可以看到`origin`远程站点中存在的各种分支。

##  创建一个分支 **(**Create a Branch**)** ##

There are various ways of creating a branch in Git. To create a new branch and stay in your current branch, run the following:

在Git中有多种创建分支的方法。 要创建一个新分支并保留在当前分支中，请运行以下命令：

git branch test_branch

Here, `test_branch` is the name of the created branch. However, on running `git branch`, it seems that the active branch is still the `master` branch. To change the active branch, we can run the `checkout` command (shown below):

在这里， `test_branch`是创建的分支的名称。 但是，在运行`git branch` ，似乎活动分支仍然是`master`分支。 要更改活动分支，我们可以运行`checkout`命令(如下所示)：

git checkout test_branch

![Creating a new branch and making it active][]

Creating a new branch and making it active

创建一个新分支并将其激活

You can also combine the two commands above and thereby create and checkout to a new branch in a single command by postfixing `-b` to the `checkout` command:

您还可以结合上面的两个命令，从而通过在`checkout`命令后缀`-b`来在单个命令中创建并检出到新分支：

git checkout -b new_test_branch

![Create and checkout to a new branch in a single command][]

The branches we’ve just created are based on the latest commit of the current active branch—which in our case is `master`. If you want to create a branch (say `old_commit_branch`) based on a certain commit—such as `cafb55d`—you can run the following command:

我们刚刚创建的分支基于当前活动分支的最新提交(在本例中为`master` 。 如果要基于某个提交(例如`old_commit_branch` )创建分支(例如`old_commit_branch` )， `cafb55d`可以运行以下命令：

git checkout -b old_commit_branch cafb55d

![Creating a branch based on an old commit][]

Creating a branch based on an old commit

基于旧提交创建分支

To rename the current branch to `renamed_branch`, run the following command:

要将当前分支重命名为`renamed_branch` ，请运行以下命令：

git branch -m renamed_branch

##  删除分支 **(**Delete a Branch**)** ##

To delete a branch, run the following command:

要删除分支，请运行以下命令：

git branch -D new_test_branch

![Deleting a branch in Git][]

Deleting a branch in Git

删除Git中的分支

### 注意：除非必须删除，否则不要删除分支 **(**Note: Don’t Delete Branches Unless You Have To**)** ###

As there’s not really any downside to keeping branches, as a precaution I’d suggest not deleting them unless the number of branches in the repository becomes too large to be manageable.

由于保留分支实际上没有任何负面影响，为预防起见，我建议不要删除它们，除非存储库中的分支数量太大而无法管理。

The `-D` option used above deletes a branch even if it hasn’t been synchronized with a remote branch. This means that if you have commits in your current branch that have not been pushed yet, `-D` will still delete your branch without providing any warning. To ensure you don’t lose data, you can postfix `-d` as an alternative to `-D`. `-d` only deletes a branch if it has been synchronized with a remote branch. Since our branches haven’t been synced yet, let’s see what happens if we postfix `-d`, shown below:

上面使用的`-D`选项删除一个分支，即使该分支尚未与远程分支同步。 这意味着，如果您当前分支中的提交尚未被推送， `-D`仍将删除您的分支而不提供任何警告。 为了确保您不会丢失数据，可以将`-d`后缀替换为`-D` 。 `-d`仅在已与远程分支同步的情况下删除该分支。 由于我们的分支尚未同步，因此让我们看看如果将postfix `-d`如下所示，会发生什么：

![Deleting a branch in Git using the -d option][]

As you can see, Git gives you a warning and aborts the operation, as the data hasn’t been merged with a branch yet.

如您所见，由于数据尚未与分支合并，因此Git会警告您并中止操作。

###  分支机构和`HEAD` **(**Branches and `HEAD`**)** ###

Now that we’ve had a chance to experiment with the basics of branching, let’s spend a little time discussing how branches work in Git, and also introduce an important concept: `HEAD`.

既然我们已经有机会试验分支的基础知识，那么让我们花一些时间讨论分支在Git中的工作方式，并介绍一个重要的概念： `HEAD` 。

As mentioned above, a branch is just a link between different commits, or a pathway through the commits. An important thing to note is that, while working with branches, the `HEAD` of a branch points to the latest commit in the branch. I’ll refer to `HEAD` a lot in upcoming chapters. In Git, the `HEAD` points to the latest commit in a branch. In other words, it refers to the tip of a branch.

如上所述，分支只是不同提交之间的链接，或者是通过提交的路径。 需要注意的重要一点是，在使用分支时，分支的`HEAD`指向分支中的最新提交。 在接下来的章节中，我会经常提到`HEAD` 。 在Git中， `HEAD`指向分支中的最新提交。 换句话说，它是指分支的尖端。

A branch is essentially a pointer to a commit, which has a parent commit, a grandparent commit, and so on. This chain of commits forms the pathway I mentioned above. How, then, do you link a branch and `HEAD`? Well, `HEAD` and the tip of the current branch point to the same commit. Let’s look at a diagram to illustrate this idea:

分支本质上是指向提交的指针，该提交具有父提交，祖父母提交等。 这个提交链构成了我上面提到的途径。 那么，如何链接分支和`HEAD` ？ 好了， `HEAD`和当前分支的尖端指向同一提交。 让我们看一个图来说明这个想法：

![Branches and HEAD][]

Branches and HEAD

分支机构和HEAD

As shown above, `branch_A` initially is the active branch and `HEAD` points to commit C. Commit A is the base commit and doesn’t have any parent commit, so the commits in `branch_A` in reverse chronological order (which also forms the pathway I’ve talked about) are C → B → A. The commits in `branch_B` are E → D → B → A. The `HEAD` points to the latest commit of the active `branch_A`, which is commit C. When we add a commit, it’s added to the active branch. After the commit, `branch_A` points to F, and the branch follows F → C → B → A, whereas `branch_B` remains the same. `HEAD` now points to commit F. Similarly, the changes when we add yet another commit are demonstrated in the figure.

如上所示， `branch_A`最初是活动分支，并且`HEAD`指向提交C。提交A是基础提交，并且没有任何父提交，因此`branch_A`中的提交按时间倒序排列(这也构成了我已经`branch_A`的路径)谈到)为C→早→A.在提交`branch_B`正在通过电邮→d→早→答： `HEAD`指向最新提交的活跃`branch_A` ，这是犯C.当我们添加一个承诺，它的加入活动分支。 提交后， `branch_A`指向F，分支遵循F→C→B→A，而`branch_B`保持不变。 `HEAD`现在指向提交F。类似地，在图中添加了另一个提交时所做的更改。

##  高级分支：合并分支 **(**Advanced Branching: Merging Branches**)** ##

As mentioned earlier, one of Git’s biggest advantages is that merging branches is especially easy. Let’s now look at how it’s done.

如前所述，Git的最大优点之一就是合并分支特别容易。 现在让我们看看它是如何完成的。

We’ll create two new branches—`new_feature` and `another_feature`—and add a few dummy commits. Checking the history in each branch shows us that the branch `another_feature` is ahead by one commit, as shown below:

我们将创建两个新分支`new_feature`和`another_feature`并添加一些虚拟提交。 查看每个分支中的历史记录可知，该分支`another_feature`在一个提交之前，如下所示：

![Checking the history in each branch][]

Checking the history in each branch

检查每个分支的历史记录

This situation can be visualized as shown below. Each circle represents a commit, and the branch name points to its `HEAD` (the tip of the branch).

这种情况可以如下图所示。 每个圆圈代表一个提交，分支名称指向其`HEAD` (分支的尖端)。

![Visualizing our branches before the merge][]

Visualizing our branches before the merge

合并前可视化我们的分支

To merge `new_feature` with `master`, run the following (after first making sure the `master` branch is active):

要将`new_feature`与`master`合并，请运行以下命令(首先确保`master`分支处于活动状态)：

git checkout master
    git merge new_feature

The result can be visualized as shown below:

结果可以如下所示可视化：

![The status of the repository after merging new\_feature into master][The status of the repository after merging new_feature into master]

The status of the repository after merging new\_feature into master

将new\_feature合并到master之后，存储库的状态

To merge `another_feature` with `new_feature`, just run the following (making sure that the branch `new_feature` is active):

要将`another_feature`与`new_feature`合并，只需运行以下命令(确保分支`new_feature`处于活动状态)：

git checkout new_feature
    git merge another_feature

The result can be visualized as shown below:

结果可以如下所示可视化：

![The status of the repository after merging another\_feature into new\_feature][The status of the repository after merging another_feature into new_feature]

The status of the repository after merging another\_feature into new\_feature

将another\_feature合并到new\_feature后，存储库的状态

### 重要提示：当心循环 **(**Important: Watch Out for Loops**)** ###

The diagram above shows that this merge has created a loop in your project history across the two commits, where the workflows diverged and converged, respectively. While working individually or in small teams, such loops might not be an issue. However, in a larger team—where there might have been a lot of commits since the time you diverged from the main branch—such large loops make it difficult to navigate the history and understand the changes. We’ll explore a way of merging branches without creating loops using the `rebase` command in Chapter 6.

上图显示，此合并已在您的项目历史记录中跨两次提交创建了一个循环，工作流分别在此处进行了分散和融合。 在单独或以小组形式工作时，此类循环可能不是问题。 但是，在较大的团队中(自从您离开主分支以来，可能已有很多提交)，如此大的循环使得难以浏览历史记录和理解更改。 我们将在第6章中探索使用`rebase`命令合并分支而不创建循环的方法。

![The status of branch new\_feature after the merge][The status of branch new_feature after the merge]

The status of branch new\_feature after the merge

合并后分支new\_feature的状态

This merge happened without any “conflicts”. The simple reason for that is that no new commits had been added to branch `new_feature` as compared to the branch `another_feature`. **Conflicts** in Git happen when the same file has been modified in non-common commits in both branches. Git raises a conflict to make sure you don’t lose any data.

这次合并没有任何“冲突”。 这样做的简单原因是，与分支`another_feature`相比，没有向分支`new_feature`添加新的提交。 当在两个分支的非常见提交中修改了同一文件时，就会发生Git **冲突** 。 Git引发冲突，以确保您不会丢失任何数据。

We’ll discuss conflicts in detail in the next chapter. I mentioned earlier that branches can be visualized by just a simple pathway through commits. When we merge branches and there are no conflicts, such as above, only the branch pathway is changed and the `HEAD` of the branch is updated. This is called the **fast forward** type of merge.

在下一章中，我们将详细讨论冲突。 前面我提到过，分支可以通过提交的简单途径来可视化。 当我们合并分支并且没有冲突时(例如，如上所述)，仅分支路径被更改，分支的`HEAD`被更新。 这称为合并的**快进**类型。

The alternate way of merging branches is the **no fast forward** merge, by postfixing `--no-ff` to the `merge` command. In this way, a new commit is created on the base branch with the changes from the other branch. You are also asked to specify a commit message:

合并分支的另一种方法是**不快进**合并，方法是在`merge`命令后缀`--no-ff` 。 这样，将在基本分支上创建一个新提交，并从另一个分支中进行更改。 还要求您指定一个提交消息：

git merge --no-ff new_feature

In the example above, the former (merging `new_feature` with `master`) was a fast forward merge, whereas the latter was a no fast forward merge with a merge commit.

在上面的示例中，前者(将`new_feature`与`master`合并)是快速向前合并，而后者是不具有合并提交的快速向前合并。

While the fast forward style of merges is default, it’s generally a good idea to go for the no fast forward method for merges into the master branch. In the long run, a new commit that identifies a new feature merge might be beneficial, as it logically separates the part of the code that is responsible for the new feature into a commit.

虽然默认为快进合并方式，但是最好采用不使用快进方式将其合并到master分支中的方法。 从长远来看，标识新功能合并的新提交可能是有益的，因为它将逻辑上负责新功能的代码部分分离为一个提交。

##  结论 **(**Conclusion**)** ##

###  您学到了什么？ **(**What Have You Learned?**)** ###

In this chapter, we discussed what branches are and how to manage them in Git. We looked at creating, modifying, deleting and merging branches.

在本章中，我们讨论了什么是分支以及如何在Git中管理它们。 我们研究了创建，修改，删除和合并分支。

###  下一步是什么？ **(**What’s Next?**)** ###

I’ve already spoken about how Git is beneficial to developers working in teams. The next chapter will look at this in more detail, as well as specific Git actions and commands that are frequently used while working in a distributed team.

我已经讲过Git如何对团队合作的开发人员有利。 下一章将对此进行更详细的介绍，以及在分布式团队中经常使用的特定Git动作和命令。

> 翻译自: [https://www.sitepoint.com/git-branching/][https_www.sitepoint.com_git-branching]

git git\_dir分支

[jsgit]: /images/20221123/85f07ce70e524bbc8c8a8b7640a4b859.png
[Jump Start Git]: https://www.sitepoint.com/premium/books/jump-start-git
[SitePoint Premium members]: https://www.sitepoint.com/premium/join
[order them here]: http://shop.oreilly.com/product/9780994182654.do
[CVS]: https://en.wikipedia.org/wiki/Concurrent_Versions_System
[Command showing the branches in the local copy as well as the origin branch]: /images/20221123/2e2c2e201abd4510948b28b8b821c0a0.png
[Creating a new branch and making it active]: /images/20221123/e7f31f9635ca41d394a94ba200294624.png
[Create and checkout to a new branch in a single command]: /images/20221123/630299e6593a488cbc82b8aef513f35a.png
[Creating a branch based on an old commit]: /images/20221123/f340b3102baa4a28954be067fb4a2407.png
[Deleting a branch in Git]: /images/20221123/d61cdf7655bd4d17b4c432b1dbcaf45b.png
[Deleting a branch in Git using the -d option]: /images/20221123/8e2ea989a61f4a26b171a38938eb7d15.png
[Branches and HEAD]: /images/20221123/04cd4f703af249a1b4dfb3bff3c92364.png
[Checking the history in each branch]: /images/20221123/ae903d821b914cd59bd2f231d7065b1d.png
[Visualizing our branches before the merge]: /images/20221123/3d45024213ce47599622b0c1c0b6aa4b.png
[The status of the repository after merging new_feature into master]: /images/20221123/fafb6c299f43466aab9cbd25265924cb.png
[The status of the repository after merging another_feature into new_feature]: /images/20221123/f059df6f1e3348f09fed87f38a2c63a2.png
[The status of branch new_feature after the merge]: /images/20221123/4d0cd688e49540e58244097686d2586c.png
[https_www.sitepoint.com_git-branching]: https://www.sitepoint.com/git-branching/