JAVAEE工程师系列技术之分布式版本控制系统git

Git概述

Git历史

很多人都知道，林纳斯·托瓦兹在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。

Git是什么

Git是一种代码托管技术。在开发中，Git是一种代码托管技术，很多代码托管平台也是基于Git来实现的。Git可以帮我们做到很多的事情，比如代码的版本控制，分支管理等。

注意：

我们可以把Git理解成是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。正是因为有了Git的存在，现在很多工作才可以变得相对轻松。

为什么要使用Git

什么是版本控制系统

你可以把一个版本控制系统（缩写VCS）理解为一个“数据库”，在需要的时候，它可以帮你完整地保存一个项目的快照。当你需要查看一个之前的快照（称之为“版本” ）时，版本控制系统可以显示出当前版本与上一个版本之间的所有改动的细节。

想法：

因为我们怕在原来的基础改错了东西，没法恢复，所以，我们可能会有多个毕业论文的文件。而我们写代码的时候本身就是「多人协作」的，修改是无法避免的，我们不希望有多个文件的产生，又希望能够记录每次更改的内容。“

这个软件用起来就应该像这个样子，能记录每次文件的改动：

版本

文件名

用户

说明

日期

1

service.doc

张三

删除了软件服务条款5

7/12 10:38

2

service.doc

张三

增加了License人数限制

7/12 18:09

3

service.doc

李四

财务部门调整了合同金额

7/13 9:51

4

service.doc

张三

延长了免费升级周期

7/14 15:17

注意：

结束了手动管理多个“版本”的史前时代，进入到版本控制的20世纪。

Git和SVN对比

SVN集中式

集中式版本控制系统需要找一个服务器作为大本营，所有的代码都需要提交到服务器上进行统一的管理。当你需要对代码进行改动时，需要先从服务器上下载一份拷贝，修改完成之后，还需要上传回服务器。

总结：模式是一对多.

SVN优缺点

优点：

管理员也可以轻松掌控每个开发者的权限。

代码一致性非常高。

适合开发人数不多的项目开发。

缺点：

服务器压力太大，数据库容量暴增。

如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。

Git分布式

在分布式版本控制系统中，大家都拥有一个完整的版本库，不需要联网也可以提交修改，所以中心服务器就显得不那么重要了。模式：多对多,M:N

注意：

Git记录版本历史只关心文件数据的整体是否发生变化。Git 不保存文件内容前后变化的差异数据。

Git优缺点

优点：

适合分布式开发，强调个体。

公共服务器压力和数据量都不会太大。

速度快、灵活。

任意两个开发者之间可以很容易的解决冲突。

离线工作。

缺点：

学习周期相对而言比较长。

不符合常规思维。

易学难精，80/20

Git基础

Git下载与安装

注意：

