理解Git分支管理最佳实践_rebasing develop

git常用命令：
1：git remote update origin --prune //更新远程分支列表
2：git branch -a //查看服务器上所有分支列表
3：git push origin -d BranchName //删除分支
其中-d也可以是–delete
git push origin --delete BranchName
4:git reflog --date=local | grep 分支名 //查看分支是从哪个分支创建的
5： 删除git标签
删除本地标签命令
git tag -d 标签名
删除远程标签命令
git push origin :refs/tags/标签名

一、分支分类

根据生命周期区分：
主分支：master，develop；
临时分支：feature/，release/，hotfix/；
根据用途区分：
发布/预发布分支：master，release/；
开发分支：develop；
功能分支：feature/；
热修复分支：hotfix/；

二、分支的用途

• master：作为发布分支，随时可以将分支上的代码部署到生产环境上。如果在生产环境上发现问题，则以 master 为基准创建
  hotfix/* 分支来修复问题；
• develop：作为开发分支，所有最新的功能都将在该分支下进行开发，develop 也将是所有分支中功能最全，代码最新的一个分支；
• feature/*：命名规则feature/功能名称，作为新功能的开发分支，该分支从 develop 创建，开发完毕之后需要重新合并到develop；
• release/：命名规则release/v+发布的版本号，作为预发布分支，release/ 只能develop 创建，且在git flow中同一个时间点，只能存在一个预发布分支。只有当上一个版本发布成功之后删除该分支，之后才能进行下一个版本的发布。如果在预发布过程中发现了问题，只能在release/* 分支上进行修改；
• hotfix/*：命名规则hotfix/v+bug修复的版本号，作为热修复分支，只能从 master
  分支分离出来。主要是用来修复在生产环境上发现的 bug，修复完成并测试通过后需要将该分支合并回 develop 及 master上，并删除该分支；

三、Git 分支管理流程

在上一部分，我们已经明确了每个主分支及辅助分支的用途与来源了，下面我们就来详细了解一下 Git 分支管理的整个流程。先来看一下分支在完整的功能开发中是如何演变的：

从上图我们可以看出，我们同时开始了两个功能的开发/研究任务，下面我将以此为基础来讲解分支管理的流程。
1. 先拉取最新的 develop 分支，然后以最新的 develop 为基准创建两个新的功能分支 feature/f1 和 feature/f2；

git pull origin develop
git checkout -b feature/f1 develop
1
2

2. 开发人员在各自的功能分支上进行开发工作，等当前功能分支开发完之后，将当前分支交由测试人员进行测试，测试过程中的问题修复及功能修改均在当前功能分支上进行；
3. 当 feature/f1 上的开发及测试任务均完成之后，将 feature/f1 合并回 develop ，并删除 feature/f1 ；

git checkout develop
git merge --no-ff feature/f1
git branch -d feature/f1
1
2
3

4. 从 develop 分支创建新的预发布分支 release/0.2，并部署到预发布环境上测试。在预发布过程中发现问题则直接在 release/0.2 上进行修复；

git checkout -b release/0.2 develop
1

5. 在生产环境中发现一个 bug，从 master 上分离出一个热修复分支 hotfix/bug1，并在上面进行修复、测试并在预发布环境中验证，当都验证通过之后将分支重新合并回 develop 及 master，并在 master 上打一个热修复 tag v0.1.1，最后删除 hotfix/bug1；

git checkout -b hotfix/bug1 master
....................
....修复bug..ing....
....................
git checkout develop
git merge --no-ff hotfix/bug1
git checkout master
git merge --no-ff hotfix/bug1
git tag v0.1.1
git branch -d hotfix/bug1
1
2
3
4
5
6
7
8
9
10
11

6. 在 feature/f2 分支上的功能 f2 已经开发并测试完成，然后将 feature/f2 合并回 develop，并删除 feature/f2，此时已经存在新功能 f1 的预发布分支 release/0.2，所以需要等待其发布完成之后才能创建预发布分支 release/0.3；

git checkout develop
git merge --no-ff feature/f2
git branch -d feature/f2
1
2
3

7. 预发布分支 release/0.2 在预发布环境中完全测试通过，随时可以部署到生产环境。但在部署到生产环境之前，需要将分支合并回 develop 及 master，并在 release/0.2 上打一个正式发布版本的 tag v0.2，最后删除 release/0.2；

git checkout develop
git merge --no-ff release/0.2
git checkout master
git merge --no-ff release/0.2
git tag v0.2
git branch -d release/0.2
1
2
3
4
5
6

8. 当前已经不存在 release/* 预发布分支，所以可以开始功能 f2 的预发布上线。创建预发布分支 release/0.3，并部署预发布环境测试；

git checkout -b release/0.3 develop
1

9. 分支 release/0.3 测试通过，将 release/0.3 合并回 develop 及 master，然后在 master 上打一个正式发布版本的 tag v0.3，最后删除 release/0.3；

四、Git Flow

上述过程中未使用到 git flow，均是以约定的规范流程进行，大家可以尝试使用 git flow 来管理分支。

#初始化 git flow
# 设置 feature、release、hotfix、tag 的前缀名
git flow init
 
#开始一个新功能 f1 的开发，以 develop 为基准创建 feature/f1
git flow feature start f1
 
#....................
#....f1 功能开发中....
#....................
 
#新功能 f1 开发完成
# 合并回 develop
# 删除 feature/f1 分支
git flow feature finish f1
 
#开始新功能 f1 的预发布验证，版本定为 0.2
git flow release start 0.2
 
#新功能 f1 预发布验证通过
# 合并到 master 分支
# 在 release 上打 tag v0.2
# 将 tag v0.2 合并到 develop 分支
# 删除 release/0.2 分支
git flow release finish 0.2
 
#开始 bug1 的修复，以 master 为基准创建 hotfix/bug1
git flow hotfix start 0.2.1
 
# bug1 修复完成
# 合并到 master 分支
# 在 hotfix 上打 tag v0.2.1
# 将 tag v0.2.1 合并到 develop 分支
# 删除 hotfix/0.2.1 分支
git flow hotfix finish 0.2.1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

五、IDEA操作git

1、合并多次提交记录（提交到本地记录未push到git服务器）

现在将最近两次的已经commit的记录合并成一个commit：

选择这两条最早的一次提交记录，右键选择 Interactively Rebase from Here…：

弹出框如图，将最新一次提交改为squash，然后点击Start Rebasing：

备注1，关于时间线：
Log 框时间线：是从上到下，越来越早。
弹出框时间线：是从上到下，越来越晚。
备注2，Rebasing Commits框中第一列Action的含义如下：
选择pick操作，git会应用这个补丁，以同样的提交信息（commit message）保存提交
选择reword操作，git会应用这个补丁，但需要重新编辑提交信息
选择edit操作，git会应用这个补丁，但会因为amending而终止
选择squash操作，git会应用这个补丁，但会与之前的提交合并
选择fixup操作，git会应用这个补丁，但会丢掉提交日志
选择exec操作，git会在shell中运行这个命令

在弹出如下图框，默认会将两次提交的信息都展示，你可以改成你想推送到远程分支的信息：

修改后如下图，修改完成后点击Resume Rebasing：

然后你会发现，在Log框中：

最后不要忘了push！！！

2、合并多次提交记录（已push到git服务器记录）

针对下列4种需求都能ok：
1.合并多次已push的记录
2.合并多次记录，其中既有commit，又有已push的记录
3.将多次已push的记录回退至某一版本
4.将多次记录回退至某一版本，其中既有commit，又有已push的记录

现在最近4次记录，v1、v2和v3都已经push，v4只commit了!
我想将v1~至v4合并成一个记录在提交
(1).那么右击v1之前的一次记录，选择Reset Current Branch To Here…

(2).然后选择Soft类型，最后点击Reset按钮

(3).发现v1~v4的提交记录不在日志记录中了

(4).点击提交按钮，发现v1~v4的所有更改都在等着提交(注意TestQuanRan.java文件是V1版本中新增的文件！！！)。

(5).上图选中Changelist里的所有更改文件，最后点击提交按钮Commit之后，如下图：
(6).最重要的一步，一定要强制推送！强制推送！强制推送！原因是因为，本地分支的版本已经低于远程分支，需要使用强制推送设置远程分支为推送的低版本分支！！！

(7).强制推送 成功，即合并成功！！
3.我想将v1~至v4取消代码，回退至v1版本的上一版本。
(1).同第2步里的第(1)步
(2).不同与第2步里的第(2)步，这里选择Hard ！！！而不是Soft。
(3).同第2步里的第(3)步
(4).直接强制推送，界面如图

(5).强制推送 成功，即回退成功！

3、版本回退（IDEA操作git回退指定版本）

1. 项目右键后，然后在“Show History”中找到当前版本（暂时取名newVersion）和想要回退到的版本（暂时取名oldVersion）

2. 选择oldVersion版本右键点击“Copy Revision Number”复制oldVersion版本的版本号：

3. 然后右击项目依次选中：Git->Repository->Reset HEAD

4. Reset Type项选择Hard，To Commit项填写刚刚复制的版本号；然后点击Reset按钮

5. 这时本地代码已经回退到oldVersion，这时候如果直接push到远程仓库，会提示版本冲突，点击“cancel”取消。


6. 下面有两种解决冲突的方法 （我选择的第一种）

方法一 ：不解决，直接强制提交：
a. 打开Terminal，切换到项目所在目录
b. 执行：git push -f

方法二：
a. 右击项目依次选中：Git->Repository->Reset HEAD
b. Reset Type项选择Mixed, To Commit项填写最新提交记录版本号（切记是最新分支的版本号newVersion分支）；然后点击Reset按钮

c. 这时你会发现，最新版本有回到newVersion。但是代码还是oldVersion的代码，这时候重push到远程仓库就不会版本冲突了

此方法代码会回滚 但是分支不会

7. 方法一vs方法二
方法一会将回退的提交记录抹点，而方法二会保留