git分支管理套路

1. 什么是git？

目前世界上最先进的分布式版本控制系统。

2. 如何创建版本库？

1.在github代码托管平台上Create a new repository，复制新仓库地址https://github.com/linfengda/springbootChapter1.git。

2.在本地文件夹分别执行以下命令

                  
//初始化git仓库
git init
//本地仓库关联远程仓库
git remote add origin https://github.com/linfengda/springbootChapter1.git
//添加所有文件
git add .
//提交文件
git commit -m 'first commit'
//提交文件到远程仓库
git push -u origin master
                  
                

然后如下图所示，可以看到本地项目被成功提交到远程仓库。

将项目导入intellij idea，可以看到版本控制信息。

3. git工作区、暂存区、版本库之间的关系？

我们自己建立的项目文件夹即工作区，在初始化git版本库之后会生成一个隐藏的文件.git，可以将该文件理解为git的版本库，而在.git文件夹里面还有很多文件，其中有一个index文件就是暂存区，如下图：

上图命令解释：

1、git add
将本地文件修改同步到暂存区
2、git commit
将暂存区的修改同步到版本库，这时候你代码所属的本地分支被更新。
2、git push
将本地分支同步到远程分支，这时候你代码所属的远程分支被更新。

通过三个命令理解

git diff 比较工作区和暂存区的差别
git diff --cached 比较暂存区和版本库的差别
git diff HEAD 比较工作区和版本库的差别

实例讲解

我们修改com.linfengda.sb.chapter1.git.Test1.java文件，并新建com.linfengda.sb.chapter1.git.Test2.java文件。分别执行这3条命令结果如下：

从图中可以看出，工作区与暂存区、工作区与版本库都有变化，而暂存区与版本库并没有变化。而且，我们发现已经提交到暂存区的文件修改的时候才可以看出明显区别，如果只是在工作区新建一个文件，那么输入这三个命令都没有结果为空白。进一步执行git add .

从图中可以看出，工作区与暂存区已经同步，暂存区与版本库、工作区与版本库没有同步。最后一步执行git commit。

当执行完git commit后，三个命令都没有输出结果，表明我们修改的文件已经被同步的版本库，已经被版本库管理起来了。

4. 什么是HEAD指针？

HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。

5. 什么是git分支？

项目代码并行开发的分支，一个项目有一个master分支，多个子分支，分支代码互不影响。

这是只有一个master分支的情况，HEAD指针指向的分支就是当前分支，现在它指向master。

我们创建一个新的分支dev，切换到dev分支，并修改该分支的Test1.java，HEAD指针就指向dev分支，而master指针不变：

如果我们又切换到master分支，并修改该分支的Test1.java，master分支和dev分支各自都分别有新的提交，变成了这样：

这时候如果我们合并dev分支到master，就会出现冲突，需要合并冲突：

合并后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

实例教程：

首先，我们创建develop分支，然后切换到develop分支：

                  
$ git checkout -b develop
Switched to a new branch 'develop'
                  
                

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

                  
$ git branch develop
$ git checkout develop
Switched to branch 'develop'
                  
                

然后，用git branch命令查看当前分支：

                  
$ git branch
* develop
  master
                  
                

6. 标准的多人协作开发模式

在git分支管理策略中，通常有2种套路

1. git-flow套路 (master + develop) + (feature + fixbug)

master分支，所有提供给用户使用的正式版本，都在这个主分支上发布，发布完成后打标签

develop分支

develop分支中包含的是下个版本需要发布的内容。从某种意义上来说，develop 是一个进行代码集成的分支。当 develop 分支集成了足够的新功能和 bug 修复代码之后，通过一个发布流程来完成新版本的发布。发布完成之后，develop 分支的代码会被合并到 master 分支中。

                  
# 创建develop分支
git checkout -b develop master

# 切换到master分支
git checkout master	

# 对develop分支进行合并
git merge --no-ff develop
                  
                

feature分支

