Git-分支

Travis 于 2020-06-01 发布

目录

Git 分支

分支的新建与合并

1. 新建分支

1
2
3
4
5
6

# 新建并切换  
$ git checkout -b iss53  
  
# 等价于  
$ git branch iss53  
$ git checkout iss53

2. 合并分支
情况一：master 可以顺着移动到 hotfix，会快速把 master 指针指向 hotfix 所在

1
2
3
4

$ git checkout master  
$ git merge hotfix  
# 合并成功删除 hotfix 分支  
$ git branch -d hotfix

示意图
master切换到hotfix
master切换到hotfix

情况二：master 与 iss53 分叉开来，Git 会做一些简单的第三方合并

1
2
3
4

$ git checkout master  
$ git merge iss53  
# 合并成功删除 iss53 分支  
$ git branch -d iss53

master切换到iss53
master切换到iss53

第二种情况，很可能遇到 合并冲突 的问题，此时需要手动解决这些冲突

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 产生冲突  
$ git merge iss53  
  
# 查看冲突文件的未合并状态  
$ git status  
  
# 解决冲突  
## 手动解决  
$ vim index.html  
$ git add index.html  
$ git status  
## 工具解决  
$ git mergetool  
  
# 最后确定提交  
$ git commit

分支管理

git branch

分支开发工作流

1. 长期分支
只在 master 分支上保留完全稳定的代码，使用其他分支进行开发测试，待到稳定后，合并到主分支上。
事实上我们刚才讨论的，是随着你的提交而不断右移的指针。 稳定分支的指针总是在提交历史中落后一大截，而前沿分支的指针往往比较靠前。
示意图
长期分支
长期分支

2. 主题分支
考虑这样一个例子，你在 master 分支上工作到 C1，这时为了解决一个问题而新建 iss91 分支，在 iss91 分支上工作到 C4，然而对于那个问题你又有了新的想法，于是你再新建一个 iss91v2 分支试图用另一种方法解决那个问题，接着你回到 master 分支工作了一会儿，你又冒出了一个不太确定的想法，你便在 C10 的时候新建一个 dumbidea 分支，并在上面做些实验。 你的提交历史看起来像下面这个样子：
主题分支

现在，我们假设两件事情：你决定使用第二个方案来解决那个问题，即使用在 iss91v2 分支中方案。 另外，你将 dumbidea 分支拿给你的同事看过之后，结果发现这是个惊人之举。 这时你可以抛弃 iss91 分支（即丢弃 C5 和 C6 提交），然后把另外两个分支合并入主干分支。 最终你的提交历史看起来像下面这个样子：
主题分支

注意
以上全部操作所影响的范围都是在本地仓库

远程分支

查看远程分支的信息

1
2

$ git remote show origin  
$ git ls-remote origin

注意区分本地 master 和远程 origin/master 的区别

以下是一个可能遇到的工作模式

1. 推送
本地的分支并不会自动与远程仓库同步——你必须显式地推送想要分享的分支。 这样，你就可以把不愿意分享的内容放到私人分支上，而将需要和别人协作的内容推送到公开分支。

1
2
3
4
5

# 自动创建远程分支的名字  
$ git push origin serverfix  
  
# 手动指定远程分支的名字  
$ git push origin serverfix:awesomebranch

2. 跟踪分支
跟踪分支是与远程分支有直接关系的本地分支

1
2
3
4
5
6
7
8
9
10
11

# 默认创建同名新分支并跟踪  
# 以下都是相同效果的  
$ git checkout -b serverfix origin/serverfix  
$ git checkout --track origin/serverfix  
$ git checkout serverfix  
  
# 指定新分支的名字  
$ git checkout -b sf origin/serverfix  
  
# 设置已有分支来跟踪远程分支  
$ git branch -u origin/serverfix

3. 删除远程分支

1

$ git push origin --delete serverfix

变基（rebase）

变基解释

1
2
3
4
5
6
7

# 将 experiment 变基到 master 分支  
$ git checkout experiment  
$ git rebase master  
  
# 快进 master 分支到 experiment 节点上  
$ git checkout master  
$ git merge experiment

如下图所示，变基是找出 c4 在基于 c2 的所有变动，依照提交顺序重新在 c3 的基底上提交，并舍弃之前的 c4 的分支。


另外一个复杂的例子
从 client 节点变基到 master节点

1
2
3
4
5
6
7

# 找出 client 分支在 server 分支上的所有变动  
# 然后基于 master 分支进行提交  
$ git rebase --onto master server client  
  
# 快进 master 到 client  
$ git checkout master  
$ git merge client

这种情况适用于，我们想把 client 合并到主分支上，而保留 server 分支（可能需要再完善测试稳定等原因）


如果想进一步把 server 分支变基到 master 节点

1
2
3
4
5
6
7
8
9
10

# server 分支变基到 master 分支  
$ git rebase master server  
  
# 快进 master 到 server  
$ git checkout master  
$ git merge server  
  
# 清理分支（此时client/server都在 master 主干上）  
$ git branch -d client  
$ git branch -d server


变基的风险
如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。