多人协作 Git 操作规范指南

整理了一下之前为团队制定的 Git 操作规范，在此记录。

一. 按规定格式提交 commit message

使用 commitizen 等工具提交符合 Angular 规范的 commit message。 要求至少包含 header，即： <type>(<scope>): <subject>。

二. git 分支管理策略

主分支 master

所有提供给用户使用的正式版本，都在这个主分支上发布。

开发用分支 dev

用于日常开发。如果想正式对外发布，就在 master 分支上，对 dev 分支进行『合并』（merge）。

临时分支

新的临时分支从 origin/master 拉取, 保证代码最新。使用完毕后，需要及时删除。 临时分支包括以下两种：

功能分支

作用为开发某个特定功能，从 dev 分支上分出来，开发完成后需要再合入 dev 分支。 命名规范：feature-{功能名称}-{姓名缩写}，如 feature-template-ljl

bug 修复分支

作用为修复某个线上 bug，从 master 分支上分出来，修复结束后再合入 dev 和 master 分支。 命名规范：hotfix-{功能名称}-{姓名缩写}，如 hotfix-template-tj

注：bug 修复分支需要先 merge origin master 以获取最新修改。且该类型的分支只能被合并，不能主动合并除了 master 分支之外的分支，以避免误带上别的分支。

三. 临时提交

当有临时提交代码的需求但是 commit message 不知如何写或者想合并多个 commit 时，使用以下两种方式（具体用法自行 Google）：

git rebase -i （pick、squash）
git commit --amend

另，merge 代码时如想合并多个 commit，可使用 git merge --squash。

四. Pull Request

此处涉及 code review 策略，此处给出整体流程建议：在代码需要合并入 dev 和 master 分支时发起 PR，请求同事进行 review，确认无误后合并入相应分支。

五. 推荐

以下内容推荐但不强制（当你明确了解这些操作可能造成什么样的后果以及能解决什么问题时再考虑使用）：

1. 未推送过的分支使用 git rebase 代替 merge 合并 master 分支
2. merge 时添加参数 --ff，以启用 fast forward 方式
3. pull 时添加参数 --rebase，使用 rebase 策略替代默认的 merge 策略

我的博客即将同步至腾讯云+社区，邀请大家一同入驻： https://cloud.tencent.com/developer/support-plan?invite_code=231p3tqjirwko