Git是现在最流行的版本控制工具几乎所有的程序员都在用但是很多人只是会用基本的addcommitpushpull对Git的工作流分支管理团队协作等等了解不多导致代码管理混乱经常出现冲突覆盖问题影响开发效率。

其实Git的强大之处不仅在于版本控制更在于它灵活的工作流和分支管理能很好地支持团队协作我用Git很多年了从单人开发到团队协作用过各种工作流踩了很多坑也总结了很多经验今天就来分享一下Git工作流的最佳实践。

一、Git基础概念

先简单回顾一下Git的一些基础概念方便理解后面的内容。

1. 工作区、暂存区、版本库

Git有三个区域：工作区就是你写代码的目录；暂存区就是git add之后代码存放的地方；版本库就是git commit之后代码提交到的地方也就是Git仓库。

这个设计很重要能让你灵活地控制哪些修改要提交哪些不提交。

2. 分支

分支是Git最强大的功能之一每个分支都是一条独立的开发线能在不影响其他分支的情况下开发新功能修复bug等等Git的分支很轻量创建和切换都很快所以鼓励多用分支。

3. 合并

合并就是把一个分支的修改合并到另一个分支Git有两种合并方式：普通合并和变基（rebase）普通合并会生成一个合并提交保留完整的历史；变基会把提交重新应用到目标分支历史更线性更干净但是会改变提交历史要小心使用。

二、单人开发工作流

先说说单人开发的工作流虽然只有一个人但是好的工作流也能让开发更有序更高效。

1. 主分支 + 功能分支

单人开发也建议用主分支加功能分支的模式不要直接在master上开发。

  • master主分支保持稳定可发布的状态。
  • 开发新功能的时候从master创建一个功能分支比如feature/login在这个分支上开发。
  • 开发完测试没问题再合并回master。

这样master一直保持稳定不会因为开发到一半的代码而不可用而且每个功能都有独立的分支方便管理和回滚。

2. 提交要小要频繁

提交不要太大太久要小步提交频繁提交比如完成了一个小功能修复了一个小bug就提交一次这样历史更清晰出了问题也方便定位和回滚。

不要攒了一大堆修改才提交那样提交信息不好写出了问题也不好定位。

3. 提交信息要清晰

提交信息很重要要清晰明了说明这次提交做了什么不要写"更新""修改""fix"这种模糊的信息。

好的提交信息应该是动词开头简洁说明做了什么比如"添加用户登录功能""修复首页加载慢的问题""优化数据库查询性能"等等这样看历史的时候一眼就知道每次提交做了什么。

4. 定期推送到远程

不要只在本地提交要定期push到远程仓库比如GitHubGitLab等等这样即使本地电脑坏了代码也不会丢而且也方便在其他电脑上继续开发。

建议每天下班前push一次或者完成了一个阶段就push一次。

三、团队协作工作流

团队协作的工作流比单人开发复杂一些需要考虑多人同时开发代码冲突代码评审版本发布等等问题。

常用的团队工作流有几种：Git FlowGitHub FlowGitLab Flow等等各有特点下面分别介绍。

1. Git Flow

Git Flow是比较经典的工作流由Vincent Driessen提出适合有明确版本发布周期的项目。

Git Flow有五种分支：

  • master主分支存放正式发布的版本。
  • develop开发分支存放最新的开发代码。
  • feature功能分支从develop创建开发新功能完成后合并回develop。
  • release发布分支从develop创建准备发布新版本做发布前的测试和bug修复完成后合并到master和develop。
  • hotfix热修复分支从master创建修复线上的紧急bug完成后合并到master和develop。

Git Flow的优点是规范清晰适合大型团队和有明确发布周期的项目缺点是比较复杂分支多对于快速迭代的项目可能有点繁琐。

2. GitHub Flow

GitHub Flow是GitHub推荐的工作流比较简单适合持续部署的项目。

GitHub Flow只有一个长期分支：master其他都是短期的功能分支。

流程：

  1. 从master创建一个功能分支。
  2. 在功能分支上开发提交。
  3. 开发完发起Pull Request（PR）请求合并到master。
  4. 团队成员代码评审讨论修改。
  5. 评审通过合并到master。
  6. 部署到线上。

GitHub Flow的优点是简单灵活适合快速迭代持续部署的项目缺点是没有明确的版本概念对于需要维护多个版本的项目不太适合。

