这是机器未来的第61篇文章

原文首发地址：https://robotsfutures.blog.csdn.net/article/details/127684442

Git企业版本管理__2022-11-07+01_06_24

《Git源码版本管理系列》快速导航：

【Git从入门到精通 | 01】企业Git使用github工作流最佳实践

文章目录

《Git源码版本管理系列》快速导航：
1. 前言
2. 主要分支介绍
3. 新功能开发工作流
4. 发布后的产品Bug修复工作流
5. 日常开发过程中常用操作
- 5.1 撤销操作
6. 总结

写在开始：

博客简介：专注AIoT领域，追逐未来时代的脉搏，记录路途中的技术成长！

博主社区：AIoT机器智能, 欢迎加入！

专栏简介：从0到1掌握企业常用的版本控制技能。

面向人群：软件工程师

1. 前言

本文描述了企业多人协作开发常用的github flow工作流，涉及发布分支、开发分支、测试分支、bug分支、特性分支等分支管理，以及版本回退等。

2. 主要分支介绍

工作流

2.1 master分支

主分支，产品的功能全部实现后，最终在master分支对外发布。

2.2 develop分支

开发分支，基于master分支克隆，产品的编码工作在此分支进行。

2.3 release分支

测试分支，基于delevop分支克隆，产品编码工作完成后，发布到本分支测试，测试过程中发现的小bug直接在本分支进行修复，修复完成后合并到develop分支。本分支属于临时分支，目的实现后可删除分支。

2.4 bugfix分支

Bug修复分支，基于master分支或发布的里程碑Tag克隆，主要用于修复对外发布的分支，收到客户的Bug反馈后，在此分支进行修复，修复完毕后分别合并到develop分支和master分支。本分支属于临时分支，目的实现后可删除分支。

2.5 feature分支

功能特征分支，基于develop分支克隆，主要用于多人协助开发场景或探索性功能验证场景，功能开发完毕后合并到develop分支。feature分支可创建多个，属于临时分支，目的实现后可删除分支。

3. 新功能开发工作流

3.1 切换到本地仓库工作区

cd /home/timerhunter/workspace

3.2 从远程仓库克隆代码到本地仓库

$git clone https://xxxx@localhost:8443/r/valve/V5-Lora.$git

3.3 基于master分支，创建develop分支

/* 切换到master分支 */
$git checkout master
/* 基于master分支克隆develop分支，并在克隆完毕后直接跳转到develop分支 */
$git checkout -b develop
/* 推送develop分支到远程仓库 */
$git push origin develop

**注：编码工作主要在develop分支，master分支主要用来发布稳定版本 **

3.4 在本地仓库的开发流程

完成一个功能点或者一天的工作结束时，将代码提交到本地仓库

/* 提交修改到缓冲区 */
$git add .
/* 提交修改到本地仓库 */
/* 如果是修复的BUG，应该在修改说明的最开始添加Bug#ID，多个Bug用逗号分隔，例如Bug#002,003 */
/* 如果是完成了一个指派的任务，应该在修改说明的最开始添加Task#TaskID,例如Task#165 */
$git commit -m "Bug#123 修改说明"
/* 每完成一个功能点可以对代码进行打包 */
$git tag -m "简要说明增加/修复/删除了什么功能" v0.0.0.170718

注：不是每一个Tag都需要提交到远程仓库，比如可以在完成一个功能点的编码工作后未编译就打一个包，仅存储于本地仓库，在编译成功&测试通过后，再打一个新的Tag包（里程碑Tag包），仅将里程碑Tag包推送到远程仓库

3.5 推送代码到远程仓库

当完成一个功能点或阶段工作时，将代码推送到远程仓库develop分支

/* 执行代码拉取操作，防止代码冲突 */
$git pull
/* 解决代码冲突后，推送代码到远程仓库*/
$git push origin develop

注：禁止将未编译或编译不通过的代码提交到远程仓库，如果编码工作进行未完成可以提交到本地仓库中，等待该功能点全部实现后再将代码推送到远程仓库中。

3.6 将代码发布到测试分支

阶段性的开发工作已完成，启动小批量测试工作，将代码发布到测试分支release

$git checkout develop
$git checkout -b release
$git push origin release

3.7 测试工程师提交Bug后修复

从远程仓库拉取代码

/* 克隆仓库 */
$git clone https://[email protected]:8443/r/admin/test.$git
/* 查看远程仓库分支情况：克隆仓库时只能克隆master分支，因此需要拉取指定分支，我们使用$git branch -r查看远程分支情况 */
$git branch -r
  origin/HEAD -> origin/master
  origin/dev
  origin/master
  origin/release
/* 拉取测试分支 */
$git checkout -b release origin/release

修复流程同#2.4，#2.5；
注意在$git commit时的修复说明中添加Bug#BugID关键字
完成一个Bug修复或完成阶段性工作后，将代码推送到远程分支

3.8 测试工作完成后，合并代码到develop分支

/* 切换到develop分支 */
$git checkout develop
/* 执行合并操作,将release分支代码合并到develop分支 */
$git merge release
/* 如果合并报错，则解决冲突，冲突解决后继续再次执行合并 */

3.9 开发工作和测试工作都完毕后，发布时将develop分支合并到主线

$git checkout master
$git merge develop

3.10 阶段开发完毕，打一个里程碑Tag包

