- 用 git cz 代替 git commit 操作
- 全局安装
npm install -g commitizen cz-conventional-changelog
npm i -g cz-customizable - 写入配置
echo'{ "path": "cz-customizable" }' > ~/.czrc - 在项目根目录下写入文件.cz-config.js
module.exports = {
// 可选类型
types: [
{ value: 'feat', name: 'feat: 新功能' },
{ value: 'fix', name: 'fix: 修复' },
{ value: 'docs', name: 'docs: 文档变更' },
{ value: 'style', name: 'style: 代码格式(不影响代码运行的变动)' },
{ value: 'refactor', name: 'refactor: 重构(既不是增加feature，也不是修复bug)' },
{ value: 'perf', name: 'perf: 性能优化' },
{ value: 'test', name: 'test: 增加测试' },
{ value: 'chore', name: 'chore: 构建过程或辅助工具的变动' },
{ value: 'revert', name: 'revert: 回退' },
{ value: 'build', name: 'build: 打包' },
],
// 消息步骤
messages: {
type: '请选择提交类型:',
scope: '请选择一个scope (可选):',
customScope: '请输入修改范围(可选):',
subject: '请简要描述提交(必填):',
body: '请输入详细描述，使用“|”进行换行(可选):',
footer: '请输入要关闭的issue，或打上私有部署标签(可选):',
confirmCommit: '确认使用以上信息提交？(y/n/e/h)',
},
allowCustomScopes: true,
scopes: [
{ name: '树结构模块' },
{ name: '设计稿模块' },
{ name: '单页模块' },
{ name: '原型稿模块' },
{ name: '演示模块' },
],
// 跳过问题
skipQuestions: ['body', 'scope'],
// subject文字长度默认是72
subjectLimit: 72,
};
现在可以在命令行中使用 git cz 操作来替代git commit 了。- 私有化部署如何较少冲突
- 优化commit-message ，使用git cz 提交commit 信息，在footer 中打上标签 #readme问题号(2023.1-p)
- git rebase ，在合并分之前都确保分支是经过git rebase 变基之后的提交。使分支更好路径更简洁，方便查看代码提交以及生成gitlog。以及分支合并策略 - 从最先提交开始合并。保证我们的分支如下图，形成一条笔直的直线状态。（rebase 原理在于在本地先同步远程分支，并解决了冲突了，在cherr-pick过程中就不会产生冲突）
- gitlab中配置 merge前进行 git rebase操作。（在配置这个前，最好的方法是尽快合并开发分支到月度版本上，尽可能避免同时几个分支需要合并的情况）
目前先将各自的合并请求发送到小组群里。 - 通过git log 来检索过滤有带有私有部署的commitID。再通过 git chery-pick commitID 来将私有化部署迁移到私有化分支上
1. 配置别名
git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset %b' --date=format:"%Y-%m-%d %H:%M:%S""
2. 执行 私有化部署查询 并 在私有化分支上新开一个分支 通过cherry-pick 从列表最底端开始pick操作。
git lg --grep="2023.1-p"
git cherry-pick c72c479
最后再将新建的分支，合并到私有化部署主分支上。最后再将整个版本合并到私有化部署分支上，也不会出现冲突，大功告成
3. 整体流程如下
- 在自己的分支上修改代码，需要提交代码时
- git add .
- git cz (替代原来的git commit -m ，不再使用 git commit 了)
- 根据git cz 控制面板提示选择和填写
5. git push 将我们本地分支推送到远程
6. 在 gitlab 中进行merge 合并代码申请
- 如果需要 进行rebase 重新提交的，流程如下
1. 在自己本地分支上 执行 git rebase origin/dev-2023-02
2. 如果有冲突，先修改冲突，然后执行git add . 和 git rebase --continue
3. 将本地分支强推到远程 git push -f (切记不可根据提示 执行 git pull )
4. 推送远程成功后，再到gitlab上进行分支合并就不会落后taget分支提示了，可以正常合并代码 - 我们的目标
- 回顾过去的分支记录
- 现在稍微努力后的分支记录
- 第一周适应过程，大家遇见不同的问题多沟通多讨论
- 第二周全面严格执行，让合并分支变成一根笔直的线 （如下图lodash团队分支图）
- 关于思想问题
- 本地分支（fix分支） 合并 到主开发分支（dev-2023-02）需要 先进行rebase 这个操作，目的是为了同步远程分支，为什么不能使用merge？ 那什么情况下需要使用merge，merge or rebase 如何选择？
首先merge 和 rebase 都能达到同步分支的效果，merge 会使得我们本地分支保留我们拉分支的时间，并且会生成一个新的commit合并记录。但也会使得我们整个分支结构看起来十分混乱。如果小团队人员多起来，我们整个分支结构将变得很难管理，如遇到 需要代码回退，解决冲突问题变得十分棘手，稍不注意会出现 解决冲突代码被合并掉了 这种大问题，不利于分支以及代码的管理。并且merge 处理冲突需要手动再加一个commit ，如果后续需要进行chery-pick 还得把冲突的commit 一起搞过去。
使用rebase 能很好解决merge带来的混乱问题，让分支结构清晰明了。rebase的变基操作，让我们去除了我们拉取分支时间这个多余的信息干扰，我们本地分支合并 dev分支，我们是不在乎你什么时候拉的分支，只在乎你什么时候合并的分支，所以这儿rebase 也能起到很好的过滤无用信息的作用。
那我们什么时候时候使用merge？原则思想是，当我们在乎 我们分支拉取的时间，需要保留这个信息的时候，我们要同步主分支的代码时就使用merge。 例如： master上有hotfix分支更新，我们想把master上的hotfix修改的代码 同步到我们本月开发分支 dev-2023-02 上时，这个时候就需要使用 merge， 为什么不能用rebase？
因为我们在意 我们dev-2023-02分支 拉取的时间（这个是月度开发分支，基准点具有一定的参考意义，不能随意改变）
具体关于merge 和rebase 的区别，参考
2. 为什么要去规范git流程？
- git 分支合并记录清晰，明了。了解一个项目从代码合并分支图，能很清晰看到这个版本的需求情况
- 有利于分支管理和代码管理，如遇到需要 代码回退情况，清晰的合并记录能很简单解决回退问题，且不容易出现代码掉了的情况
- 有利于冲突的解决，每个合并分支都先进行rebase，后续代码合并都是最小冲突的版本。
- 有利于解决 私有化部署 反复来回合并 出现大量冲突问题。
- 加上其他的一些流程优化，让我们整体流程变得更加合理，规范，便于管理，减少冲突
- 分支合并后，就遗弃。重新从开发分支上拉分支。尽量不要一个分支用到底。