理解Git分支管理最佳实践

理解Git分支管理最佳实践

  • 一、分支分类
  • 二、分支的用途
  • 三、Git 分支管理流程
  • 四、Git Flow
  • 五、IDEA操作git
    • 1、合并多次提交记录(提交到本地记录未push到git服务器)
    • 2、合并多次提交记录(已push到git服务器记录)
    • 3、版本回退(IDEA操作git回退指定版本)

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 分支管理的整个流程。先来看一下分支在完整的功能开发中是如何演变的:
理解Git分支管理最佳实践_第1张图片
从上图我们可以看出,我们同时开始了两个功能的开发/研究任务,下面我将以此为基础来讲解分支管理的流程。
1. 先拉取最新的 develop 分支,然后以最新的 develop 为基准创建两个新的功能分支 feature/f1 和 feature/f2;

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

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

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

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

git checkout -b release/0.2 develop

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

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

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

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

git checkout -b release/0.3 develop

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

五、IDEA操作git

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

现在将最近两次的已经commit的记录合并成一个commit:
理解Git分支管理最佳实践_第2张图片
选择这两条最早的一次提交记录,右键选择 Interactively Rebase from Here…:
理解Git分支管理最佳实践_第3张图片
弹出框如图,将最新一次提交改为squash,然后点击Start Rebasing:
理解Git分支管理最佳实践_第4张图片
备注1,关于时间线:
Log 框时间线:是从上到下,越来越早。
弹出框时间线:是从上到下,越来越晚。
备注2,Rebasing Commits框中第一列Action的含义如下:
选择pick操作,git会应用这个补丁,以同样的提交信息(commit message)保存提交
选择reword操作,git会应用这个补丁,但需要重新编辑提交信息
选择edit操作,git会应用这个补丁,但会因为amending而终止
选择squash操作,git会应用这个补丁,但会与之前的提交合并
选择fixup操作,git会应用这个补丁,但会丢掉提交日志
选择exec操作,git会在shell中运行这个命令

在弹出如下图框,默认会将两次提交的信息都展示,你可以改成你想推送到远程分支的信息:
理解Git分支管理最佳实践_第5张图片
修改后如下图,修改完成后点击Resume Rebasing:
理解Git分支管理最佳实践_第6张图片
然后你会发现,在Log框中:
理解Git分支管理最佳实践_第7张图片
最后不要忘了push!!!
理解Git分支管理最佳实践_第8张图片

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…
理解Git分支管理最佳实践_第9张图片
(2).然后选择Soft类型,最后点击Reset按钮
理解Git分支管理最佳实践_第10张图片
(3).发现v1~v4的提交记录不在日志记录中了
理解Git分支管理最佳实践_第11张图片
(4).点击提交按钮,发现v1~v4的所有更改都在等着提交(注意TestQuanRan.java文件是V1版本中新增的文件!!!)。
理解Git分支管理最佳实践_第12张图片
(5).上图选中Changelist里的所有更改文件,最后点击提交按钮Commit之后,如下图:
(6).最重要的一步,一定要强制推送!强制推送!强制推送!原因是因为,本地分支的版本已经低于远程分支,需要使用强制推送设置远程分支为推送的低版本分支!!!
理解Git分支管理最佳实践_第13张图片
(7).强制推送 成功,即合并成功!!
3.我想将v1~至v4取消代码,回退至v1版本的上一版本。
(1).同第2步里的第(1)步
(2).不同与第2步里的第(2)步,这里选择Hard !!!而不是Soft。
(3).同第2步里的第(3)步
(4).直接强制推送,界面如图
理解Git分支管理最佳实践_第14张图片
(5).强制推送 成功,即回退成功!

3、版本回退(IDEA操作git回退指定版本)

1. 项目右键后,然后在“Show History”中找到当前版本(暂时取名newVersion)和想要回退到的版本(暂时取名oldVersion)
理解Git分支管理最佳实践_第15张图片
2. 选择oldVersion版本右键点击“Copy Revision Number”复制oldVersion版本的版本号:
理解Git分支管理最佳实践_第16张图片
3. 然后右击项目依次选中:Git->Repository->Reset HEAD
理解Git分支管理最佳实践_第17张图片
4. Reset Type项选择Hard,To Commit项填写刚刚复制的版本号;然后点击Reset按钮
理解Git分支管理最佳实践_第18张图片
5. 这时本地代码已经回退到oldVersion,这时候如果直接push到远程仓库,会提示版本冲突,点击“cancel”取消。
理解Git分支管理最佳实践_第19张图片
理解Git分支管理最佳实践_第20张图片
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方法二
方法一会将回退的提交记录抹点,而方法二会保留

你可能感兴趣的:(软件项目运维)