项目开发手册-开发工具使用之Git
目录
1 Git 在企业开发中的基本使用
2 分支的建立管理
3 开发标准流程
常见命令使用
在本地创建并推送develop分支到远程
创建feature分支(基于develop)
合并feature分支到develop
删除本地和远程的 feature 分支
合并feature分支到develop 完整操作流程示例
Conventional Commits 规范
基本格式
具体格式说明
在企业开发中，每一个功能或修复对应一个独立分支，开发完成后通过代码审查合并进主分支，确保多人协作下的代码质量和稳定性。
1 Git 在企业开发中的基本使用
版本控制：跟踪代码的每次改动，防止丢失，方便回滚
多人协作：不同的人可以并行开发，最后合并到一起
代码审查：通常提交 (Push) 到远程仓库后，需要别人审查你的改动，审查通过才能合并
发布版本管理：通过Tag或者Release记录每个上线的版本
2 分支的建立管理
通常遵循一套比较规范的分支策略，比如 Git Flow 或者更轻量的 Trunk Based Development
常见的分支类型有
- Master 分支：稳定、随时可以发布的代码，生产环境运行的就是master分支上的代码。不可直接基于该分支提交。只有经过严格审核测试后的Develop或Hotfix分支可以合并到master
- Develop 开发分支：日常开发的集成分支，测试环境通常跑的是这里的代码，从Master创建得来。功能开发的基础分支。
- feature 功能分支：从Develop分支创建得来，针对一个具体功能/需求开的分支，比如feature/login，开发测试完成后会合并到Develop分支。
- Release：预发布分支，当Develop上积累了一定的功能特性后，从Develop分支创建一个Release分支，做一些发布前的准备工作，不可开发功能。最终合并到Master分支和Develop分支。
- Hotfix：热修复分支，当Master出现紧急BUG时，基于Master临时创建的分支，修复完成后合并到Develop和Master分支。
建立分支步骤一般是这样的：
# 切到develop分支，更新到最新git checkout developgit pull# 基于develop创建一个新分支git checkout -b feature/login-page3 开发标准流程
（1）开发前
git pull拉取最新代码，保持本地和远程同步git checkout -b开新分支 (如果还没开的话)
（2）开发中
- 写一部分逻辑，就
git add+git commit一次 - 提交信息规范(非常重要，团队通常需要统一风格，可参考 Conventional Commits规范，比如)：
-
- feat：新增功能
- fix：修复问题
- docs：修改文档
- style：格式（空格，分号等）
- refactor：代码重构
- chore：其他杂项修改
- test：添加测试
例子：
git add .
git commit -m "feat: 完成登录页面接口对接"（3）开发完成后
- 先切回develop分支，更新最新
- 回到自己的分支，git rebase develop 同步最新的变动，解决冲突
- 然后
git push origin feature/login-page推到远程仓库 - 提交 Merge Request（MR）/Pull Request (PR) ，等待别人审查
（部分公司要求必须经过代码评审，小团队可以直接自己合并。）
（4）最后合并上线
- 合并到 develop 后，经过测试人员测试没问题
- 准备发布时，从develop拉release分支，最后合并回main
- 打一个Tag，比如v1.0，用于回溯或追踪版本
常见命令使用
在本地创建并推送develop分支到远程
1 切换到 main 分支并确保代码是最新的：
git checkout main
git pull origin main2 创建 develop 分支：
git checkout -b develop3 推送 develop 分支到远程仓库：
-u 参数会将本地分支与远程分支关联起来，之后直接用 git push 或 git pull 就可以同步。
git push -u origin develop这会将 develop 分支推送到远程仓库，并关联本地分支和远程分支。
创建feature分支(基于develop)
feature分支用于开发新功能
1 切换到 develop 分支：
先确保你在 develop 分支上：
git checkout develop
git pull origin develop2 创建 feature 分支：
创建一个功能分支，假设命名为 feature/login：
git checkout -b feature/login3 将 feature 分支推送到远程：
git push -u origin feature/login合并feature分支到develop
在合并之前，切换到 develop 分支并确保它是最新的：
git checkout develop
git pull origin develop（1）直接合并
切换到 develop 分支后，运行以下命令将 feature 分支合并到当前分支（develop）：
git merge feature/login-page说明：
feature/login-page是你的功能分支名称。- 如果合并过程中没有冲突，Git 会直接合并。
- 如果有冲突，Git 会提示你解决冲突。
（2）解决冲突（如果有）
如果合并时遇到冲突：
- Git 会提示哪些文件有冲突，打开这些文件并手动解决冲突。
- 冲突解决后，标记文件为已解决
git add <file-name>- 完成后提交合并：
git commit（3）推送合并后的 develop 分支到远程
将合并后的 develop 分支推送到远程仓库：
git push origin develop删除本地和远程的 feature 分支
（1）删除本地 feature 分支
如果不再需要 feature 分支，可以删除本地分支：
git branch -d feature/login-page注意：如果 feature 分支未合并到其他分支，使用上述命令会报错，提示未合并的分支将丢失数据。如果你确定要删除，可以强制删除：
git branch -D feature/login-page（2）删除远程 feature 分支
如果远程仓库中也不再需要该分支，可以删除远程分支：
git push origin --delete feature/login-page合并feature分支到develop 完整操作流程示例
feature 分支名称是 feature/login，以下是从合并到删除分支的完整命令：
# 1. 确保 develop 是最新的
git checkout develop
git pull origin develop# 2. 合并 feature/login 到 develop
git merge feature/login# 3. 推送合并后的 develop 到远程
git push origin develop# 4. 删除本地 feature/login 分支
git branch -d feature/login# 5. 删除远程 feature/login 分支（可选）
git push origin --delete feature/loginConventional Commits 规范
Conventional Commits 是一种提交消息的书写规范，约定了提交信息的结构和格式，主要由以下部分组成：
基本格式
<type>[optional scope]: <description>[optional body][optional footer(s)]<type>：提交的类型，必填，用来说明这次提交的目的。[optional scope]：提交的影响范围，可选，指明更改所影响的模块或功能。<description>：简短的提交描述，必填，说明这次提交做了什么。[optional body]：可选，描述更详细的内容，比如改动的原因、背景、解决方案等。[optional footer(s)]：可选，通常用于放置一些元信息，例如关联的任务或 Breaking Changes（不兼容变更）。
具体格式说明
1. Commit 类型 (<type>)
<type> 是提交的类别，以下是 Conventional Commits 中常用的类型：
| 类型 | 含义 |
|
| 新功能（feature） |
|
| 修复 bug（bug fix） |
|
| 仅文档更改 |
|
| 不影响代码含义的更改（空格、格式化、缺少分号等） |
|
| 代码重构（既不是新增功能，也不是修复 bug） |
|
| 提高性能的代码更改 |
|
| 添加或修改测试代码 |
|
| 构建系统或依赖项的更改（如更新 npm 包、修复构建脚本等） |
|
| CI 配置文件和脚本的更改（如修改 GitHub Actions、Jenkins 配置等） |
|
| 杂务（其他不修改 src 或测试文件的更改，如更新构建工具配置等） |
|
| 回滚之前的提交 |
2. 提交范围 ([optional scope])
[scope] 是可选项，用来标明此次更改的影响范围，比如模块或功能名称。
例如：
- 如果修改了用户认证模块，可以写为： plaintext复制
feat(auth): 添加用户登录功能- 如果修改了购物车功能： plaintext复制
fix(cart): 修复商品无法正确结算的问题3. 提交描述 (<description>)
<description> 是对提交内容的简短描述，必须是简洁明了的一句话，且：
- 使用小写字母开头（遵循英语句式）。
- 不以句号（
.）结尾。 - 保持 50 字符以内，过长会影响阅读。
4. 提交正文 ([optional body])
[body] 是可选的，用于详细说明此次更改的背景、原因、动机或实现方式。正文每行不超过 72 个字符，方便阅读。
例如：
feat(auth): 添加用户登录功能实现了用户登录功能，支持用户名和密码的校验。
并对登录失败的情况进行了错误提示优化。5. 提交脚注 ([optional footer(s)])
脚注 用于指定与提交相关的元信息，主要包括以下内容：
（1）Breaking Changes（不兼容变更）
当提交中有不兼容的重大变化时，必须在脚注中注明。格式：
BREAKING CHANGE: <详细描述>示例：
feat(router): 移除 Router.push 方法BREAKING CHANGE: Router.push 方法已移除，请使用 Router.navigate 替代。（2）关联的任务或问题（Issue）
通常用于关联 JIRA、GitHub Issue 或 GitLab Issue，格式：
<关键词> #<issue编号>常用关键词：
Closes：本次提交解决了该 Issue。Fixes：用于修复问题。Refs或Related to：仅提及，但不关闭 Issue。
示例：
fix(cart): 修复商品无法正确结算的问题修复了由于浮点数精度问题导致的结算错误。Closes #123