git_chapter3_分支

2016-04-22  本文已影响55人  董哒哒

Chapter3 分支

参考自 https://git-scm.com/book/zh/v1/Git-%E5%88%86%E6%94%AF

3.1 什么是分支

为了理解 Git 分支的实现方式，我们需要回顾一下 Git 是如何存储数据的。Git 保存的不是文件差异或者变化量，而是一系列文件快照。

下面用一个实际例子来说明分支的实现方式：

  1. 首先，我们创建一个新的本地仓库，并在工作目录新增三个文件：

    $ mkdir branchtest
$ cd branchtest
$ git init
$ git add file_001 file_002 file_003

    注意，这个时候仓库中还没有任何分支，不信你用 git branch --list 试一下，没有输出任何东西。

  2. 接下来我们将暂存区的文件提交到仓库：

    git commit -m 'initial commit of my project'
[master (root-commit) 2618748] initial commit of my project
 3 files changed, 3 insertions(+)
 create mode 100644 file_001
 create mode 100644 file_002
 create mode 100644 file_003

Dongyu@Dongyu-PC MINGW64 /e/workspace/others/git/branchtest (master)
$ git branch --list
* master

    可以看到这个时候有了一个新的分支 master, 在这个过程中发生了什么呢？

    • 首先，在暂存操作(也就是 git add)中，Git 会计算每个文件的校验和，然后把文件快照和校验和打包到 blob 结构体中，再存储到 仓库里。暂存区并不存储文件快照，只是存储了文件校验和。
    • 然后，在提交操作(也就是 git commit)执行前，Git 会先计算每个子目录的校验和，然后把目录和文件的校验和一起打包到 tree 结构体中。
    • 最后，执行提交操作，Git 会将之前的 tree 结构体和作者信息等内容打包到 commit 结构体(提交对象)中，存储到仓库里。

    上述过程可以用下图表示：


    单个提交对象在仓库中的数据结构

    每次 git commit 操作都会将一个 commit 提交对象存储到仓库里。新存储的 commit 会跟在之前 commit 对象的后面：

    多个提交对象之间的链接关系

  3. 提交对象链 与 分支：
    多次提交会让 commit 对象连成一条提交链。而 Git 中的分支，本质上只是一个指向某个 commit 对象的可变指针。master 是分支的默认名字，每次你提交一个 commit 对象上去，master 指针就会向后移动，指向最新提交的 commit 对象：

    分支其实就是从某个提交对象往回看的历史

  4. 新建一个分支：
    新建一个分支，实际上就是创建一个新的分支指针，这可以用 git branch 命令实现，比如 git branch testing 就会在当前 commit 对象上新建一个分支指针：

    多个分支指向提交数据的历史

  5. 切换到新建分支上：
    Git 是如何知道你当前在那个分支上工作呢？很简单，它保存着一个名为 HEAD 的特别指针。刚刚的 git branch 只是创建了一个新分支，并没有切换到那个分支上，所以 HEAD 指针还是指向 master 分支：

    HEAD 指向 master 分支

    要切换到新建的 testing 分支，就得把 HEAD 指针移动到 testing 分支上，这可以用 git checkout testing 命令来实现：

    HEAD 指向 testing 分支

    注意 使用 git checkout 切换分支的同时，工作目录中的文件也会被修改为 目标分支 的文件。如果工作目录中有未提交的修改的话， git 是不允许你切换分支的。

  6. 在新建分支上提交：
    现在 master 和 testing 分支上的内容是完全一样的，我们修改一下 工作目录 中的文件，然后提交。下图显示了提交后的结果：

    每次提交后 HEAD 随着分支一起向前移动

  7. 在原分支上提交：
    我们用 git checkout master 命令切换回原 master 分支。此时工作目录会还原回 master 分支的状态。做些修改后再次提交。下图显示了提交后的结果：

    不同流向的分支历史

3.2 分支的新建与合并

例子

现在我们来看一个简单的分支与合并的实际例子：

已经有了一个项目仓库(master)，接到了一个新需求，创建一个分支用来实现这个需求 (iss53)。

这个时候，你突然接到任务要在原项目中做一个紧急修复。那么可以按照如下步骤处理：

  1. 返回原有项目分支(master)；
  2. 为这个紧急任务创建一个新分支，并在其中修复这个问题(hotfix)；
  3. Bug 解完后，回到原有分支(master)，把修补分支合并进来；
  4. 切换到 新需求分支(iss53)，继续工作。

好，我们来看一下每个步骤中分支的状态：

  1. 原项目分支(master):


    原项目分支

  2. 接到新需求，创建一个分支(iss53):
    创建分支使用 git branch iss53 命令：

    创建新需求分支

  3. 在新需求分支上提交了一些代码：


    经过提交的分支

  4. 接到解 Bug 任务，再创建一个解Bug分支(hotfix)，并在其中了提交一些代码：

    # 先回到 master
