整理了一下之前为团队制定的 Git 操作规范,在此记录。
使用 commitizen 等工具提交符合 Angular 规范的 commit message。
要求至少包含 header,即: <type>(<scope>): <subject>
。
所有提供给用户使用的正式版本,都在这个主分支上发布。
用于日常开发。如果想正式对外发布,就在 master 分支上,对 dev 分支进行『合并』(merge)。
新的临时分支从 origin/master 拉取, 保证代码最新。使用完毕后,需要及时删除。 临时分支包括以下两种:
作用为开发某个特定功能,从 dev 分支上分出来,开发完成后需要再合入 dev 分支。 命名规范:feature-{功能名称}-{姓名缩写},如 feature-template-ljl
作用为修复某个线上 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
。
此处涉及 code review 策略,此处给出整体流程建议:在代码需要合并入 dev 和 master 分支时发起 PR,请求同事进行 review,确认无误后合并入相应分支。
以下内容推荐但不强制(当你明确了解这些操作可能造成什么样的后果以及能解决什么问题时再考虑使用):
我的博客即将同步至腾讯云+社区,邀请大家一同入驻: https://cloud.tencent.com/developer/support-plan?invite_code=231p3tqjirwko