3. GitLab Flow

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

GitLab Flow也是以master为主但是会根据环境创建不同的分支比如pre-productionproduction等等代码从master合并到pre-production测试没问题再合并到production发布。

GitLab Flow的优点是灵活能适应不同的发布流程缺点是需要根据项目情况调整没有统一的标准。

四、团队协作最佳实践

不管用哪种工作流有一些最佳实践是通用的能让团队协作更顺畅更高效。

1. 分支命名要规范

分支命名要规范让人一眼就知道这个分支是做什么的常用的命名方式：

  • feature/xxx功能分支比如feature/user-login。
  • bugfix/xxxbug修复分支比如bugfix/login-error。
  • hotfix/xxx紧急修复分支比如hotfix/payment-bug。
  • release/xxx发布分支比如release/v1.2.0。

这样分支管理很清晰不会混乱。

2. 代码评审很重要

代码评审（Code Review）是团队协作中非常重要的一环能提高代码质量发现bug分享知识统一风格。

每个功能分支合并之前都应该发起PR至少有一个其他团队成员评审通过才能合并评审的时候要认真看代码提出问题和建议不要走过场。

3. 解决冲突要小心

多人协作难免会有代码冲突解决冲突的时候要小心不要随便删掉别人的代码要理解双方的修改然后合理地合并解决完冲突要测试一下确保代码能正常运行再提交。

如果冲突比较复杂不确定怎么解决可以找相关的同事一起讨论解决不要自己随便处理。

4. 不要提交无关的修改

一个提交应该只包含相关的修改不要把不相关的修改混在一个提交里比如你在开发登录功能顺便改了首页的样式这两个修改应该分开提交这样历史更清晰出了问题也方便定位和回滚。

5. 不要提交敏感信息

绝对不要把密码密钥数据库配置等等敏感信息提交到Git仓库特别是公开的仓库那样很危险会被人利用攻击你的系统。

敏感信息应该放在环境变量或者配置文件里配置文件加入.gitignore不提交到仓库只提交配置文件的示例比如config.example.php让其他人自己复制修改。

6. .gitignore要配置好

.gitignore文件很重要要把不需要提交的文件都加进去比如依赖目录（vendornode_modules）日志文件临时文件编译产物配置文件IDE配置等等这样仓库会很干净不会有无关的文件。

五、常用Git技巧

分享一些常用的Git技巧能让你用Git更高效。

1. git stash

git stash能把当前的修改暂存起来等以后再恢复比如你正在开发一个功能突然有一个紧急bug要修复这时候可以git stash把当前的修改暂存然后切换分支修复bug修复完再git stash pop恢复之前的修改继续开发。

2. git rebase -i

git rebase -i交互式变基能让你整理提交历史比如合并多个提交修改提交信息删除提交等等让历史更干净更清晰但是要注意不要对已经push到远程的提交做rebase那样会改变历史影响其他人。

3. git cherry-pick

git cherry-pick能把某一个提交应用到当前分支比如你在一个分支上修复了一个bug想把这个修复也应用到另一个分支就可以用git cherry-pick把那个提交挑过来很方便。

4. git bisect

git bisect二分查找能帮你快速定位是哪个提交引入了bug比如你发现现在的代码有bug但是之前的版本没有就可以用git bisect二分查找快速定位出问题的提交很高效。

5. git blame

git blame能查看某一行代码是谁在什么时候修改的为什么修改出了问题能快速找到负责人了解背景很方便。

六、写在最后

Git工作流最佳实践：从单人开发到团队协作。

Git是每个程序员都必须掌握的工具但是很多人只是会用基本的命令对工作流和最佳实践了解不多导致代码管理混乱影响开发效率。

这篇文章分享了Git的基础概念单人开发工作流团队协作工作流（Git FlowGitHub FlowGitLab Flow）团队协作最佳实践以及一些常用的Git技巧希望能帮大家更好地使用Git提高开发效率。

好的Git工作流不是一成不变的要根据团队和项目的情况选择合适的工作流并且不断优化调整找到最适合自己的方式。

最后用一句话结尾：

"Git不只是一个版本控制工具更是一种开发思维和协作方式掌握了好的工作流能让开发更高效更愉悦。"

祝大家都能用好Git开发顺利！