git checkout master

# 切换到 hotfix 工作
git branch hotfix
git checkout hotfix

# 进行代码提交
git add ...
git commit -m 'fix bug'
    经过提交的分支

    注意，创建 hotfix 之前要先回到 master 分支，不然的话创建的分支是基于 iss53 分支的。

  5. Bug 解完，回到原有分支(master), 把 hotfix 合并进来：

    # 先回到 master
git checkout master

# 进行分支合并
git merge hotfix
    合并后的分支

  6. hotfix 用完了，删除掉它

    git branch -d hotfix
    删除 hotfix

  7. 回到 新需求分支 上继续开发：

    git checkout iss53
    新分支

  8. 新需求开发完了，合并到 master 上：

    # 先切换回 master
git checkout master

# 合并分支
git merge iss53

    这次的分支合并跟之前不大一样，合并 hotfix 的时候，master 还是原来的 master, 但合并 iss53 分支的时候，master 已经不是原来的 master 了(此时的 master 由于合并了 hotfix, 指针向右移动了一格)。

    此时，master 指针不是直接移动到 iss53 指针所在的位置，而是在 master 分支上创建了一个新的节点用于存储合并的结果：

    iss53 分支合并

冲突时的分支合并

加入在合并 iss53 分支的时候遇到了冲突，git 会显示如下内容：

$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

上述指令显示在 index.html 文件中出现了冲突，你可以用 git status 命令查看一下此时的状态：

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:      index.html

no changes added to commit (use "git add" and/or "git commit -a")

git 提醒你你要先解决冲突，然后使用 git add <file> 来将冲突标记为已解决状态，然后调用 git commit 命令来修复冲突。

  1. 打开 index.html 文件，找到冲突所在位置：

    <<<<<<< HEAD
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
  please contact us at support@github.com
</div>
>>>>>>> iss53

    ======= 以上的部分是 master 分支的内容，以下的部分是 iss53 分支的内容，你可以保留其中某个，或者改成另一种实现。

  2. 解决完冲突后，调用 git add index.html 将该文件放入暂存区;

  3. 然后调用 git commit 命令提交到仓库。

3.3 分支的管理

  1. 显示分支列表 git branch：

    $ git branch
  iss53
* master
  testing

  2. 查看各个分支的最后提交信息 git branch -v：

    $ git branch -v
  iss53   93b412c fix javascript issue
* master  7a98805 Merge branch 'iss53'
  testing 782fd34 add scott to the author list in the readmes

  3. 显示已合并的分支 git branch --merged ：

    $ git branch --merged
  iss53
* master

    知道哪些分支已经被合并，就可以删除它们了

  4. 显示未合并的分支 git branch --no-merged ：

    $ git branch --no-merged
  testing

  5. 分支已经合并的情况下，可以用 git branch -d branch_name 命令来删除：

    $ git branch -d iss53

  6. 分支未合并的情况下，直接使用上述命令会报错，因为分支上的修改可能是有用的，删除的话可能会有危险：

    $ git branch -d testing
error: The branch 'testing' is not fully merged.
If you are sure you want to delete it, run 'git branch -D testing'.

    正如提示所说，如果你确实不需要这个分支，可以用 git branch -D branch_name 来强制删除。

利用分支进行开发的工作流程

这一节介绍一些使用分支进行开发的工作流程。你可以结合实际项目的情况选择一种用用看。

长期分支

由于 git 使用简单的三方合并，你可以同时拥有多个开放的分支，每个分支用于特定的任务。

许多使用 git 的开发者都喜欢用这种方式来开展工作。比如在 master 分支中保留完全稳定的代码，与此同时，在 master 的基础上新建一个 develop 分支用于开发，还可以在 develop 分支的基础上新建一个 topic 分支用于开发某些新特性。

topic 分支开发完毕后，合并到 develop 分支；develop 分支稳定下来后，合并到 master 分支：

流水线式的分支

注意： 这种方式是基于一种筛选的思想，新代码通过 topic -> develop -> master 层层筛选，从而达到提交代码稳定性的目的。跟之前 同时做两件事的分叉分支 不是一个思路。

特性分支

这种方式就是上一节中同时做好几件事的思路。在任何项目中都可以使用 特性分支(topic) 。一个特性分支是指一个短期的，用来实现单一特性的分支。可能你在其它版本控制工具里从未这样做过，因为创建与合并分支的消耗太大。然而，在 git 中，一天之内建立、合并再删除多个分支是常见的事。

这种技术有一个显而易见的好处：各个特性分支之间互不干扰。浏览代码之类的事情会因此变得更简单。你可以把特性分支保存几天甚至几个月，在需要的时候合并它们就好了。

这种方式就不举例子了，之前已经说过。

3.5 远程分支

上一篇下一篇

猜你喜欢

热点阅读