Git 分支的新建与合并 - 分支操作
Git 分支的新建与合并 - 分支操作
创建分支并切换
此时有一个需求需要在新的分支 iss53
上工作:
|
|
它是下面两条命令的简写:
|
|
切换分支
突然有一个紧急问题要解决,需要在原来的 master
分支进行修复:
|
|
在切换到 master
之前,需要 iss53
分支保持好一个干净的状态(修改都已提交)。
注意:切换分支 Git 会重置你的工作目录。
checkout
中文含义 “检出”,checkout <branch>
检出分支 => 检出指定分支的代码 => 重置工作目录并切换分支。
接下来,你要修复这个紧急问题。 建立一个 hotfix
分支,在该分支上工作直到问题解决:
|
|
合并分支
|
|
删除分支
|
|
注意删除分支是在 branch
命令上
多次提交之后合并分支
假设你已经修正了 #53 问题,打算合并到 master
分支:
|
|
这看似和之前的合并区别不大。此时你的开发历史从一个更早的地方开始分叉开来(diverged)。 因为,master
分支所在提交并不是 iss53
分支所在提交的直接祖先,Git 不得不做一些额外的工作。 出现这种情况的时候,Git 会使用两个分支的末端所指的快照以及这两个分支的公共祖先,做一个简单的三方合并。
和之前将分支指针向前推进所不同的是,Git 将此次三方合并的结果做了一个新的快照并且自动创建一个新的提交指向它。 这个被称作一次合并提交,它的特别之处在于他有不止一个父提交。
遇到冲突时的分支合并
如果你在两个不同的分支中,对同一个文件的同一个部分进行了不同的修改,Git 就没法干净的合并它们,就产生了冲突。
合并过程中出现 CONFLICT
提升,表示有冲突
|
|
使用 git status
查看未合并状态。
任何因包含合并冲突而有待解决的文件,都会以未合并状态标识出来。 Git 会在有冲突的文件中加入标准的冲突解决标记,这样你可以打开这些包含冲突的文件然后手动解决冲突。 出现冲突的文件会包含一些特殊区段,看起来像下面这个样子:
|
|
你需要手动解决冲突,解决了所有文件里的冲突之后,对每个文件使用 git add
命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件,Git 就会将它们标记为冲突已解决。
如果你对结果感到满意,并且确定之前有冲突的的文件都已经暂存了,这时你可以输入 git commit
来完成合并提交。