1.idea中使用Git

1.1.idea配置Git和Gitee

第一步：设置git.exe的安装路径。**点击菜单

File -> Settings -> Version Control -> Git

，设置Path to Git executable的值为：C:\software\Git\bin\git.exe。**

**请将上述路径

C:\software\Git\bin\git.exe

改为自己git的安装目录；点击右边的test按钮，应该显示成功消息及git的版本信息。**

第二步：安装Gitee插件。点击菜单

File -> Setttings -> Plugins

下载Gitee插件，安装完成后重启idea使其生效。

第三步：配置Gitee账号。点击菜单

File -> Settings -> Version Control -> Gitee

，点击右侧+号添加Gitee账号，总共有2种方式：账号密码方式和私人令牌方式。

登录到Gitee，点击

设置 -> 私人令牌

，点击 +生成新令牌 即可生成私人令牌，最后将私人令牌复制到idea中即可（即使用私人令牌方式登录Gitee）。

1.2.实践操作

1.2.1.将本地项目推送到远程

**点击菜单

VCS -> Import into Version Control -> Share Project On Gitee

，输入远程仓库名、勾选是否是私库，最后点击Share按钮将本地项目推送到远程库。**

最后，可以再Gitee中的仓库里看到刚刚推送的仓库及仓库中项目。

之后，即可在idea中的右键项目选择Git菜单，进行Git三部曲操作（add/commit/push）。

• 新增项目文件

此时文件为新增状态，以红色状态显示。

• 保存暂存区

点击Add按钮，新增文件将被保存到暂存区，此时文件为绿色状态。

• 提交到本地仓库

右键项目，选择

Git -> Commit Directory

，在弹窗中输入Commit Message，点击commit，此时项目文件从暂存区真正进入版本库(本地)中，项目文件变成白色。（这里要注意如果idea是白色风格，那么文件将会是黑色）

• 修改文件

修改已提交的文件后，此时文件将变成蓝色，蓝色代表已修改状态。

• 推送和拉取

右键项目点击

Git -> Repository -> Push

，将本地项目推送到远程库。 右键项目点击

Git -> Repository -> Pull

，将远程库代码更新到本地。

1.2.2.从远程库克隆项目到本地

打开idea，选择

Get From Version Control

。

2.Git Flow

2.1.什么是Git Flow

Git Flow是git的一种工作流程规范，由Vincent Driessen最先提出来,目的是为了解决分支和commit杂乱无章的问题。在实际开发过程中，若多名程序员开发同一个项目时很容易造成代码混乱甚至代码丢失的情况，而合理的运用gitflow规范可以很好地解决这个问题。如果你的公司很重视代码review，那么gitflow更是你的不二之选。

2.2.工作流程

Git Flow的分支主要分为两大类：主分支和辅助分支。其中主分支包含主要分支和开发分支，而辅助分支包含功能分支、预发分支、热修复分支以及其他自定义分支。

• 主要分支（Master）

主要分支上存放的是最稳定的正式版本，并且该分支的代码应该是随时可在生产环境中使用的代码。当一个版本开发完毕后，产生了一份新的稳定的可供发布的代码时，主要分支上的代码要被更新。同时，每一次更新，都需要在主要分支上打上对应的版本号。

任何人不允许在主要分支上进行代码的直接提交，只接受其他分支的合入。原则上主要分支上的代码必须是合并自经过多轮测试及已经发布一段时间且线上稳定的预发分支。

• 开发分支（Develop）

开发分支是主开发分支，其上更新的代码始终反映着下一个发布版本需要交付的新功能。当开发分支到达一个稳定的点并准备好发布时，应该从该点拉取一个预发分支并附上发布版本号。

开发分支接受其他辅助分支的合入，最常见的就是功能分支，开发一个新功能时拉取新的功能分支，开发完成后再并入开发分支。需要注意的是，合入开发的分支必须保证功能完整，不影响开发分支的正常运行。

• 功能分支（Feature）

功能分支一般命名为 Feature/xxx，用于开发即将发布版本或未来版本的新功能或者探索新功能。该分支通常存在于开发人员的本地代码库而不要求提交到远程代码库上，除非几个人合作在同一个功能分支开发。

功能分支只能拉取自开发分支，开发完成后要么合并回开发分支，要么因为新功能的尝试不如人意而直接丢弃。

• 预发分支（Release）

预发分支一般命名为 Release/1.2（后面是版本号），该分支专为测试—发布新的版本而开辟，允许做小量级的Bug修复和准备发布版本的元数据信息（版本号、编译时间等）。通过创建预发分支，使得开发分支得以空闲出来接受下一个版本的新的功能分支的合入。

预发分支需要提交到服务器上，交由测试工程师进行测试，并由开发工程师修复Bug。同时根据该分支的特性我们可以部署自动化测试以及生产环境代码的自动化更新和部署。

预发分支只能拉取自开发分支，合并回开发分支和主要分支。

• 热修复分支（Hotfix）

