Git已经成为了程序员必备的版本控制工具。无论是个人项目还是团队协作Git都能帮我们高效地管理代码版本。

但是很多人对Git的使用只停留在add、commit、push、pull这几个基本命令。对于Git工作流分支管理团队协作等高级用法却知之甚少。

如果团队没有一个好的Git工作流很容易出现代码冲突分支混乱版本管理困难等问题影响团队的开发效率。

我自己用Git已经几年了经历过不同的团队和不同的Git工作流。今天就来分享一下Git工作流的最佳实践帮大家建立高效的团队协作流程。

为什么需要Git工作流

Git本身只是一个版本控制工具它不规定你应该怎么使用，它。但是在团队协作中如果每个人都按照自己的习惯来使用Git就会导致混乱。

比如：

  • 有人直接在master分支上开发
  • 有人创建很多分支却不删除
  • 有人commit信息写得很随意
  • 有人不做code review直接合并
  • 有人把不相关的改动放在一个commit里

这些问题都会影响团队的开发效率和代码质量。

所以团队需要一个统一的Git工作流来规范每个人的使用方式让团队协作更高效更有序。

一个好的Git工作流应该，能：

  • 让开发并行进行互不干扰
  • 让代码质量得到保障
  • 让版本管理清晰有序
  • 让发布流程稳定可靠
  • 让问题定位和回滚方便快捷

常见的Git工作流

目前比较流行的Git工作流有以下几种：

1. Git Flow

Git Flow是最经典的Git工作流由Vincent Driessen在2010年提出。

它定义了5种分支：

  • master：主分支存储正式发布的版本
  • develop：开发分支存储最新的开发版本
  • feature：功能分支从develop分出开发新功能完成后合并回develop
  • release：发布分支从develop分出准备发布完成后合并到master和develop
  • hotfix：热修复分支从master分出修复线上bug完成后合并到master和develop

Git Flow的优点是清晰规范适合版本发布周期比较固定的项目。缺点是比较复杂分支多流程长不适合快速迭代的项目。

2. GitHub Flow

GitHub Flow是GitHub使用的工作流比较简单轻量。

它只有一个长期分支：

  • master：主分支始终保持可部署状态

开发流程：

  1. 从master创建新分支
  2. 在新分支上开发提交
  3. 提交Pull Request进行code review
  4. code review通过后合并到master
  5. 部署到线上

GitHub Flow的优点是简单轻量适合快速迭代持续部署的项目。缺点是没有明确的版本概念不适合版本发布周期长的项目。

3. GitLab Flow

GitLab Flow是GitLab推荐的工作流结合了Git Flow和GitHub Flow的优点。

它在GitHub Flow的基础上增加了环境分支和版本分支：

  • master：主分支最新的代码
  • pre-production：预发布环境分支
  • production：生产环境分支
  • 版本分支：比如1-0-stable，1-1-stable维护旧版本

GitLab Flow的优点是兼顾了简单和版本管理适合有多个环境和版本的项目。

4. Trunk-Based Development

Trunk-Based Development主干开发是一种比较极端的工作流。

它的核心思想是所有人都在主干（trunk/master），上开发频繁提交通过Feature Flag（功能开关），来控制未完成功能的可见性。

Trunk-Based Development的优点是合并冲突少集成快适合持续集成持续部署。缺点是对团队要求高需要完善的测试和Feature Flag机制。

推荐的Git工作流

对于大多数团队我推荐使用简化版的Git Flow或者GitHub Flow根据项目的特点来选择。

如果项目版本发布周期比较固定比如每两周发布一个版本推荐使用简化版的Git Flow。

如果项目需要快速迭代持续部署推荐使用GitHub Flow。

下面我详细介绍一下我推荐的简化版Git Flow工作流。