在Windows操作系统中安装 Git之前，先从官方网站(​​https://git-scm.com/​​)下载合适的Git版本。

下载window版

下载64位软件包

安装Git

环境配置

当安装Git后首先要做的事情是设置用户名称和email地址。这是非常重要的，因为每次Git提交都会使用该用户信息。

由于没有git目录了，先进行了初始化的操作

git init

设置用户信息

git config --global user.name "laozhang"
git config --global user.email "laozhang@163.com"

查看配置信息

检查当前的设置

git config --list
git config user.name

注意：

通过上面的命令设置的信息会保存在本地 账户的~/.gitconfig文件中。 查看之

本地初始化仓库

如果是全新的开始

如果这是你第一次使用Git，那么就先从创建一个全新的目录开始吧。打开终端机窗口，并试着操作以下命令（命令后面的#是说明,不需要输入）:

mkdir tmp #创建tmp目录 也可以手动创建文件夹
git init #初始化这个目录让Git对这个目录开始进行版本控制。

小提示：

​​git init​​​ 命令会在上述目录中创建一个名为 ​​.git​​ 的隐藏目录，并在其中创建一个版本库。该目录为文件，查看->显示隐藏目录。整个Git的精华都集中在这个目录中了，现在不先讲细节，只是体会一下使用Git的感觉，后续在详细介绍。

文件的两种状态

版本控制就是对文件的版本控制，要对文件进行修改、提交等操作，首先要知道文件当前在什么状态，不然可能会提交了现在还不想提交的文件，或者要提交的文件没提交上。

注意：

Git不关心文件两个版本之间的具体差别，而是关心文件的整体是否有改变，若文件被改变，在添加提交时就生成文件新版本的快照，而判断文件整体是否改变的方法就是用SHA-1算法计算文件的校验和。

untracked未跟踪

未跟踪, 此文件在文件夹中, 但并没有加入到git库, 不参与版本控制. 通过git add 状态变为Staged.

tracked已跟踪

被纳入版本控制

• Unmodified
  文件已经入库,未修改, 即版本库中的文件快照内容与文件夹中完全一致. 这种类型的文件有两种去处, 如果它被修改, 而变为Modified，如果使用git rm移出版本库, 则成为Untracked文件。
• Modified
  文件已修改, 仅仅是修改, 并没有进行其他的操作. 这个文件也有两个去处, 通过git add可进入暂存staged状态, 使用git checkout 则丢弃修改过,返回unmodify状态, 这个git checkout即从库中取出文件, 覆盖当前修改。
• Staged
  暂存状态. 执行git commit则将修改同步到库中, 这时库中的文件和本地文件又变为一致, 文件为Unmodify状态. 执行git reset HEAD filename取消暂存,文件状态为Modified。

注意：

这些文件的状态会随着我们执行Git的命令发生变化

下图远程仓库和本地仓库称之为版本库（本地是隐藏文件夹）

注意：

• 新建文件--->Untracked
• 使用add命令将新建的文件加入到暂存区--->Staged
• 使用commit命令将暂存区的文件提交到本地仓库--->Unmodified
• 如果对Unmodified状态的文件进行修改---> modified
• 如果对Unmodified状态的文件进行remove操作--->Untracked

查看文件状态命令

语法结构：

git status

参数：

• -s： 简洁输出

例子

在目录下新建一个hello.log

$ git status
On branch master

No commits yet

Untracked files:
(use "git add <file>..." to include in what will be committed)
a.txt

文件加入暂存区

文件加入暂存区命令

语法结构

git add 文件名

文件取消暂存区命令

语法结构

git reset 文件名|git rm 文件名 等价

git rm -- cached 是从stage（index，暂存区） 里面删除文件，当你提交（commit）之后文件就会删除了。

git reset HEAD -- file : 回退暂存区里的文件（还原为HEAD commit里面该文件的状态），会撤销从上一次提交（commit）之后的一些操作。 如果是对于新增文件，这两个操作时等效的。

git rm --cached 作用： 从索引里删除文件。 如果要删除的文件已经在仓库里了，git rm --cached 将会从索引里删除该文件，但本地工作目录还会保存源代码，提交之后将会同时从仓库里删除该文件。git reset HEAD file (命令默认参数为 --mixed) 不同于文件已经在仓库中，该命令的作用是 用repo(HEAD)替换index中file的版本，使file的版本回退到HEAD版本

文件提交与删除

如果仅是通过git add命令把移动加到暂存区，还不算是完成整个流程。如果想让暂存区的内容永久保存下来，就要使用git commit命令。

文件提交命令

语法结构：

git commit -m "提交信息"

参数：

• -m : 本次提交做了什么事，只要简单、清楚的文本说明即可，中英文都可以重点是说清楚，能让自己和别人很快明白就行。

如果不加m参数，会进入类似vim编辑。 ESC 出来:输入wq即可退出；

修改commit记录

身为程序员，难免会遇到一些不太顺心的客户或项目。心情不好的时候，在代码或Commit信息中“发泄”一下情绪也是很常见的，只是这要是让客户看见了总是不好解释。

要改动Commit记录有几种方式。

• (1）把.git目录整个删除（不建议）。
• (2）使用git rebase命令来改动历史记录。
• (3）先把 Commit用git reset命令删除，整理后再重新Commit。
• (4）使用--amend参数改动最后一次的Commit。

使用--amend参数进行Commit

git log --oneline

只需要在Commit命令后面加上--amend即可

git commit --amend -m "welcome to facebook"

Git基础_删除文件

语法结构：

git rm 文件名

注意：

删除的文件只是删除工作目录的文件，我们的版本库里面还是存在的。 删除文件会把这个文件直接放入暂存区。

挽救已被删除的文件或目录

“人有失手，马有失蹄”，人总会有不小心或状态不好的时候。不管是有意还是无心 在Git中如果不小心把文件或目录删除了，是可以挽救回来的，这也是使用版本控制系统最主要的原因之一。

这里先使用rm命令，故意把项目中所有的HTML文档删除:

rm *.html
ls -al

可以看出当前1个文件都处于被删除（deleted）状态。

可以使用git checkout命令：

git checkout index.html

1.如果我们没有提交到暂存区，直接rm 文件名，没法checkout,由于你这个删除和git无关；
2.提交文件到暂存区，再rm -rf文件名，接下来，再checkout可以恢复成功;
3.提交文件到版本库，再rm -rf文件名，接下来，再checkout可以恢复成功；

注意：

当使用git checkout命令时，Git 会切换到指定的分支，但如果后面接的是文件名或路径，Git则不会切换分支，而是把文件从.git目录中复制一份到当前的工作目录。更精准地说，这个命令会把暂存区中的内容或文件拿来覆盖工作目录中。

如果想把所有删除文件都挽救回来，可以使用以下命令：

git checkout .

小技巧:

这个技巧不仅可以将删除的文件挽救回来，当改动某个文件后反悔了，也可以用它把文件恢复到上一次Commit的状态。不是所有情况下都能恢复被删除的文件的。因为整个Git的记录都是放在根目录下的 .git目录中，如果这个目录被删除了，也就意味着历史记录也被删除了，那么删除的文件也就不能恢复了。

将文件添加至忽略列

一般我们总会有些文件无需纳入Git的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。在这种情况下，我们可以在工作目录中创建一个名为 .gitignore的文件(文件名称固定)，列出要忽略的文件模式。

忽略规则

# / 表示 当前文件所在的目录

# 忽略public下的所有目录及文件
/public/*
#不忽略/public/assets，就是特例的意思，assets文件不忽略
!/public/assets

# 忽略具体的文件
index.class

# 忽略所有的class
*.class

# 忽略 a.class b.class
[ab].class

注意：

• \#匹配规则和linux文件匹配一样
• \#以斜杠“/”开头表示目录
• \#以星号“*”通配多个字符
• \#以问号“?”通配单个字符
• \#以方括号“[]”包含单个字符的匹配列表
• \#以叹号“!”表示不忽略(跟踪)匹配到的文件或目录

例子

手动创建一个role.class文件

touch role.class
touch roleDao.class

创建.gitignore文件

touch .gitignore -- 如果手动无法创建，则使用该命令。

编写规则

*.class

日志记录操作

查看日志

语法结构：

git log

参数：

• --graph ： 查看分支合并图
• --oneline : 标记把每一个提交压缩到了一行中
  退出：wq

获取执行过的命令

语法结构：

git reflog

比较文件差异

diff是指的是两个事物的不同。例如在Linux系统中，diff命令会逐行比较两个文本的差异然后显示出来。

git diff命令格式

语法结构：

git diff [--cached]

注意：

• ​​---​​：标记原始文件
• ​​+++​​：标记新文件
• ​​@@​​：两个不同文件版本的上下文行号。
• ​​-​​： 原始文件删除改行
• ​​+​​：原始文件增加一行

实战演习

工作文件夹比较

git diff

把修改文件追加到索引区

git add .

无法比较工作文件夹的修改文件

git diff

索引区比较

git diff --cached

还原文件

对于恢复修改的文件，就是将文件从仓库中拉到本地工作区，即 仓库区 ----> 暂存区 ----> 工作区。

对于修改的文件有三种情况：

• 只是修改了文件，没有任何 Git 操作
• 修改了文件，并提交到暂存区（即编辑之后，gitadd但没有gitadd但没有 git commit -m ....）
• 修改了文件，并提交到仓库区（即编辑之后，gitadd和gitadd和 git commit -m ....）

情况I

只是修改了文件，没有任何 git 操作，直接一个命令就可回退

$ git checkout -- aaa.txt # aaa.txt为文件名

情况II

修改了文件，并提交到暂存区(即编辑之后，git add但没有gitadd但没有 git commit ）

$ git log --oneline # 可以省略
$ git reset HEAD # 回退到当前版本
$ git checkout -- aaa.txt # aaa.txt为文件名

注意：

情况II 和 情况III 只有回退的版本不一样，对于 情况II，并没有 $ git commit，仓库版本也就不会更新和记录，所以回退的是当前版本

情况III

修改了文件，并提交到仓库区\（即编辑之后git add和gitadd和 git commit -m ）

$ git log --oneline # 可以省略
$ git reset HEAD^ # 回退到上一个版本
$ git checkout -- aaa.txt # aaa.txt为文件名

注意：

git reset 版本号 ---- 将暂缓区回退到指定版本,根据 $ git log --oneline 显示的版本号，可以回退到任何一个版本，也可通过 HEAD 来指定版本。

• HEAD 当前版本
• HEAD^ 上一个版本
• HEAD^^ 上上一个版本

Git远程仓库

常用的Git代码托管平台

前面我们已经知道了Git中存在两种类型的仓库，即本地仓库和远程仓库。

远程仓库和本地仓库

常见远程仓库托管平台

我们可以借助互联网上提供的一些代码托管服务来实现，其中比较常用的有GitHub、码云、GitLab等。

• GitHub (地址:​​https://github.com/​​)是一个面向开源及私有软件项目的托管平台，因为只支持Git作为唯的版本库格式进行托管，故名GitHub。
• 码云（地址:​​https://gitee.com/）是国内的一个代码托管平台，由于服务器在国内，所以相比于GitHub，码云速度会更快。​​
• GitLab (地址:​​https://about.gitlab.com/​​)）是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

注册码云账号、创建远程仓库

登录码云

注册完成可以使用刚刚注册的邮箱进行登录(地址：​​www.gitee.com/login​​)

创建Git远程仓库

Git远程仓库_远程仓库操作

添加远程仓库

添加一个新的远程Git仓库，同时指定一个可以引用的简写。

语法结构：

git remote add <shortname><url>

注意：

• shortname ：远程的名字（可以随意取名）
• url : 远程仓库地址

例子

git remote add origin https://gitee.com//hundred-battles.git

查看远程仓库

如果想查看已经配置的远程仓库服务器，可以运行git remote命令。它会列出指定的每一个远程服务器的简写。如果已经克隆了远程仓库，那么至少应该能看到origin，这是Git克隆的仓库服务器的默认名。

语法命令：

git remote

克隆远程仓库

如果你想获得一份已经存在了的Git仓库的拷贝，这时就要用到gitclone命令。Git克隆的是该Git仓库服务上的几乎所有数据（包括日志信息、历史记录等)，而不仅仅是复制工作所需要的文件。当你执行git clone 命令的时候，默认配置下远程Git仓库中的每一个文件的每一个版本都将被拉取下来。

语法结构：

git clone 远程仓库地址url

移除无效的远程仓库

如果因为一些原因想要移除一个远程仓库，可以使用git remote rm

语法结构:

git remote rm 远程仓库名字

注意：

此命令只是从本地移除远程仓库的记录，并不会真正影响到远程仓库。

Git远程仓库_推送、抓送和拉取

Git远程仓库_推送

当你想分享你的代码时，可以将其推送到远程仓库。

语法结构：

git push [remote-name][branch-name]

从远程仓库中抓取与拉取

语法结构：

git fetch

注意：

git fetch是从远程仓库获取最新版本到本地仓库，不会自动merge，想看见文件就需要手动进行合并文件 git merge origin/master 。

从远程仓库中抓取与拉取

语法结构：

git pull

注意：

git pull是从远程仓库获取最新版本到本地仓库，会自动merge

多人协作冲突问题

为什么会出现冲突问题

不同分支下的合并

同一个分支下的pull后者push

下载远程仓库

git clone https://gitee.com/WCCRegistered/hundred-battles.git wcc
git clone https://gitee.com/WCCRegistered/hundred-battles.git kalista

设置各自用户环境配置

git config --local -user.name ""
git config --local -user.email ""

制造冲突

第一用户修改一个文件并提交

vim a.info
git commit -am"sumbit file"
git push

第二用户慢了一步在提交时发生了报错

vim a.info
git commit -am"sumbit file2"
git push

报错：

$ git push To ​​https://gitee.com/WCCRegistered/hundred-battles.git​​​ ! [rejected] master -> master (fetch first) error: failed to push some refs to '​​https://gitee.com/WCCRegistered/hundred-battles.git​​' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

解决冲突

拉取最新的代码

git pull

查看哪里冲突

new
<<<<<<< HEAD
#你自己写的
this is yunhe
=======
#别人写的并且提交了的代码
public class HelloWorld{}
>>>>>>> 0b8b926afc79bd22d220bd0cb76ef7d97b5fb5d4

注意:

手动删除不要的代码。

重新提交

git commit -am"修改了用户头像信息"
git push

SSH协议推送

Git支持的传输协议

由于Git的远程仓库不在我们本地，当我们在使用远程仓库的时候(例如克隆，拉取，推送)就会涉及到数据的网络传输，Git支持多种数据传输协议，包括：

• 本地协议(Local)
• HTTPS协议
• SSH(Secure Shell)协议
• Git协议

什么是SSH协议

SSH为Secure Shell(安全外壳协议)的缩写，由IETF的网络小组(Network Working Group)所制定。SSH是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用SSH协议可以有效防止远程管理过程中的信息泄露问题。

配置SSH协议

以使用Git提供的命令行工具Git Bash生成公钥和私钥，具体操作过程如下：

1.使用命令ssh-keygen -t rsa生成公钥和私钥

ssh-keygen -t rsa

注意：

执行完成后在window本地用户.ssh目录(C:\Users\用户名.ssh)下生成如下名称的公钥和私钥。

2.复制公钥文件内容至服务器上

3.配置完成后就可以正常传输数据了

Git分支

使用分支原因

几乎所有的版本控制系统都以某种形式支持分支。使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。

查看分支

列出版本库中的分支名。

语法结构：

git branch

参数：

• -r : 列出所有远程分支
• -a ：列出所有本地分支和远程分支

创建分支

语法结构：

git branch 分支名字

参数：

• -m 修改分支名字

切换分支

语法结构：

git checkout b1

Git分支_推送至远程仓库分支

语法结构：

git push 远程仓库名字 分支名字

合并分支

对分支的误解

上节虽然介绍了如何使用分支，但我相信有些小伙伴对分支还是有些误解的。

你认为的分支是什么样的

分支是什么

有人可能认为，所谓的“开分支”，就是把文件先复制到另外的目录，然后进行改动,之后再合并，把文件与原本的文件比对之后放回原来的目录……其实，Git不是这样做的。

分支像贴纸一样

可以把分支想象成一张贴纸，贴在某一个Commit上面。

当做了一次新的Commit之后，这个新的Commit会指向它的前一个Commit。

而接下来“当前的分支”，也就是HEAD所指的这个分支，会贴到刚刚做的那个Commit 上,同时HEAD也会跟着前进。

结论：

Git中的分支并不是通过复制目录或文件来进行改动形成的，它就是一个指标、一张贴纸，贴在某个Commit 上而已。

一个分支不够，就来两个

如果一个分支不够说明，那就来两个。通过git branch cat命令创建一个新的分支。它就像一张贴纸，与master贴在同一个地方。

接下来执行git checkout cat命令，切换到cat分支。此时, HEAD转而指向cat分支，表示它是“当前的分支”。

接着进行一次新的Commit，这个新的Commit会指向前一次Commit。

然后，cat分支上的“贴纸”就会被撕下来，转而贴到最新的那个Commit上;当然HEAD也是一样。

合并分支

语法结构：

git merge b1

切换分支Git干了什么

主要做2件事

更新暂存区和工作目录

变更HEAD的位置

合并过的分支要保留吗

合并后，原本没有的内容都有了，而分支本身又像一张贴纸一样“地位低微”，那么它也就没有利用价值了。所以，合并过的分支想删就删吧。

删除分支

删除本地仓库分支

语法结构：

git branch -d b1

参数：

• -d 删除本地分支

注意：

如果要删除的分支中进行了一些开发动作，此时执行上面的删除命令并不会删除分支，如果坚持要删除此分支，可以将命令中的-d参数改为-D 。

不小心把还没合并的分支删除了，救得回来吗

合并过的分支想留就留、想删就删，Git的分支并不是复制文件到某个目录，所以不会因为删掉分支文件就不见了。

注意：

但如果删除的是还未合并的分支就不一样了。

cat分支是从master分支出去的，当前领先master分支两次 Commit，而且还没有合并过。这时如果试着删掉cat分支，它会提醒:"这个分支还没全部合并哦"。

$ git branch -d cat
error: The branch 'cat' is not fully merged.
If you are sure you want to delete it, run 'git branch -D cat'.

虽然Git这么贴心的提醒了，但这里仍然把它删除了

git branch -D cat
Deleted branch cat(was b1729234)

上面不是已经删除cat分支了吗，怎么还在?这里再次跟大家说明一下分支的概念:分支只是一个指向某个Commit的指标，删除这个指标并不会使那些Commit消失。

git branch new_cat b2323b

注意：

这个命令"请帮我创建一个叫做new_cat的分支，让它指向17b23n3这个Commit"，也就是在拿一张贴纸贴回去。

git branch

切换过去看看

git checkout new_cat

确认一下文件列表

ls -al

删除远程仓库分支

语法结构：

git push origin -d 分支名字

分支综合练习

工作场景如下

为实现某个新的需求，创建一个分支(dev)。在这个分支上开展工作。正在此时，你突然接到一个电话说有个很严重的问题需要紧急修补。

你将按照如下方式来处理:

切换到你的线上分支(master)。

为这个紧急任务新建一个分支(fix)，并在其中修复它。

在测试通过之后，切换回线上分支(master)。

然后合并这个修补分支(fix)，最后将改动推送到线上分支(master)。

切换回你最初工作的分支上（dev）,继续工作。

创建dev分支

git branch dev

切换分支

git checkout dev

创建UserDao.java文件

#在dev分支开发一些新的功能
public class UserDao{}

提交dev分支的文件

git add UserDao.java
git commit -m "add userdao.java in dev branch"

切换master分支

git checkout master

创建新的修复分支fix

git branch fix

切换fix分支

git checkout fix

修复问题

vim a.info

提交修改文件到本地仓库

git commit -a -m "fix update a.info"

切换master分支

git checkout master

合并分支

git merge cat

推送到线上分支

git push

切换到dev分支

git checkout dev

标签概念

标签是什么

Git可以给历史中的某一个提交打上标签，以示重要。比较有代表性的是人们会使用这个功能来标记发布结点(v1.0、v1.2等)。标签指的是某个分支某个特定时间点的状态。通过标签，可以很方便的切换到标记时的状态。

什么时候用标签

通常开发软件时会完成特定的“里程碑”，如软件版号1.0.0或beta-release之类的，这时就很适合使用标签做标记。

标签与分支有什么区别

标签与分支的区别是，分支会随着Commit而移动，但标签不会。之前介绍过当Git往前推，进一个Commit时，它所在的分支会跟着向前移动。而标签一旦贴上去不管Commit怎么前进，标签都会留在原来贴的那个位置上。因此，分支可以看成是“会移动的标签”。

注意：

这两者在被删除的时候，都不会影响到被指到的那个对象。

标签基本操作

列出已有标签

语法结构：

git tag

创建标签

语法结构：

git tag 标签名字

查看标签信息

语法结构：

git show 标签名

标签推送远程仓库

语法结构：

git push [remote] [tag]

检出与删除标签

检出标签

新建一个分支，指向某个tag

git checkout -b [branch] [tag]

删除标签

删除本地标签

语法结构：

git tag -d [tag]

删除远程标签

语法结构：

$ git push origin :refs/tags/标签名字

注意：

:refs/tags/是固定写法。

Git工作流

Git Flow是什么

Git Flow是什么

在使用Git的过程中如果没有清晰流程和规划，否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。GitFlow工作流通过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。

Git Flow 的常用分支

解释：

• master 主干分支，开发完成的上线的项目版本
• hotixes 热部署分支，进行主干分支的补丁操作
• release 预部署分支，测试工程师的调用的分支
• develop 开发分支，开发源代码分支
• feature 功能分支，你们调用分支

Master/Devlop 分支

所有在Master分支上的Commit应该打上Tag，一般情况下Master不存在Commit，Devlop分支基于Master分支创建

Feature 分支

Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留。

Release 分支

Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature 发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。

注意：

一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支。

Hotfix 分支

hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag。

工作方式示例

在IDEA使用Git

配置Git

安装好IntelliJ IDEA后，如果Git安装在默认路径下，那么idea会自动找到git的位置，如果更改了Git的安装位置则需要手动配置下Git的路径。 选择File→Settings打开设置窗口，找到Version Control下的git选项:

配置git

在IDEA中创建工程并将工程添加至Git

新建项目

创建maven项目

基本操作

忽略列文件

安装ignore插件并重启

新建.gitignore文件

添加忽略项

# Created by .ignore support plugin (hsz.mobi)
gitignore
idea/*
HelloWorld.iml
target

将文件加入暂存区

提交文件

编写提交信息

推送至远程仓

填写远程仓库url地址

提交到远程仓库

从远程仓克隆

从远程仓库拉取

版本对比

分支操作

创建分支

创建并切换

切换分支

分支合并

解决冲突

手动解决冲突

手动修改最终版本

最后提交代码