Git分支管理-创新互联

前言

分支在实际生产环境中的作用：比如你准备开发一个新功能，但是需要很长的时间才能完成，第一天编写了一些代码，如果讲代码立即上传，由于代码还没写完，不完整的代码库会导致别人不能工作。但是如果等代码全部写完再提交，又存在丢失每天进度的巨大风险。

现在有了分支，这样的担心就完全没有必要了。创建一个属于自己的分支，别人看不到，还继续在原来的分支上进行工作，而你在自己的分支上工作，想提交随时可以提交，直到开发完毕后，再一次性地合并到原本的分支上，这样，既安全，又不影响别人工作。

几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来，然后在不影响主线的同时继续工作。在很多版本控制系统中，这是个昂贵的过程，常常需要创建一个源代码目录的完整副本，对大型项目来说会花费很长时间。

有人把git的分支模型称为“必杀技特性”，而正是因为它，将git从版本控制系统家族里区分出来。git有何特别之处呢？git的分支可谓是难以置信的轻量级，它的新建操作几乎可以在瞬间完成，并且在不同分支间切换起来也差不多一样快。和许多其他版本控制系统不同，git鼓励在工作流程中频繁使用分支与合并，哪怕一天之内进行许多次都没有关系。

理解分支的概念并熟练运用后，你才会意识到为什么 Git 是一个如此强大而独特的工具，并从此真正改变你的开发方式。

关于git的详细介绍，建议还是移步到git官方文档进行系统化的学习！

1）安装并初始化git版本库

[root@git ~]# yum -y install git
[root@git ~]# git --version
git version 1.8.3.1
[root@localhost ~]# mkdir /git && cd /git
[root@git git]# git init
初始化空的 Git 版本库于 /git/.git/
[root@git git]# git config --global user.name admin
[root@git git]# git config --global user.email admin@admin.com

2）创建、快速合并及删除分支

[root@localhost git]# echo -e "第一行" > README.txt
[root@localhost git]# git add README.txt
[root@git git]# git commit -m "第一次提交来自master分支"
[root@localhost git]# git checkout -b dev
#创建一个新的分支，名称为dev，并且切换到dev分支下
###############以下操作在dev分支下操作##################
[root@localhost git]# git branch            #查看当前的分支情况
* dev                                                     #分支前的“*”号就表示当前在该分支下
  master
[root@git git]# echo -e "# 第二行" >> README.txt 
[root@git git]# git add README.txt
[root@git git]# git commit -m "第一次提交来自dev分支"
[root@git git]# cat README.txt             #在dev分支下查看文件内容
# 第一行
# 第二行
[root@git git]# git checkout master
#切换到master分支
##############以下操作在master分支操作#################
[root@git git]# git branch                  #保证分支切换成功
  dev
* master
[root@git git]# cat README.txt          #在master分支下查看文件内容
# 第一行
[root@git git]# git merge dev
#将dev分支与当前（master）分支合并，采取的是快速合并的方式
[root@git git]# cat README.txt               #再次查看文件内容
# 第一行
# 第二行
[root@git git]# git log --graph --pretty=oneline --abbrev-commit         #查看提交的日志信息，使其在一行显示
* da7e6c8 第一次提交来自dev分支
* 78c0b14 第一次提交来自master分支
#可以看到提交日志前面的“*“号在同列，这就是采用快速合并的方式的特点（默认）
#时间长了，就无法分辨出，具体是在那个分支进行的提交
#稍后写下关闭快速合并的方法，二者进行比对！
[root@git git]# git branch -d dev              #删除dev分支（前提是不在dev分支下）

3）解决分支冲突问题

在我们实际工作中会遇到一个分支冲突的问题，就是当你在工作分支dev下对文件内容进行了修改，然后在你提交到版本库前，master分支下的内容已经发生了改变，此时，你dev分支下的内容是比master下的内容要旧，这种情况下进行分支合并，会有一个分支冲突的概念，例子如下：

[root@git git]# mkdir /lzj && cd /lzj            #重新创建目录用于测试
[root@git lzj]# git init                              #初始化目录
[root@git lzj]# echo "aaaa" > readme.txt
[root@git lzj]# git add readme.txt
[root@git lzj]# git commit -m "commit from master"          #将测试文件上传到版本库中
[root@git lzj]# git branch                   #确认当前分支
* master
[root@git lzj]# cat readme.txt                      #确认文件内容
aaaa
[root@git lzj]# git checkout -b dev                #创建dev分支并切换到dev分支
[root@git lzj]# echo "bbbb" >> readme.txt 
[root@git lzj]# git add readme.txt
[root@git lzj]# git commit -m "commit form dev"    #将dev分支的内容提交到版本库
[root@git lzj]# cat readme.txt     #查看文件内容
aaaa
bbbb
[root@git lzj]# git checkout master              #切换到master分支
[root@git lzj]# cat readme.txt                      #查看文件内容（还是原本的内容）
aaaa
[root@git lzj]# echo "cccc" >> readme.txt 
[root@git lzj]# git add readme.txt
[root@git lzj]# git commit -m "alter commit from master"             #再次插入内容并提交
[root@git lzj]# cat readme.txt                 #确认文件内容
aaaa
cccc
[root@git lzj]# git merge dev                 #将dev分支与master分支进行合并 
#返回以下内容，说明合并时发生冲突
自动合并 readme.txt
冲突（内容）：合并冲突于 readme.txt
自动合并失败，修正冲突然后提交修正的结果。
#接下来就是解决合并时发生的冲突
#出现上述报错信息，表示dev分支下的内容存在master分支的文件，只是dev分支的文件没有与master分支下的文件进行合并，再次提交提交即可
#实际环境中，并不建议直接提交，因为文件内容可能有特殊的地方
[root@git lzj]# vim readme.txt              #此时文件内容如下
aaaa
<<<<<<< HEAD
cccc
=======
bbbb
>>>>>>> dev
[root@git lzj]# cat readme.txt               #讲特殊符号进行删除后再次提交
aaaa
cccc
bbbb
[root@git lzj]# git add readme.txt
[root@git lzj]# git commit -m "冲突已解决"               #再次提交
[root@git lzj]# git log --graph --pretty=oneline --abbrev-commit
#查看分支合并情况
*   9549c57 冲突已解决
|\  
| * 336e03c commit from dev
* | 26e7e0d alter commit from master
|/  
* e766eaf commit from master