分支定义

  • master：主分支存储正式发布的版本只接受release和hotfix的合并
  • develop：开发分支存储最新的开发版本日常开发都基于这个分支
  • feature/xxx：功能分支从develop分出开发新功能完成后合并回develop
  • release/xxx：发布分支从develop分出准备发布完成后合并到master和develop
  • hotfix/xxx：热修复分支从master分出修复线上bug完成后合并到master和develop

开发流程

  1. 创建功能分支

从develop分支创建功能分支命名规范：feature/功能名称，比如，feature/user-login、feature/order-system。

``bash git checkout develop git pull git checkout -b feature/user-login ``

  1. 开发提交

在功能分支上开发频繁提交每个commit应该是一个独立的小改动commit信息要清晰规范。

``bash git add . git commit -m "feat: add user login form" ``

  1. 推送分支

把功能分支推送到远程仓库。

``bash git push origin feature/user-login ``

  1. 提交合并请求

功能开发完成后提交Merge Request（或Pull Request），请求合并到develop分支进行code review。

  1. Code Review

团队成员进行code review提出修改意见。开发者根据意见修改代码再次提交。

  1. 合并到develop

code review通过后合并功能分支到develop分支删除功能分支。

发布流程

  1. 创建发布分支

当develop分支的功能积累到一定程度准备发布时从develop分支创建发布分支命名规范：release/版本号，比如，release/1.0.0。

``bash git checkout develop git pull git checkout -b release/1.0.0 ``

  1. 测试和修复bug

在发布分支上进行测试修复发现的bug。只修复bug不添加新功能。

  1. 合并到master和develop

测试通过后合并发布分支到master和develop分支在master分支上打标签。

```bash git checkout master git merge release/1.0.0 git tag -a v1.0.0 -m "release version 1.0.0" git push origin master --tags

git checkout develop git merge release/1.0.0 git push origin develop ```

  1. 删除发布分支

合并完成后删除发布分支。

热修复流程

  1. 创建热修复分支

当线上出现紧急bug需要立即修复时从master分支创建热修复分支命名规范：hotfix/描述，比如，hotfix/fix-login-error。

``bash git checkout master git pull git checkout -b hotfix/fix-login-error ``

  1. 修复bug

在热修复分支上修复bug测试通过。

  1. 合并到master和develop

修复完成后合并热修复分支到master和develop分支在master分支上打标签。

```bash git checkout master git merge hotfix/fix-login-error git tag -a v1.0.1 -m "hotfix: fix login error" git push origin master --tags

git checkout develop git merge hotfix/fix-login-error git push origin develop ```

  1. 删除热修复分支

合并完成后删除热修复分支。

Commit信息规范

好的commit信息能让代码历史更清晰方便问题定位和版本回滚。

推荐使用Conventional Commits规范：

<type>(<scope>): <subject>

<body>

<footer>

Type

type表示commit的类型常见的，有：

  • feat：新功能
  • fix：修复bug
  • docs：文档修改
  • style：代码格式修改不影响代码逻辑
  • refactor：重构既不是新功能也不是修复bug
  • perf：性能优化
  • test：测试相关
  • chore：构建过程或辅助工具的变动

Scope

scope表示commit影响的范围比如模块名组件名等可选。

Subject

subject表示commit的简短描述不超过50个字符。

Body

body表示commit的详细描述可选可以分多行。

footer表示一些备注比如关闭的issue编号不兼容的改动等可选。

示例

feat(user): add user login feature

- add login form
- add login API integration
- add form validation

Closes #123
fix(order): fix order calculation error

The order total was calculated incorrectly when there were multiple items with different tax rates.

Closes #456

Code Review最佳实践

Code Review是保障代码质量的重要环节。

Code Review的好处

  • 发现代码中的bug和问题
  • 提升代码质量和可维护性
  • 统一代码风格和规范
  • 促进团队成员之间的知识分享
  • 让团队成员熟悉彼此的代码

Code Review的要点

  1. 及时review

收到Merge Request后应该及时进行review不要让开发者等太久。

  1. 关注重点