/* 创建里程碑Tag */
$git tag -m "Task#003 v1.0.0 首版发布" v1.0.0.170718
/* 推送里程碑Tag到远程仓库 */
$git push origin v1.0.0.170718

4. 发布后的产品Bug修复工作流

4.1 获取Bug产品的软件发布版本号

4.2 查找里程碑Tag

 /* 查询里程碑及其提交说明 */
 $git tag -n1 -l v*

4.3 基于里程碑Tag创建分支

 /* git checkout -b [创建的分支名称] [里程碑Tag名称] */
 $git checkout -b bugfix-v1.0.0.170718 v1.0.0.170718

4.4 修复代码后可以查询修改过的地方

 $git diff

4.5 修复完毕后分别合并到develop分支和master分支

/* 合并到develop */
$git checkout develop
$git merge hotfix-v1.0.0.170718
/* 提交到远程仓库develop分支 */
$git push origin develop
/* 合并到master：如果随下一个版本再发布，可不用合并至master分支 */
$git checkout master
$git merge develop
/* 提交到远程仓库master分支 */
$git push origin master

4.6 创建新的里程碑Tag

 $git tag -m "Bug#002 修复某某Bug" v1.0.1.170719
 /* 推送到远程仓库 */
 $git push origin v1.0.1.170719

4.7 删除bugfix分支

/* 删除本地分支-$git branch -d [本地分支名]*/
$git branch -d bugfix-v1.0.0.170718
/* 删除远程分支-$git push origin :[远程分支名]*/
$git push origin :bugfix-v1.0.0.170718

4.8 多版本并行时仅合并部分修改

这里就要用到cherry-pick了，cherry-pick支持仅合并其它分支单次提交的修改到当前分支，语法为：

git cherry-pick [commitid]

举例说明：
因不同客户需求不一样，有时候会出现多个版本并行的情况，需要同时维护多个版本，出现bug后验证后，需要同步到所有分支版本。

# 切换到v4.66.0.0分支
$ git checkout 4.66.0.0
Switched to branch '4.66.0.0'
# 查看最近三次提交
$ git log --oneline -3
23d9422 [Description]:4.66.0.0 commit 3
2555c6e [Description]:4.66.0.0 commit 2
b82ba0f [Description]:4.66.0.0 commit 1

4.66.0.0版本最近添加了2个需求，修复了一个bug，bug提交记录为commit2，那么可以仅将commit2合并到其它分支版本

git cherry-pick 2555c6e

如果出现冲突，在冲突解决后，可以执行

git commit

提交，或者通过

git add .
git cherry-pick --continue

提交

5. 日常开发过程中常用操作

5.1 撤销操作

5.1.1 提交后发现丢了几个文件没有提交

/* 正常提交 */
$git commit -m "发布v1.0"
/* 发现丢了修改记录，重新添加 */
$git add CHANGELOG.md
/* 重新提交,仍以"发布v1.0的名义提交"，最终只有一个提交*/
$git commit --amend

5.1.2 撤销上一次的提交，但是保留暂存区和当前修改不变

/* 正常提交 */
$git commit -m "发布v1.0"
/* 将会撤销“发布v1.0”的提交，但是保留暂存区和当前目录中文件的修改 */
$git reset --soft HEAD~

5.1.3 撤销上一次的提交和暂存区修改，仅保留当前修改不变

/* 正常提交 */
$git commit -m "发布v1.0"
/* 将会撤销“发布v1.0”的提交，撤销暂存区，但保存当前目录中文件的修改 */
$git reset --mixed HEAD~

5.1.4 撤销上一次的提交，并丢弃所有修改，包括暂存区和当前目录中的修改，整体回档到上上次的提交

/* 正常提交 */
$git commit -m "发布v1.0"
/* 将会撤销“发布v1.0”的提交，但是保留暂存区和当前目录中文件的修改 */
$git reset --hard HEAD~

5.1.5 撤销暂存区和当前目录下所有文件的修改，整体回档到上一次提交

注意：此操作非常危险，会丢失所有修改，直接整体回档到指定的版本，谨慎使用

/* 正常提交 */
$git commit -m "发布v1.0"
/* 修改多个文件 */
/* 添加到暂存区 */
git add .
/* 撤销暂存区和本地目录下所有文件的修改，并整体回档到上一次提交的状态 */
$git reset --hard HEAD
/* 可以修改HEAD为SHA-1值回档到任意版本 */
/* 使用git log查看每次提交的SHA-1值，可以仅指定前7位 */
$git reset --hard 745d8cd

5.1.6 将文件提交到暂存区后撤回

在对文件执行git add操作后，重新撤回

/* 添加文件到暂存区 */
$git add README
/* 将文件从暂存区撤回 */
$git reset HEAD README

5.1.7 撤销对文件的修改

在对文件进行修改后，发现思路不对，需要将文件恢复至原有状态

/* 撤销对CHANGELOG.md文件的修改，请注意这是一个危险的命令，
 * 对指定文件的修改都会被取消，会还原成上次提交的样子 */
$git checkout -- CHANGELOG.md

6. 总结

本文描述了企业开发过程中软件工程师常用的工作流，后续还会发布适合小团队或一人一个项目的gitlab工作流的使用方法，gitlab版本控制软件的搭建，持续开发/持续集成(CI/CD)，自动化测试的相关内容，敬请期待！

— 博主热门专栏推荐 —

【Git从入门到精通 | 01】Git源码管理github工作流实践