Git 工作流程指南

本指南旨在为项目提供清晰、一致的 Git 操作规范。

基本原则

功能分支 (Feature Branches): 所有新功能、修复或实验性工作都应在独立的分支上进行，而不是直接在 main 分支上修改。
原子提交 (Atomic Commits): 每次提交应只解决一个问题或实现一个明确的小功能。提交信息应清晰描述变更内容。
保持 main 分支稳定: main 分支应始终处于可部署状态。

标准工作流程

1. 开始新任务

# 确保在 main 分支并获取最新代码
git checkout main
git pull origin main

# 创建并切换到新分支
# 命名规范: feat/功能名, fix/问题描述, chore/杂项
git checkout -b feat/new-feature-name

2. 开发与提交

# 进行你的修改...

# 查看更改状态
git status

# 将更改添加到暂存区 (可以多次添加)
git add <file1> <file2>

# 提交更改
git commit -m "feat: 添加了新功能的具体描述"

3. 同步与推送

# 在推送前，先将 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 分支。

合并后，删除已合并的远程和本地功能分支。

# 删除远程分支
git push origin --delete <your-feature-branch>

# 删除本地分支
git branch -d <your-feature-branch>

提交信息规范

我们采用 Conventional Commits 规范：

<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 的输出，当前有未暂存的更改。建议：

如果这些更改是相关的，请使用 git add 将它们暂存，然后 git commit 提交。
如果这些更改是不相关的或临时的，请考虑使用 git stash 将它们暂存起来，以便在干净的工作区开始新任务。

GIT_GUIDE.md 2.9 KB History Raw