|
@@ -0,0 +1,104 @@
|
|
|
|
|
+# Git 工作流程指南
|
|
|
|
|
+
|
|
|
|
|
+本指南旨在为项目提供清晰、一致的 Git 操作规范。
|
|
|
|
|
+
|
|
|
|
|
+## 基本原则
|
|
|
|
|
+
|
|
|
|
|
+1. **功能分支 (Feature Branches)**: 所有新功能、修复或实验性工作都应在独立的分支上进行,而不是直接在 `main` 分支上修改。
|
|
|
|
|
+2. **原子提交 (Atomic Commits)**: 每次提交应只解决一个问题或实现一个明确的小功能。提交信息应清晰描述变更内容。
|
|
|
|
|
+3. **保持 `main` 分支稳定**: `main` 分支应始终处于可部署状态。
|
|
|
|
|
+
|
|
|
|
|
+## 标准工作流程
|
|
|
|
|
+
|
|
|
|
|
+### 1. 开始新任务
|
|
|
|
|
+
|
|
|
|
|
+```bash
|
|
|
|
|
+# 确保在 main 分支并获取最新代码
|
|
|
|
|
+git checkout main
|
|
|
|
|
+git pull origin main
|
|
|
|
|
+
|
|
|
|
|
+# 创建并切换到新分支
|
|
|
|
|
+# 命名规范: feat/功能名, fix/问题描述, chore/杂项
|
|
|
|
|
+git checkout -b feat/new-feature-name
|
|
|
|
|
+```
|
|
|
|
|
+
|
|
|
|
|
+### 2. 开发与提交
|
|
|
|
|
+
|
|
|
|
|
+```bash
|
|
|
|
|
+# 进行你的修改...
|
|
|
|
|
+
|
|
|
|
|
+# 查看更改状态
|
|
|
|
|
+git status
|
|
|
|
|
+
|
|
|
|
|
+# 将更改添加到暂存区 (可以多次添加)
|
|
|
|
|
+git add <file1> <file2>
|
|
|
|
|
+
|
|
|
|
|
+# 提交更改
|
|
|
|
|
+git commit -m "feat: 添加了新功能的具体描述"
|
|
|
|
|
+```
|
|
|
|
|
+
|
|
|
|
|
+### 3. 同步与推送
|
|
|
|
|
+
|
|
|
|
|
+```bash
|
|
|
|
|
+# 在推送前,先将 main 分支的最新更改合并到你的功能分支(可选但推荐)
|
|
|
|
|
+git checkout main
|
|
|
|
|
+git pull origin main
|
|
|
|
|
+git checkout <your-feature-branch>
|
|
|
|
|
+git merge main
|
|
|
|
|
+
|
|
|
|
|
+# 或者使用 rebase (更干净的提交历史)
|
|
|
|
|
+git checkout <your-feature-branch>
|
|
|
|
|
+git rebase main
|
|
|
|
|
+
|
|
|
|
|
+# 解决可能出现的冲突后,推送你的分支到远程仓库
|
|
|
|
|
+git push origin <your-feature-branch>
|
|
|
|
|
+```
|
|
|
|
|
+
|
|
|
|
|
+### 4. 创建合并请求 (Pull Request)
|
|
|
|
|
+
|
|
|
|
|
+在 GitHub/GitLab 等平台上,从你的功能分支向 `main` 分支创建一个合并请求 (PR/MR)。在 PR 中详细描述你的更改、目的和任何需要注意的事项。
|
|
|
|
|
+
|
|
|
|
|
+### 5. 合并与清理
|
|
|
|
|
+
|
|
|
|
|
+- 在 PR 获得批准并成功通过 CI 检查后,将其合并到 `main` 分支。
|
|
|
|
|
+- 合并后,删除已合并的远程和本地功能分支。
|
|
|
|
|
+
|
|
|
|
|
+```bash
|
|
|
|
|
+# 删除远程分支
|
|
|
|
|
+git push origin --delete <your-feature-branch>
|
|
|
|
|
+
|
|
|
|
|
+# 删除本地分支
|
|
|
|
|
+git branch -d <your-feature-branch>
|
|
|
|
|
+```
|
|
|
|
|
+
|
|
|
|
|
+## 提交信息规范
|
|
|
|
|
+
|
|
|
|
|
+我们采用 [Conventional Commits](https://www.conventionalcommits.org/) 规范:
|
|
|
|
|
+
|
|
|
|
|
+```
|
|
|
|
|
+<type>[optional scope]: <description>
|
|
|
|
|
+
|
|
|
|
|
+[optional body]
|
|
|
|
|
+
|
|
|
|
|
+[optional footer(s)]
|
|
|
|
|
+```
|
|
|
|
|
+
|
|
|
|
|
+**常用 type:**
|
|
|
|
|
+- `feat`: 新增功能
|
|
|
|
|
+- `fix`: 修复 bug
|
|
|
|
|
+- `docs`: 文档变更
|
|
|
|
|
+- `style`: 代码格式调整(不影响代码逻辑)
|
|
|
|
|
+- `refactor`: 代码重构
|
|
|
|
|
+- `test`: 添加或修改测试
|
|
|
|
|
+- `chore`: 构建过程或辅助工具的变动
|
|
|
|
|
+
|
|
|
|
|
+**示例:**
|
|
|
|
|
+- `feat(auth): add login with Google`
|
|
|
|
|
+- `fix(api): resolve null pointer exception in user service`
|
|
|
|
|
+- `docs(readme): update installation instructions`
|
|
|
|
|
+
|
|
|
|
|
+## 当前状态处理
|
|
|
|
|
+
|
|
|
|
|
+根据 `git status` 的输出,当前有未暂存的更改。建议:
|
|
|
|
|
+1. 如果这些更改是相关的,请使用 `git add` 将它们暂存,然后 `git commit` 提交。
|
|
|
|
|
+2. 如果这些更改是不相关的或临时的,请考虑使用 `git stash` 将它们暂存起来,以便在干净的工作区开始新任务。
|