团队协作一些看法

[Mrwaite]

团队协作一些看法

基于 Git Flow 的开发流程

Git Flow 分支模型

• master 分支 => 正式环境（最为稳定功能最为完整）
• test 分支（release分支） => 测试环境（发布定期要上线的功能）
• dev 分支 => 团队协作的发开环境（功能最新最全的分支）
• hotfix 分支 => 修复线上代码的 bug
• feature分支 => 某个功能点正在开发阶段

各分支关系：

开发阶段

1. 功能细分
2. 创建一个对应的 feature 分支，拉取 dev 分支代码，进行开发
3. 功能开发完并自测之后，先切换到 develop 分支将最新的代码拉取下来，再切换回自己负责的 feature 分支把 develop 分支的代码合并进来。有冲突解决冲突。
4. gitlab上创建合并请求（merge request）
5. 项目负责人代码审核, 有问题解决，没问题接受 merge request，删除对应的 feature 分支。

测试环境

1. 完成新功能后，dev 分支提交到 test 分支（release分支），进行测试
2. 有bug：创建hotfix 分支（修复后合并到 test 分支）

发布上线

1. release 分支合并进 master 和 develop
2. 上线
3. 线上环境小 bug：创建 hotfix 分支进行修改，大bug：版本回滚

分支命名

参考：

• feature——按照功能点（而不是需求）命名；
• test(release)——用发布时间命名，可以加上适当的前缀；
• hotfix——GitLab 的 issue 编号或 bug 性质等。

git hook

用 Git 钩子进行简单自动部署
Git 钩子(hooks)是在 Git 仓库中特定事件(certain points)触发后被调用的脚本。
客户端:

1. commit 之前 eslint 检查

服务端:

1. 远程服务器同步拉取最新文件，重启服务器

参考

Git: 教你如何在Commit时有话可说
git-recipes
用 Git 钩子进行简单自动部署
团队中的 Git 实践
使用 git rebase 避免無謂的 merge
团队规范第一步 - EditorConfig & ESLint & git hook