Git 之三 - 分支管理

发表于 更新于 阅读次数： 评论数： 本文字数： 362 阅读时长 ≈ 1 分钟

系列教程

Git 常见的分支模型

git-branch-type

Git 分支管理图解

git-branch-manage-diagram

Git 分支的创建、删除、切换

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 查看当前的分支列表
$ git branch -v

# 创建分支
$ git branch hot_fix

# 删除某个分支
$ git branch -d hot_fix

# 切换到某个分支
$ git checkout hot_fix

# 一步完成创建并切换分支
$ git checkout -b hot_fix

Git 分支的合并

1
2
3
4
5
6
7
# 这里演示将hot_fix分支合并到master分支

# 第一步，切换到接收修改的分支（即准备增加新内容的分支）上
$ git checkout master

# 第二步，合并分支到当前分支
$ git merge hot_fix

Git 分支的变基

1
2
3
4
5
6
7
# 这里演示在feature分支上开发功能，但master分支上有一些新的提交，想让feature分支基于最新的master分支

# 第一步：切换到feature分支
$ git checkout feature

# 第二步：将当前分支的提交历史，变基（即"重新建立基底"）到master分支的最新提交之后，形成一条线性的提交历史
$ git rebase master
  • 原始的分支结构：
1
2
3
A---B---C  (main)
     \
      D---E---F  (feature)
  • 变基之后的分支结构:
1
2
3
A---B---C  (main)
             \
              D'--E'--F'  (feature)
特点说明
提交历史更整洁线性、易读，没有分叉结构
原始提交会被 “复制” 实际是创建新的提交，不是简单移动
会改变提交哈希所以不要对公共分支执行 git rebase（否则会引发冲突和混乱）
可以减少 merge commit 与 git merge 不同，git rebase 不会产生额外的合并节点

特别注意

在团队开发中，不要在公共分支使用 git rebase，否则可能会引起他人拉取代码时的冲突和困惑。

Git 解决合并分支后产生的冲突

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 这里演示将master分支合并到hot_fix分支，并解决合并后产生的冲突

# 切换到hot_fix分支
$ git checkout hot_fix

# 合并master分支，git输出了合并冲突的提示信息
$ git merge master
<<<<<<< HEAD
edit by hot_fix s
=======
edit by hot_fix2
>>>>>>> master

# 第一步，手动编辑产生冲突的文件，并修改文件内容，直至冲突的文件内容都修改掉
$ vim api.json

# 第二步，标记冲突已解决，将之前产生冲突的文件添加到暂存区
$ git add api.json

# 第三步，提交修改，此时commit参数不能带具体文件名
$ git commit -m 'update message'

克隆指定分支的代码

1
2
# 通过 -b 参数指定分支，默认是master分支
$ git clone -b develop https://github.com/xxx.git