git_chapter3_分支

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_chapter3_分支_第1张图片
    单个提交对象在仓库中的数据结构

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

    git_chapter3_分支_第2张图片
    多个提交对象之间的链接关系

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

    git_chapter3_分支_第3张图片
    分支其实就是从某个提交对象往回看的历史
  4. 新建一个分支:
    新建一个分支,实际上就是创建一个新的分支指针,这可以用 git branch 命令实现,比如 git branch testing 就会在当前 commit 对象上新建一个分支指针:

    git_chapter3_分支_第4张图片
    多个分支指向提交数据的历史
  5. 切换到新建分支上:
    Git 是如何知道你当前在那个分支上工作呢?很简单,它保存着一个名为 HEAD 的特别指针。刚刚的 git branch 只是创建了一个新分支,并没有切换到那个分支上,所以 HEAD 指针还是指向 master 分支:

    git_chapter3_分支_第5张图片
    HEAD 指向 master 分支

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

    git_chapter3_分支_第6张图片
    HEAD 指向 testing 分支

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

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

    git_chapter3_分支_第7张图片
    每次提交后 HEAD 随着分支一起向前移动
  7. 在原分支上提交:
    我们用 git checkout master 命令切换回原 master 分支。此时工作目录会还原回 master 分支的状态。做些修改后再次提交。下图显示了提交后的结果:

    git_chapter3_分支_第8张图片
    不同流向的分支历史

3.2 分支的新建与合并

例子

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

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

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

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

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

  1. 原项目分支(master):


    git_chapter3_分支_第9张图片
    原项目分支
  2. 接到新需求,创建一个分支(iss53):
    创建分支使用 git branch iss53 命令:

    git_chapter3_分支_第10张图片
    创建新需求分支
  3. 在新需求分支上提交了一些代码:


    git_chapter3_分支_第11张图片
    经过提交的分支
  4. 接到解 Bug 任务,再创建一个解Bug分支(hotfix),并在其中了提交一些代码:

    # 先回到 master
    git checkout master
    
    # 切换到 hotfix 工作
    git branch hotfix
    git checkout hotfix
    
    # 进行代码提交
    git add ...
    git commit -m 'fix bug'
    
    git_chapter3_分支_第12张图片
    经过提交的分支

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

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

    # 先回到 master
    git checkout master
    
    # 进行分支合并
    git merge hotfix
    
    git_chapter3_分支_第13张图片
    合并后的分支
  6. hotfix 用完了,删除掉它

    git branch -d hotfix
    
    git_chapter3_分支_第14张图片
    删除 hotfix
  7. 回到 新需求分支 上继续开发:

    git checkout iss53
    
    git_chapter3_分支_第15张图片
    新分支
  8. 新需求开发完了,合并到 master 上:

    # 先切换回 master
    git checkout master
    
    # 合并分支
    git merge iss53
    

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

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

    git_chapter3_分支_第16张图片
    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 ..." to mark resolution)

        both modified:      index.html

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

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

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

    <<<<<<< HEAD
    
    =======
    
    >>>>>>> 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 分支:

git_chapter3_分支_第17张图片
流水线式的分支

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

特性分支

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

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

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

3.5 远程分支

你可能感兴趣的:(git_chapter3_分支)