写在前面
在日常开发中，规范的Git工作流能大大提高团队协作效率，减少不必要的冲突和问题。这里整理一下常用的Git工作流和最佳实践，希望对大家有帮助。
几种常见的Git工作流
Git Flow - 适合大项目
这个比较复杂，但是规范。如果你们项目比较大，发版周期固定，可以用这个。
简单说就是这几个分支：
master - 线上代码，别乱动develop - 开发主分支，大家的代码最终都合到这里feature/xxx - 开发新功能用的release/xxx - 准备发版用的hotfix/xxx - 线上出bug紧急修复用的
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| # 装个git flow工具，省事
git flow init
# 开发新功能
git flow feature start login-page
# 写代码...
git flow feature finish login-page
# 准备发版
git flow release start v1.0.0
# 测试、修bug...
git flow release finish v1.0.0
# 线上出bug了，紧急修复
git flow hotfix start fix-login-bug
# 修bug...
git flow hotfix finish fix-login-bug
|
GitHub Flow - 简单粗暴
这个简单多了，就一个主分支，适合小团队或者经常发版的项目。
规则很简单：
master分支随时可以发版- 开发新功能就从master拉个分支
- 写完了发PR，让别人review一下
- 合并后直接发版
1
2
3
4
5
6
7
8
9
10
11
12
| # 拉个分支开发
git checkout -b feature/add-login
# 写代码，提交
git add .
git commit -m "加了个登录功能"
# 推到远程
git push origin feature/add-login
# 然后去GitHub/GitLab创建PR
# review通过就合并，然后发版
|
GitLab Flow - 中庸之道
这个介于上面两种之间，有环境分支的概念。
1
2
3
4
5
6
7
8
| # 一般是这样的流程
master -> staging -> production
# 开发功能
git checkout -b feature/new-stuff
# 写完合并到master
# master自动部署到测试环境
# 测试OK了再合并到production分支发版
|
commit信息别瞎写
规范的commit信息对于项目维护和问题追踪非常重要，能让团队协作更加高效。
简单的格式
常用的类型：
feat - 新功能fix - 修bugdocs - 改文档style - 改格式（不影响功能的）refactor - 重构代码test - 测试相关
举几个例子
1
2
3
4
5
6
7
8
9
| # 好的commit信息
git commit -m "feat: 添加用户登录功能"
git commit -m "fix: 修复登录页面验证码不显示的问题"
git commit -m "docs: 更新README安装说明"
# 别这样写
git commit -m "fix"
git commit -m "更新"
git commit -m "修改了一些东西"
|
分支名别乱起
分支名起得有意义一点，一看就知道是干啥的。
1
2
3
4
5
6
7
8
9
10
| # 推荐这样
feature/user-login # 开发用户登录功能
fix/login-bug # 修复登录bug
hotfix/urgent-security # 紧急安全修复
# 别这样
test
my-branch
临时分支
aaaa
|
Code Review别走过场
Code Review是保证代码质量的重要环节，认真的review能发现不少潜在问题，提高代码质量。
简单的检查项
- 代码能跑吗？
- 逻辑有问题吗？
- 有没有明显的bug？
- 代码风格统一吗？
- 有没有写注释？
几个有用的命令
1
2
3
4
5
6
7
8
| # 看看改了哪些文件
git diff --stat master
# 看具体改了啥
git diff master
# 看提交记录
git log --oneline master..HEAD
|
解决冲突别慌
冲突是常有的事，别一看到冲突就慌。
怎么避免冲突
- 经常pull最新代码
- 别一次改太多文件
- 改同一个文件前先沟通一下
冲突了怎么办
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| # 先拉最新代码
git pull origin master
# 如果有冲突，打开文件手动解决
# 找到 <<<<<<< ======= >>>>>>> 这些标记
# 删掉不要的代码，保留要的
# 解决完了继续
git add .
git commit -m "解决冲突"
# 或者用rebase（推荐）
git rebase origin/master
# 解决冲突后
git add .
git rebase --continue
|
一些有用的工具
Git Hooks - 提交前检查
可以设置一些钩子，提交前自动检查代码格式、跑测试什么的。
1
2
3
4
5
6
7
8
| # .git/hooks/pre-commit
#!/bin/sh
# 提交前跑一下测试
npm test
if [ $? -ne 0 ]; then
echo "测试挂了，先修复再提交"
exit 1
fi
|
CI/CD自动化
用GitHub Actions或者Jenkins之类的，PR的时候自动跑测试。
1
2
3
4
5
6
7
8
9
10
| # 简单的GitHub Actions
name: 测试
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- run: npm install
- run: npm test
|
一些实用技巧
Git别名 - 偷懒神器
1
2
3
4
5
6
7
8
9
10
11
| # 设置一些常用的别名
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.cm commit
git config --global alias.lg "log --oneline --graph"
# 以后就可以这样用
git co master # 等于 git checkout master
git st # 等于 git status
git cm -m "xxx" # 等于 git commit -m "xxx"
|
推荐的工具
- Git客户端: SourceTree（图形界面，新手友好）
- VS Code插件: GitLens（看代码历史很方便）
- 命令行工具: tig（命令行下的git图形界面）
总结
其实Git工作流没那么复杂，关键是团队要统一，别各搞各的。
几个要点：
- 选个适合团队的工作流，别瞎折腾
- commit信息写清楚点
- 经常pull代码，减少冲突
- code review认真点，别走过场
- 用点工具提高效率
最后，Git这东西熟能生巧，多用就会了。遇到问题别慌，Google一下基本都能解决。
参考链接
