PS:禁止拷贝形式转载，转载请以URL形式
| 版本 | 时间 | 描述 |
|---|---|---|
| V1 | 2025.2.12 | 第一版内容编写 |
1. 背景
目前团队逐步成长项目开发分支也越来越多，但是当前团队使用git规范不统一，导致git源码管理困难如：
- commit提交信息各异、
- 一个功能反复提交修改导致分支混乱、
- 分支与标签的不当使用导致分支过多与混乱等。
为了解决这些问题避免源码管理无法跟上业务的增长，本编文章提供较完整流程思路指导团队规范化使用git避免上述问题。
2. 方案
- 能力： git 首先提供了较为底层全面的API，只是负责提供底层能力。
- 模型： git 分支管理模型（gitflow、githubflow、TBD等）这些提供方法论，告诉你何时去操作这些git API。
- 规范： git 应用规范（这一步才是各公司基于前面2个落地到实处的阶段），有了能力和模型基本可以做到落地，但是一些场景是模型没有提及但是实际场景又要解决的，这时候根据当前场景自己完善修改模型最终落地为实际规范。
3. git使用操作
即 git API能力，本编文章默认大家基本会使用git，故内容省略。不会，影响也不大最终本编文章是使用GUI 管理工具source tree 进行演示处理
4. git管理模型
git 分支管理模型（gitflow、githubflow、TBD等）这些提供方法论，告诉你何时去操作这些git API。
如下演示的模型，其参考git flow 和 TBD 分支模型
- master： 主分支，一直为最新的可发布大版本分支，每次合并的新版本配合标签TAG进行记录
- fix： 修复分支，针对master大版本进行BUG修复分支，每当可发布的状态配合TAG标签进行记录
- dev： 开发分支，针对新版本的开发分支根据当前情况酌情选择将sp修复分支的内容合并进当前分支，达到可发布的状态后合并至master 分支当中。
PS:注意
- fix修复版本的commit提交不能及时合并master主线或者dev 开发分支，没有整体流程的保障的话存在历史fix 修复过的问题任会在新的主线版本里面存在。(这个需要如项目版本管理记录好)
5. git应用规范
git应用规范完整的介绍了什么时候做什么,进一步补充git 管理模型达到可以落地的状态。因为git 只是开发的一环所以必须配合开发流程才能描述git 应用规范，本节简述一个基本的开发流程并描述git 在这些开发流程中要干什么即什么时候做什么
方法参考 4. git管理模型
实操参考 6. sourcetree工具使用
- 需求确认
- git 无操作
- 版本规划
- 创建版本分支如V1.0.1-dev/V1.0.1-fix
- 任务执行
- git 是否需要将历史fix 分支的commit提交合并到本分支
- git 正常执行任务推送commit ，参考代码提交规范
- 开发内测
- 内测通过后对git 进行整理，如重复提交合并、错误提交删除、提交顺序优化等
- 内测通过后对git 进行打标签进行标识，后续进行交付
- 正式测试
- 接收到BUG，继续迭代V1.0.1-dev1,2,3,4,5重复循环
- 版本发布
- 正式发布后，打上对应发布标签删除内测标签以及本分支，用标签进行存档
6. sourcetree工具使用
git提供了操作功能，git代码管理模型告诉了我们怎么做，git应用规范完整的介绍了什么时候做什么。这时候我们可以进行一个完整的代码管理了，但是Git提供的功能只能由命令行完成导致操作不够直观以及容易出错。
因此市面上就诞生了很多GUI可视化工具去代替Git命令行完成Git操作，本节通过介绍如何使用Git可视化工具Sourcetree来代替Git命令行操作
6.1 安装
- 获取GIT：git-scm.com/download
- 安装GIT：略
- 获取sourcetreeapp：www.sourcetreeapp.com/
- 安装sourcetreeapp：略
6.2 仓库管理
- 仓库查看
- 克隆仓库
6.3 基础操作
6.3.1 分支操作
- 操作演示：
- 创建本地分支：
- 更新本地分支
- 提交本地分支
- 推送远程分支
- 获取远程分支
- 拉取远程分支
6.3.2 reset （重置提交）
- 含义解释： git reset 命令用于回退版本，可以指定退回某一次提交的版本。该命令有三个主要模式：soft、mixed、hard，每种模式对HEAD、暂存区和工作目录的影响不同
- --soft（软合并）：仅移动本地库的HEAD指针指向选中的提交，暂存区和工作区的代码保持不变。将被回退的提交放入暂存区，可以通过git commit重新提交。
- --mixed（混合合并）：移动本地库的HEAD指针指向选中的提交，并清空暂存区。将回退的变更和暂存区中的内容都放入工作区，需要重新执行git add命令才能再次暂存。
- --hard（强行合并）：移动本地库的HEAD指针指向选中的提交，清空暂存区和工作区。这会撤销所有未提交的更改，并将工作区恢复到指定提交的状态，因此需要谨慎使用，以免丢失重要更改。
- 使用案例：
- 开发成员在本地分支上错误提交了不属于当前分支的commit，需要将本地分支版本进行回退。
- 开发成员需要上传打包好的前端文件至对应分支上，但是本地分支版本过于落后或者有残余历史文件没有及时上传，可以使用reset 直接将本地仓库对齐远程仓库版本后在进行上传。
- 操作演示：
- 本地提交一个错误commit。
- 重置提交，回退至正确提交版本。
6.4 进阶操作
6.4.1 push -f （强制推送）
- 含义解释： 这个命令的作用是将自己本地仓库的代码直接推送至远程仓库，完全以该命令提交的内容为准，之前远程仓库的提交都会被覆盖。
- 使用案例： 开发成员A 上传了错误代码或错误合并，导致远程开发分支版本错误。开发负责人B使用正常的版本强制覆盖远程版本，进行版本同步。
- 操作演示：
- GitLab或对应Git服务器确保操作用户具有强推权限
- SourceTree启用强推选项
3. 选择对应分支进行强制推送
6.4.2 cherry-pick（筛选/遴选）
- 含义解释：
cherry-pick是一种将指定的提交(commit)应用到当前分支的操作。它允许用户从一个分支中挑选出一个或多个特定的提交，并将这些提交复制到当前分支上，而无需将整个分支合并过来 - 使用案例： 正在迭代的版本中没有修复一些BUG，因业务需要新建了一个维护版本并在该版本里面修复了一些BUG并发布，维护版本的这些修复BUG代码提交可以使用cherry-pick（筛选/遴选）这个功能合并到正在迭代的主线版本中。
- 操作演示：
- 新建一个V1.0.0-sp1-devlop分支
- 在V1.0.0-sp1-devlop分支添加了1个功能修复了2个BUG共3个提交
- 推送到远程V1.0.0-sp1-devlop分支
- 筛选其中2个修复BUG提交合并到V1.1.0-devlop分支中
- 推送到远程V1.1.0-devlop分支
6.4.3 rebase（变基）
- 含义解释： 它会将某个分支的提交移到另一个分支的最新提交之后。
- 使用案例： 当前正在开发一个分支A且该分支还在迭代中，这时需要基于该开发分支再开出一个新的分支B，在分支B中进行了提交后分支A又进行了更新，这时候如果分支B要包含分支A的最新提交时，可以使用rebase 变基来完成。
- 操作演示：
- 基于V1.1.0-dev分支新建V1.1.0-sp1-dev分支
- 在V1.1.0-sp1-dev分支新增1个功能提交"X"
- 切换到V1.1.0-dev新增2个功能提交"1"和“2”
- 切换到V1.1.0-sp1-dev分支进行变基使该分支包含提交"1"和“2”
6.4.4 rebase -i（交互式变基）
- 含义解释： 这是交互式变基，它允许你重新排序、合并、删除或者撤销提交。
- 使用案例： 内测前，对Git记录进行整理保持一个干净的分支。对重复提交，错误提交，commit消息错误进行整理修改。
- 操作演示：
- 在V1.1.0-dev分支中新增重复、错误等共5个提交 推送至远程仓库
- 选择提交开启交互式变基
- 对于异常提交如commit信息有误进行修改
- 对于错误提交进行删除
- 对于重复提交进行合并
- 对于排序提交进行排序
- 保存并进行强制推送到远程仓库，如果只是修改本地仓库的可以忽略这一步骤
7. commit 提交规范
当前结合禅道进行整个项目流程及可视化管理，GIT代码管理作为整个项目管理的重要组成部分，可以结合禅道的任务记录来规范开发代码的提交记录。 最终达到每一次代码开发都有禅道管理任务的对照记录，方便整个项目的可视化管理以及面对问题时的朔源排查。
commit 信息构成：<禅道类型#禅道ID> <禅道标题> commit 信息示例：任务#3198 [开发]-服务信息搜索框增加数据资源模糊搜索功能
# 暂存
$ git add .
# 提交
$ git commit -m "任务#3198 [开发]-服务信息搜索框增加数据资源模糊搜索功能"
# 推送
$ git push
# 查看
$ git log
....
任务#3198 [开发]-服务信息搜索框增加数据资源模糊搜索功能
....
