Git分支管理实践

引言

多人协作开发如果所有人直接往master主分支提交，代码很容易混乱、出现问题无法回滚。一套清晰的分支命名和合并规则，是团队开发协作的基础。

常见分支模型

• master/main：稳定生产分支，只接受合并，不直接开发；
• develop：日常集成开发分支；
• feature/xxx：单个功能开发分支，从develop拉出；
• hotfix/xxx：线上紧急bug修复分支，从master拉出；
• release/x.x：版本发布前测试分支。

常用命令

# 新建并切换功能分支
git checkout -b feature/login

# 提交代码
git add .
git commit -m "新增登录接口"

# 推送到远程
git push origin feature/login

开发流程

1. 从develop拉取新功能分支；
2. 本地开发提交，定期同步develop最新代码；
3. 测试通过后发起合并请求(MR/PR)；
4. 代码评审通过合并到develop；
5. 上线前拉出release分支测试，最终合并master打tag。

注意事项

• 功能分支命名要语义化，带上开发人或需求编号；
• 每次提交信息写清楚改了什么；
• 不要在长期分支堆积大量提交，频繁同步主干避免冲突；
• hotfix修复完成后要同步回develop，防止下次版本再次出现bug。

总结

Git分支模型不追求复杂，适合团队规模即可。核心原则：主干保持稳定，功能独立分支，小步提交，评审合并，线上问题走hotfix单独修复。

Git 常用命令汇总

Git 是现在开发必备工具，整理一份常用命令清单，收藏备用。

1. 初始化和克隆

# 初始化新仓库
git init

# 克隆远程仓库
git clone https://github.com/user/repo.git

# 克隆指定分支
git clone -b dev https://github.com/user/repo.git

2. 查看状态

# 查看工作区状态
git status

# 查看提交历史
git log

# 查看简洁历史
git log --oneline --graph

# 查看文件改动
git diff

3. 添加和提交

# 添加所有文件到暂存区
git add .

# 添加指定文件
git add file.php

# 提交到本地仓库
git commit -m "修复bug"

# 提交并跳过验证
git commit --no-verify -m "修复bug"

4. 分支操作

# 查看本地分支
git branch

# 查看所有分支（包括远程）
git branch -a

# 创建新分支
git branch dev

# 切换分支
git checkout dev

# 创建并切换分支
git checkout -b dev

# 删除分支
git branch -d dev

# 强制删除分支
git branch -D dev

5. 远程操作

# 拉取远程更新
git pull

# 推送本地提交
git push

# 推送本地新分支到远程
git push -u origin dev

# 删除远程分支
git push origin --delete dev

6. 撤销操作

# 撤销工作区修改
git checkout -- file.php

# 撤销暂存区
git reset HEAD file.php

# 回退到上一个版本
git reset --hard HEAD^

# 回退到指定版本
git reset --hard commit_id

# 撤销上次提交（保留修改）
git reset --soft HEAD^

7. 合并和变基

# 合并分支
git merge dev

# 变基
git rebase master

# 取消合并
git merge --abort

8. 标签操作

# 打标签
git tag v1.0.0

# 查看标签
git tag

# 推送标签
git push origin v1.0.0

# 推送所有标签
git push origin --tags

总结

Git 常用命令核心：

• 查看：status / log / diff
• 提交：add / commit
• 分支：branch / checkout / merge
• 远程：pull / push
• 撤销：reset / checkout

记住这些，日常 Git 操作基本够用了。

前言

Git 是每个程序员都必须掌握的工具，但很多团队用着用着就乱了：分支满天飞、提交记录看不懂、合并冲突天天有。本文介绍一套简单实用的 Git 工作流，让团队协作井井有条。

一、分支模型

推荐使用简化版的 Git Flow，核心分支只有两个：

• main / master：主分支，永远是可发布状态
• develop：开发分支，日常开发都在这上面

临时分支：

• feature/xxx：功能分支，从 develop 拉出来
• bugfix/xxx：修复分支，从 develop 拉出来
• release/xxx：发布分支，从 develop 拉出来准备上线
• hotfix/xxx：紧急修复分支，从 main 拉出来修线上 bug

二、日常开发流程

1. 拉最新代码

git checkout develop
git pull origin develop

2. 创建功能分支

git checkout -b feature/user-login

3. 开发并提交

# 写代码...

# 添加文件
git add .

# 提交（commit message 要清晰）
git commit -m "feat: 添加用户登录页面"

commit message 规范：

• feat: 新功能
• fix: 修复 bug
• docs: 文档修改
• style: 代码格式调整
• refactor: 重构
• chore: 构建流程或工具变动

4. 推送到远程

git push origin feature/user-login

5. 发起 Pull Request / Merge Request

在 Git 平台（GitHub/GitLab/Gitee）上发起 PR，把 feature 分支合并到 develop 分支。

6. 代码评审

同事 review 代码，提出修改意见，修改后再合并。

7. 合并后删除分支

git checkout develop
git pull origin develop
git branch -d feature/user-login
git push origin --delete feature/user-login

三、发布流程

1. 从 develop 拉发布分支

git checkout -b release/1.2.0

2. 修复小问题，准备发布

在发布分支上只做 bug 修复，不加新功能。

3. 合并到 main，打 tag

git checkout main
git merge release/1.2.0
git tag -a v1.2.0 -m "版本 1.2.0"
git push origin main --tags

4. 合并回 develop

git checkout develop
git merge release/1.2.0
git push origin develop

四、线上紧急修复

1. 从 main 拉 hotfix 分支

git checkout main
git pull origin main
git checkout -b hotfix/login-bug

2. 修复 bug，合并回 main 和 develop

# 修复...

git checkout main
git merge hotfix/login-bug
git tag -a v1.2.1 -m "修复登录 bug"
git push origin main --tags

# 合并回 develop
git checkout develop
git merge hotfix/login-bug
git push origin develop

五、实用技巧

1. 撤销提交

# 撤销最近一次提交，保留代码改动
git reset --soft HEAD~1

# 撤销最近一次提交，丢弃代码改动（慎用）
git reset --hard HEAD~1

2. 暂存当前工作

# 临时保存当前工作
git stash

# 恢复
git stash pop

3. 查看历史

# 简洁的图形化提交历史
git log --oneline --graph --all

4. 变基保持提交干净

# 把 feature 分支的提交变基到最新的 develop 上
git checkout feature/user-login
git rebase develop

六、常见坑

1. 不要在 main 上直接开发：所有改动都要通过 PR 合并
2. commit 不要太大：一个功能一个 commit，方便回滚
3. 不要 force push 到公共分支：会搞乱别人的代码
4. 定期同步 develop：每天至少 pull 一次最新代码

总结

Git 工作流的核心思路：

1. main 永远可发布，develop 是集成分支
2. 功能分支从 develop 拉，修完合并回 develop
3. 发布时从 develop 拉 release，合并到 main 打 tag
4. 线上 bug 从 main 拉 hotfix，修完合并回 main 和 develop

这套流程简单实用，小团队用起来刚刚好。