master和develop。前者用于正式发布，后者用于版本测试。在生产开发中，产品会创建很多需求和若干个版本，然后把需求分到不同的版本。比如：产品规划了2个版本，1.1版本和1.2版本，1.1版本新增C模块，需要在10号上线，1.2版本升级A模块，需要在15号上线，但是它们需要同时进行开发。这时候我们就需要从develop分支上面分出feature-1.1分支和feature-1.2分支，同时进行开发。开发完成后，要再并入develop。

                  
# 创建feature分支
git checkout -b feature-x develop

# 切换到develop分支
git checkout develop	

# 对feature分支进行合并
git merge --no-ff feature-x

# 删除feature分支
git branch -d feature-x
                  
                

fixBug分支

软件正式发布以后，如果出现bug。这时就需要创建一个分支，进行bug修补。我们称呼为fixbug-*分支，fixbug-*分支是直接从master分支上面分出来的。bug修补后，再合并进master和develop分支。

                  
# 创建fixbug分支
git checkout -b fixbug-x develop

# 修补结束后，合并到master分支：
git checkout master	
git merge --no-ff fixbug-x

# 修补结束后，合并到develop分支：
git checkout develop	
git merge --no-ff fixbug-x
                  
                

2. GitHub flow套路 master +（V1.1 + V1.2 + V1.3 + ...V1.n)

从公式可以看出，该套路追求极简风格和简单实用。

master分支中包含稳定的代码，该分支已经或即将被部署到生产环境。master 分支的作用是提供一个稳定可靠的代码基础。任何开发人员都不允许把未测试或未审查的代码直接提交到 master 分支。

对代码的任何修改，包括 bug 修复、hotfix、新功能开发等都在单独的分支中进行。不管是一行代码的小改动，还是需要几个星期开发的新功能，都采用同样的方式来管理。当需要进行修改时，从 master 分支创建一个新的分支。新分支的名称应该简单清晰地描述该分支的作用。所有相关的代码修改都在新分支中进行。开发人员可以自由地提交代码和 push 到远程仓库。

当新分支中的代码全部完成之后，团队中的其他人员会对代码进行审查，提出相关的修改意见。然后在测试环境进行测试。当代码通过代码审查和测试之后，该分支的代码被合并到master分支。再从master分支部署到生产环境。

7. 一些你可能需要用到的操作

1.从任意commit hash中新建分支

                  
# 从commit hash新建分支：
$ git checkout -b branch_name a7666fa
# push到远程分支：
$ git push -u branch_name
                  
                

2.从标签tag中新建分支

                  
# 从tag_name新建分支：
$ git checkout -b branch_name tag_name
# push到远程分支：
$ git push -u branch_name
                  
                

3.还原文件修改

                  
# 使用版本库还原暂存区中的文件
$ git reset HEAD
# 使用暂存区还原工作区中的文件
$ git checkout file
# 使用版本库还原暂存区和工作区中的文件
$ git checkout HEAD file
                  
                

4.当本地分支和远程分支有冲突，先合并最新代码到本地分支，再手动一行行解决冲突，解决后提交到远程分支

                  
//查询当前远程的版本 
$ git remote -v 
//获取最新代码到本地(本地当前分支为[branch_name]，获取的远端的分支为[origin/branch_name]) 
$ git fetch origin branch_name  
//合并最新代码到本地分支 
$ git merge origin/branch_name 
//手动合并冲突后提交
$ git add .
$ git commit -m 'commit after merge'
$ git push origin branch_name
                  
                

5.如果当前分支的代码写到一半，需要切换到另一个分支进行开发时，可以将当前分支的代码放到暂存区

                  
# 保存当前工作进度到暂存区：         
$ git stash
# 恢复最新的进度到工作区：
$ git stash pop
                  
                

6.删除git仓库中的文件（不改变工作区）

                  
# 删除target文件夹
$ git rm -r --cached target
# 提交
$ git commit -m '删除了target文件夹'
# 提交到仓库
$ git push -u origin master
                  
                

参考文章：https://www.ibm.com/developerworks/cn/java/j-lo-git-mange/index.html