review时应该重点关注： - 逻辑是否正确 - 是否有安全漏洞 - 性能是否有问题 - 代码是否可维护 - 是否符合团队规范

不要过度关注代码风格的细节这些应该由工具来检查。

  1. 提出建设性意见

review时应该提出建设性的意见而不是单纯地批评。说明为什么需要改怎么改比较，好。

  1. 尊重开发者

review时应该尊重开发者对事不对人。不要因为代码问题而攻击个人。

  1. 小步提交

开发者应该小步提交每个Merge Request不要太大否则review起来很困难。建议每个Merge Request的代码改动不超过400行。

Git常用技巧

1. 别名配置

可以给常用的Git命令配置别名提高效率。

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all"

这样就可以用，git co，代替，git checkout，用，git lg，查看漂亮的提交历史。

2. 储藏改动

如果正在开发中途需要切换分支但是又不想提交未完成的代码可以用，git stash，储藏改动。

# 储藏改动
git stash

# 查看储藏列表
git stash list

# 恢复最近的储藏
git stash pop

# 恢复指定的储藏
git stash apply stash@{0}

# 删除指定的储藏
git stash drop stash@{0}

3. 撤销提交

如果提交错了可以用，git reset，或，git revert，撤销。

# 撤销最近的提交，保留改动
git reset --soft HEAD~1

# 撤销最近的提交，丢弃改动
git reset --hard HEAD~1

# 用新的提交撤销指定的提交（适合已经推送到远程的提交）
git revert <commit-hash>

4. 交互式rebase

git rebase -i，可以交互式地整理提交历史比如合并多个提交修改提交信息删除提交，等。

# 整理最近3个提交
git rebase -i HEAD~3

然后在编辑器中选择要对每个提交做的操作：

  • pick：保留提交
  • reword：保留提交但修改提交信息
  • edit：保留提交但暂停修改
  • squash：合并到前一个提交
  • fixup：合并到前一个提交丢弃提交信息
  • drop：删除提交

5. 查看历史

# 查看提交历史
git log

# 查看简洁的提交历史
git log --oneline

# 查看图形化的提交历史
git log --oneline --graph --all

# 查看指定文件的修改历史
git log -p filename

# 查看指定行的修改历史
git blame filename

常见问题与解决方法

1. 合并冲突

当两个分支修改了同一个文件的同一行合并时就会出现冲突。

解决方法：

  1. 查看冲突文件
  2. 手动编辑文件解决冲突
  3. 添加解决后的文件
  4. 继续合并或rebase
# 查看冲突文件
git status

# 手动编辑文件解决冲突后
git add filename

# 如果是merge
git commit

# 如果是rebase
git rebase --continue

2. 误删分支

如果不小心删除了分支可以用reflog找回。

# 查看操作历史
git reflog

# 找到删除分支前的commit hash
# 创建新分支
git checkout -b branch-name <commit-hash>

3. 大文件误提交

如果不小心提交了大文件可以用，git filter-branch，或BFG Repo-Cleaner清理。

# 使用BFG清理大文件
bfg --strip-blobs-bigger-than 10M repo.git

4. 提交信息写错

如果最近的提交信息写错了可以修改。

# 修改最近的提交信息
git commit --amend

如果已经推送到远程需要强制推送。

git push --force

写在最后

Git工作流是团队协作的基础。一个好的Git工作流能让团队协作更高效代码质量更有保障。

但是Git工作流不是一成不变的也没有最好的只有最适合的。团队应该根据自己的项目特点团队规模发布周期等选择和调整适合自己的工作流。

另外工具只是辅助更重要的是团队成员的意识和习惯。只有每个人都遵守规范认真对待code review，Git工作流才能真正发挥作用。

希望这篇文章能帮到大家。如果你有什么Git工作流的经验和技巧欢迎在评论区留言和我一起讨论。

最后记住：好的工具，+ 好的流程，+ 好的团队，= 高效的协作。 祝大家都能建立高效的Git工作流让团队协作更顺畅。