4）关闭快速合并

在上面说到，在查看git版本的提交历史时，其分支结构表现的不是那么直观，那是因为默认开启了快速合并的选项，这里写下如何关闭快速合并。

[root@git lzj]# git checkout dev                    #切换到dev分支下
[root@git lzj]# echo "dddd" >> readme.txt 
[root@git lzj]# git add readme.txt
[root@git lzj]# git commit -m "关闭快速合并"            #插入数据并提交
[root@git lzj]# git checkout master                          #切换master分支
[root@git lzj]# git merge --no-ff -m "分支合并说明" dev           #”--no-ff“选项就是关闭快速合并，需自行添加提交的说明信息
[root@git lzj]# git log --graph --pretty=oneline --abbrev-commit 
#查看提交的日志信息，并以一行显示
*   2255433 分支合并说明
|\  
| * 5c3d07a 关闭快速合并
* |   9549c57 冲突已解决          #从这里往上，可以看出是经过一个分支才提交的
|\ \  
| |/  
| * 336e03c commit from dev
* | 26e7e0d alter commit from master
|/  
* e766eaf commit from master
[root@git lzj]# git branch -d dev              #删除dev分支

5）Bug分支

开发人员在开发过程中，bug就像家常便饭一样，有了bug就要修复，在git中，由于分支是强大的，所以都可以通过一个新的临时分支来修复bug，修复后，分支合并，然后将临时分支删除。

当我们接到一个修改bug的任务后，很自然的想要创建一个分支来修复它，但是当前正在进行的工作进行到一半，还无法提交，但又需要马上修复bug，此时，可以通过git提供的stash功能，可以把当前工作区“储藏”起来，等以后恢复现场后继续工作。

1）工作进行到一半时工作区的状态如下：

[root@git lzj]# cat readme.txt 
aaaa
cccc
bbbb
dddd
[root@git lzj]# echo "eeee" >> readme.txt 
[root@git lzj]# git status             #查看状态可以看出有修改但未提交
# 位于分支 master
# 尚未暂存以备提交的变更：
#   （使用 "git add ..." 更新要提交的内容）
#   （使用 "git checkout -- ..." 丢弃工作区的改动）
#
#   修改：      readme.txt
#
修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）

2）将此时的工作区隐藏起来

[root@git lzj]# git stash                     #使用此命令讲当前工作区隐藏
[root@git lzj]# git status                    #再次查看当前工作区，就是干净的状态了
# 位于分支 master
无文件要提交，干净的工作区
[root@git lzj]# cat readme.txt                  #再次查看文件内容，也没有刚才添加的内容
aaaa
cccc
bbbb
dddd

3）假设在dev分支上修复bug

[root@git lzj]# git checkout -b dev            #创建dev分支并切换到dev分支
[root@git lzj]# echo "ffff" >> readme.txt 
[root@git lzj]# git add readme.txt
[root@git lzj]# git commit -m "alter from dev"
[root@git lzj]# git checkout master                    #切换到master分支
[root@git lzj]# git merge dev                          #将dev分支进行快速合并
#有两种恢复方法：
#一是使用 git stash apply 恢复，但是恢复后，stash 内容并不删除，需要用 git stash drop 来删除；
#另一种方式是用 git stash pop，恢复的同时把 stash 内容也删了；这里我采用第二种方法
[root@git lzj]# git stash pop               #回复存储区的内容
[root@git lzj]# cat readme.txt 
aaaa
cccc
bbbb
dddd
<<<<<<< Updated upstream
ffff
=======
eeee
>>>>>>> Stashed changes
#查看文件内容发现出现了分支冲突
[root@git lzj]# cat readme.txt 
aaaa
cccc
bbbb
dddd
ffff
eeee
#将文件中的乱码进行删除
[root@git lzj]# git add readme.txt
[root@git lzj]# git commit -m "解决分支冲突"            #重新提交

6）远程分支管理

将本地的版本库与github进行关联，由于关于简单，省略此步骤！

[root@git ~]# git clone git@github.com:lvzhenjiang-hub/test.git
#将github上的数据拉取到本地
[root@git ~]# git remote add origin git@github.com:lvzhenjiang-hub/test.git
[root@git ~]# git remote           #查看远程关联的远程主机，使用”-v“选项查看详细信息
origin
[root@git ~]# git checkout -b dev                #创建并进入dev分支
[root@git ~]# echo "aaa" > 123.txt
[root@git ~]# git add 123.txt
[root@git ~]# git commit -m "aaa"
[root@git ~]# git push origin dev         #将本地的dev分支与远程的dev进行关联，如果远程没有dev分支，则会新建

如图：

[root@git ~]# git branch -r -d origin/dev          #将远程的dev分支进行删除
[root@git ~]# git push origin :dev              #将删除的远程分支提交到远程版本库中

如果github在dev分支下，这时再次刷新就会出现以下页面，如图：

——————————本次博文到此结束，感谢阅读————————————

另外有需要云服务器可以了解下创新互联建站www.cdcxhl.com，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。