1. 目的
统一团队 Git Commit 标准，便于后续代码 review、版本发布、自动化生成 change log
可以提供更多更有效的历史信息，方便快速预览以及配合 cherry-pick 快速合并代码
团队其他成员进行类{{git blame}}时可以快速明白代码用意
2. Git 版本规范
2.1 分支
master
develop
feature
开发分支，任何时候都是从 develop 为基础，创建 feature 分支
分支命名：feature/开头，例如：feature/user_module, feature/cart_module
开发完成后，本地完成测试后，提交到 develop 合并
release
预上线分支，发布提测阶段，以 release 分支为基准提测
准备发布提测时，以 develop 为基础，创建 release 分支
如果测试过程中出现 bug，开发者直接基于 release 分支修改并提交
测试完成后，合并 release 分支到 master 和 develop 分支，此时 master 为最新稳定发布版本，用作上线
hotfix
线上出现紧急问题时，需要及时修复，以 master 为基础创建 hotfix 分支
修复完成后，hotfix 分支提测，上线前需要合并到 master 和 develop 分支，再以 master 分支上线
分支命名：hotfix/开头，例如：hotfix/user_module, hotfix/cart_module
2.2 常见开发流程
建立仓库关系
(master)$: git clone git@xxx_self.git # 克隆个人fork出来的代码库(master)$: git remote add upstream git@xxx_team.git # 关联团队代码库(master)$: git remote -v # 查看代码库关系 origin ssh://git@182.92.163.137:2222/jiangdongwei/maxwell-front.git (fetch)origin ssh://git@182.92.163.137:2222/jiangdongwei/maxwell-front.git (push)upstream ssh://git@182.92.163.137:2222/zino_tech/maxwell-front.git (fetch)upstream ssh://git@182.92.163.137:2222/zino_tech/maxwell-front.git (push)
复制代码
本地代码同步
(dev)$: git fetch upstream # 更新本地项目代码库(dev)$: git rebase upstream/develop # 更新本地托管环境(dev)$: git checkout feature/xxx # 切换开发分支(feature/xxx)$: git rebase develop # 更新本地feature分支 # 多人合作开发feature/xxx(feature/xxx)$: git rebase upstream/feature/xxx(feature/xxx)$: git rebase develop # 更新本地feature分支
复制代码
开发新功能
(dev)$: git checkout -b feature/xxx # 创建feature分支(feature/xxx)$: blabla # 开发(feature/xxx)$: git add xxx(feature/xxx)$: git commit -m 'commit comment' # 场景1：独立开发feature(dev)$: git merge feature/xxx --no-ff # 把特性分支合并到dev(dev)$: git push origin develop # 把dev分支提交到fork的托管# 发起pull request，更新项目develop分支 # 场景2：多人合作feature(feature/xxx)$: git push origin feature/xxx# 发起pull request，更新项目feature/xxx分支 # pull request 完成后，准备merge的时候，可能开始分支的时候的代码库已经过时，这个时候需要更新分支点，再更新pull request，再合并(dev)$: git fetch upstream # 更新本地项目代码库(dev)$: git rebase upstream/develop # 更新本地托管环境(dev)$: git checkout feature/xxx # 切换开发分支(feature/xxx)$: git rebase develop # 更新本地feature分支(feature/xxx)$: git rebase upstream/feature/xxx# 更新pull request(feature/xxx)$: git push origin feature/xxx# 检查pull request更新情况，合并代码 # 删除远程分支(feature/xxx)$: git push origin :feature/xxx
复制代码
修复紧急 bug
(master)$: git checkout -b hotfix/xxx # 从master建立hotfix分支(hotfix/xxx)$: blabla # 开发(hotfix/xxx)$: git add xxx(hotfix/xxx)$: git commit -m 'commit comment'# pull request, 提测 # 通过pull request or leader知情的情况下直接操作项目仓库(master)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到master，并上线到生产环境(dev)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到dev，同步代码
复制代码
准备测试环境
(release)$: git merge dev --no-ff # 把dev分支合并到release，然后在测试环境拉取并测试
复制代码
生产环境上线
Tag：采用三段式，v 版本.里程碑.序号，如{{v1.2.1}}
架构升级或架构重大调整，修改第 2 位
新功能上线或者模块大的调整，修改第 2 位
bug 修复上线，修改第 3 位
(master)$: git merge release --no-ff # 把release测试好的代码合并到master，运维人员操作(master)$: git tag -a v0.1 -m '部署包版本名' # 给版本命名，打Tag
复制代码
合并提交
通常本地会有很多次 commit，例如 3 次提交，然后提交到 fork 的分支之后，会有 3 次提交记录，但是代码审查和后面的合并的时候，实际上你并不希望同事看到你本地的 3 次提交记录，这个时候希望把本地先压缩之后，再上传；这个时候可以用 git rebase -i
在终端输入: git rebase -i HEAD~2 这里的 HEAD~2 表示合并最近两次的提交, 如果想合并最近三次的提交修改为: git rebase -i HEAD~3
输入 git rebase -i HEAD~2 命令后, 会弹出编辑器
将第二行的 pick 改为 s “s” 为 “squash” 的缩写
“squash” 的意思是 将倒数的这二次提交 压缩为最后一次提交
然后保存
将 This is the commit message 下面的内容改成你想提交的概述即可
具体参考：https://blog.csdn.net/ywdhzxf/article/details/90517432
https://www.cnblogs.com/amou/p/9465880.html
3. Git 提交消息规范
编写良好的 Commit messages 可以达到 3 个重要的目的：
Commit messages 的基本语法
当前业界应用的比较广泛的是 Angular Git Commit Guidelines
具体格式为:
<type>(<scope>): <subject><BLANK LINE><body><BLANK LINE><footer>
复制代码
type: 本次 commit 的类型，诸如 bugfix docs style 等
scope: 本次 commit 波及的范围
subject: 简明扼要的阐述下本次 commit 的主旨，在原文中特意强调了几点 1. 使用祈使句，是不是很熟悉又陌生的一个词，来传送门在此 祈使句 2. 首字母不要大写 3. 结尾无需添加标点
body: 同样使用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比如此次变更的动机，如需换行，则使用 |
footer: 描述下与之关联的 issue 或 break change
Type 的类别说明：
feat: 添加新特性
fix: 修复 bug
docs: 仅仅修改了文档
style: 仅仅修改了空格、格式缩进、typo 等等，不改变代码逻辑
refactor: 代码重构，没有加新功能或者修复 bug
perf: 增加代码进行性能测试
test: 增加测试用例
chore: 改变构建流程、或者增加依赖库、工具等
Commit messages 格式要求
# 标题行：50个字符以内，描述主要变更内容## 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:## * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等# * 他如何解决这个问题? 具体描述解决问题的步骤# * 是否存在副作用、风险?## 如果需要的化可以添加一个链接到issue地址或者其它文档
复制代码
案例
feat($browser): onUrlChange event (popstate/hashchange/polling) Added new event to $browser:- forward popstate event if available- forward hashchange event if popstate not available- do polling when neither popstate nor hashchange available Breaks $browser.onHashChange, which was removed (use onUrlChange instead)
复制代码
fix($compile): couple of unit tests for IE9 Older IEs serialize html uppercased, but IE9 does not...Would be better to expect case insensitive, unfortunately jasmine doesnot allow to user regexps for throw expectations. Closes #392Breaks foo.bar api, foo.baz should be used instead
复制代码
参考：
评论