热修复分支一般命名为Hotfix/1.2.1（后面是版本号），当生产环境的代码（主要分支上代码）遇到严重到必须立即修复的缺陷时，就需要从主要分支上指定的tag版本（比如1.2）拉取热修复分支进行代码的紧急修复，并附上版本号（比如1.2.1）。这样做的好处是不会打断正在进行的开发分支的开发工作，能够让团队中负责功能开发的人与负责修复的人并行、独立的开展工作。

热修复分支只能主要分支上拉取，测试通过后合并回主要分支和开发分支。

2.3.实践操作

第一步：在Master分支（主分支）上由项目经理开启新项目，搭建框架。（这时可以定义一个初始版本号，例如：v1.0.0）

请手动模拟项目经理操作，在git项目目录下创建aa.txt和bb.txt。

初始化git项目

git init

将手动添加的项目文件全部提交到暂存区

git add .

提交到本地仓库

git commit -m "搭建项目"

第二步：创建Dev分支（开发分支），并切换到Dev分支，编写程序。（这时程序员们开始干活了）

请手动模拟开发人员操作，在git项目目录下创建cc.txt和dd.txt。

**# 创建并切换到Dev分支
git checkout -b dev

将手动添加的代码文件添加到dev的暂存区

git add .

提交到本地仓库

git commit -m "一阶段开发完成"**

第三步：若开发阶段性工作完成，准备发布新版本，这时需要创建Release分支（预发布分支），并切换到Release分支，将Dev分支代码合并到该分支（这时测试工程师开始干活了），测试功能并修复Bug后，合并到Master（主分支）和Dev（开发分支）。

创建release预发布分支

git branch release

查看所有分支情况

git branch -v

这时，请不要急着切换到Release分支，当前任处于dev分支下，请再次手动在git项目中创建ff.txt文件。

将ff.txt添加到暂存区，如果有很多文件需要添加，则请使用git add .

git add ff.txt

提交到本地仓库

git commit -m "ff.txt"

预示着虽然一阶段项目完成了，但是后续开发工作还要继续做，这时再次切换到Release分支上发现并没有ff.txt文件。

切换到release分支

git checkout release

这时，测试工程师在Release分支进行代码测试，并修复测试中遇到的Bug。（可以手动修改Release分支下的代码文件，例如：cc.txt和dd.txt等等）

修改完之后，必须进行add/commit操作。

添加到Release分支的暂存区

git add .

提交到本地仓库

git commit -m "修改release分支的bug"

第四步：切换到Master分支上，将当前的Release分支（预发布分支）上的代码合并到Master分支上，并打上标签v1.0.0。

切换Master分支

git checkout master

将Release分支上的代码更新到Master分支上

git merge release -m "1.0.0"

第五步：切换到Dev分支上，将当前的Release分支（预发布分支）上的代码合并到Dev分支上。

切换Master分支

git checkout dev

将Release分支上的代码更新到Dev分支上

git merge release -m "1.0.0"

第六步：删除当前的Release分支。

删除Release分支

git branch -d release

第七步：若v1.0.0发布版本在生产阶段遇到了Bug，这时则创建Hotfix分支（热修复分支），并切换到Hotfix分支，将Master主分支上v1.0.0版本的代码合并到Hotfix分支上进行修复并测试，测试完成后若无问题，则将当前Hotfix分支上的代码合并到Master（主分支）和Dev（开发分支）上。

创建+切换Hotfix分支

git checkout -b hotfix110

将Master分支上V1.0.0版本的代码合并到Hotfix分支

git merge master -m "修复master分支v1.0.0版本的问题"

模拟代码测试及修复操作。

将修复代码提交到hotfix分支的暂存区

git add .

提交到本地仓库

git commit -m "已在hotfix110分支上修复了代码"

第八步：切换到Master分支，将Hotfix分支上修复测试的代码更新合并到Master分支，并打上标签v1.0.1。

切换到Master分支

git checkout Master

将hotfix110分支上的代码合并到Master分支

git merge -m "合并hotfix110分支上修复的代码"

基于当前修复的代码，在Master分支上打上v1.0.1的标签

git tag -a v1.0.1 -m "v1.0.0问题已修复，标签v1.0.1"

第九步：切换到Dev分支，将Hotfix分支上修复测试的代码更新合并到Dev分支；

切换到Dev分支

git checkout dev

将hotfix110分支上的代码合并到Dev分支

git merge -m "合并hotfix110分支上修复的代码"

第十步：删除当前的Hotfix分支。

删除hotfix110分支

git branch -d hotfix110

如果要开发即将发布版本或未来版本的新功能或者探索新功能，则需要创建Feature分支（功能分支）。在该分支上完成新功能的探索与开发工作，如若没有问题则可以将Feature分支上的代码更新到Dev分支（开发分支）。最后删除该Feature分支。

创建+切换Feature分支

git checkout feature

将dev分支上的代码合并到feature分支

git merge dev -m "探索新功能"

功能探索成功，则合并到原有的Dev开发分支。

切换到dev分支

git checkout dev

将feature分支上探索开发成功的功能合并到dev分支

git merge feature -m "功能探索功能合并代码"

不管是功能探索成功，还是失败，最后都删除Feature分支

删除feature分支

git branch -d feature