Appearance
Git
单分支模型
如果一个项目的前端开发者不超过 5 名,为快捷开发和部署,尽量使用单分支模型,即只创建master
(或main
)分支。
图形化工具
重度使用图形化工具的话,应使用
Sourcetree
。下载地址:https://www.sourcetreeapp.com轻度使用的话,可以使用
TortoiseGit
。
日常推送流程
提交
-> 拉取
-> 如果有冲突则解决冲突且重新提交和拉取
-> 推送
约束提交说明
提交说明即 Commit message,根据最流行的 Angular 规范的最简洁规范,提交说明的格式为:<type>: <subject>
,比如:feat: 视频播放器增加了倍速播放功能
。其中:
type
可以有这些值,按照使用频率排列如下,日常使用前三个:feat
:新特性fix
:修改问题refactor
:代码重构docs
:文档修改style
:不影响代码运行代码格式修改,注意不是 CSS 修改test
:测试用例修改chore
:其他修改,比如构建流程、依赖管理pref
:性能提升的修改build
:对项目构建或者依赖的改动ci
:对持续集成的修改
type
后面的冒号必须是英文冒号,后面敲个空格。subject
是主题,中英文均可,追求言简意赅,准确表达,通常为主谓宾结构或动宾结构,末尾不加标点。
如何约束合作程序员的提交说明:
❌ 不应采用本地安装一些库来约束提交说明,因为本地 gitHooks 可以被绕过。不能被绕过的是服务端 gitHooks。
✔️ 采用服务端 gitHooks 方案,比如 GitLab 就提供了这种技术,具体由运维或后端程序员实施,在此不赘述。在 GitLab 没有部署 gitHooks 的前提下,依靠同事的自觉即可,毕竟提交记录是可以被看到的。
提交时机
多个主题必须及时独立提交,不允许合并提交。
对上一次提交的修改,应执行“修改上一次提交”,禁止生成新的提交。
打标签
由负责发布者给提交打标签,标签即版本号。打标签意味着即将发布新版本。操作流程:
提升
package.json
的版本号,然后提交,提交说明的type
使用build
,subject
写上发布 v1.x.x
之类。本地打包或服务器打包、部署即可。