技术工具

Git日志提交规范

规范Git Commit有利于后续接手开发的人员

约定式提交规范(Conventional Commits)

https://www.conventionalcommits.org/zh-hans/v1.0.0/
原文：

1
2
3
4
5
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

译文：

1
2
3
4
5
<类型>[可选 范围]: <描述>

[可选 正文]

[可选 脚注]

类型（type）

1
2
3
4
5
6
7
8
9
10
11
feat:  类型为 feat 的提交表示在代码库中新增了一个功能（这和语义化版本中的 MINOR 相对应）。
fix：类型为 fix 的 提交表示在代码库中修复了一个 bug （这和语义化版本中的 PATCH 相对应）。
docs: 只是更改文档。
style: 不影响代码含义的变化（空白、格式化、缺少分号等）。
refactor: 代码重构，既不修复错误也不添加功能。
perf: 改进性能的代码更改。
test: 添加确实测试或更正现有的测试。
build: 影响构建系统或外部依赖关系的更改（示例范围：gulp、broccoli、NPM）。
ci: 更改持续集成文件和脚本（示例范围：Travis、Circle、BrowserStack、SauceLabs）。
chore: 其他不修改src或test文件。
revert: commit 回退。

范围（scope）
可选作用域用于说明 commit 影响的范围，比如数据层、控制层、视图层、模块名等等，视项目不同而不同。可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。
例如feat(order): 订单更新；涉及到多个模块可以用*代替。

Jira ID
Jira ID 可以是Jira上对应问题的ID，比如：故事ID、工单ID、任务ID、缺陷ID等，Commit Message 指定ID后，Jira会自动将提交记录与Jira问题关联，这样便于通过jira查看解决问题的代码。
例如feat(Controller): #JIRA-001 用户查询接口开发
注意使用英文冒号，冒号后面一个空格。

BREAKING CHANGE
在可选的正文或脚注的起始位置带有 BREAKING CHANGE: 的提交，表示引入了破坏性 API 变更（这和语义化版本中的 MAJOR 相对应）。 破坏性变更可以是任意类型提交的一部分。

IDEA使用Git Commit Template插件（https://plugins.jetbrains.com/plugin/9861-git-commit-template）比较方便

技术工具

gitlab分支管理实践

Shape1

Gitlab分支管理实践

  1. 整体流程图

  1. 分支规约
分支 分支命名 分支描述
功能开发分支 origin/feature_${feature} 1. 用于承载具体的功能开发，基于最新的master分支检出
1. 命名规范：feature_{日期}_{功能}。如：feature_20220809_login
开发集成分支 origin/develop 1. 在开发环境集成各个功能分支，用于开发自测或联调
测试/发布集成分支 origin/release_{release_date} 1. 在测试环境集成各个功能分支，用于测试人员测试
2. UAT环境验收（部分功能）：如果需要提前验收部分功能，则部署到UAT环境验收
3. 可能同时存在多个（即n * release），支持多版本并行测试（需要多套测试环境）
4. 命名规范：release_{发布日期}。如：release_20220801、release_20220801_1（部分功能无法上线，则重新检出）
热修复分支 origin/hotfix_${hotfix} 1. 用于修复生产环境Bug，基于master分支或指定Tag版本检出
2. 命名规范：hotfix_{日期}_{修复功能}。如：hotfix_20220801_loginBug
主干分支 origin/master 1. master分支代表项目的基线，不允许直接修改
2. UAT环境验收（全部功能）：全部功能测试通过后，将release_xxx合并到master分支，部署master到UAT环境验收
3. 生产环境发布：基于当前master分支打tag，审批发布上线
4. Tag命名规范：v{版本号}。如：v1.0.1
  1. 常规流程
序号 阶段 Gitlab 角色 组织角色 操作 / 事项
1 迭代开始 Maintainer 开发组长/SA 基于最新master检出新的发布分支：release_xxx（可以多个）
Developers 开发人员 基于最新master检出新的开发分支：feature_xxx（多人可共用一个）
2 开发阶段 Developers 开发人员 在feature分支开发，开发完成后，将feature分支合并到develop分支，部署develop到开发环境自测或联调
3 提测阶段 Developers 开发人员 在Gitlab发起Merge Request，合并到release_xxx分支
4 代码审查&合并 Maintainer 开发组长/SA 完成Code Review并合并到release_xxx分支
5 测试阶段 Maintainer 测试人员 部署release_xxx分支到测试环境测试（支持多版本并行测试，需要多套测试环境）
6 UAT验收 Maintainer 开发组长/SA 将release_xxx合并到master，部署master到UAT环境
Other 产品或业务 产品或业务在UAT环境验收
7 发布上线 Maintainer 测试人员 基于当前master分支打tag，发起生产环境部署审批，完成发布上线
8 收尾阶段 Maintainer 开发组长/SA 将master分支合并到develop分支以及下一发布分支或开发分支（如果存在的话）
  1. 热修复流程
序号 阶段 Gitlab角色 组织角色 操作 / 事项
1 开发修复 Developers 开发人员 基于当前master检出热修复分支hotfix_xxx，修复后合并到develop分支，部署develop到开发环境自测或联调
2 开发提测 Developers 开发人员 通知测试人员部署hotfix_xxx分支测试
3 测试阶段 Maintainer 测试人员 部署hotfix_xxx分支到测试环境测试
4 合并请求 Developers 开发人员 在Gitlab发起Merge Request，合并到master分支
5 代码审查&合并 Maintainer 开发组长/SA 完成Code Review并合并到master分支
6 UAT验收 Maintainer 开发组长/SA 部署master分支到UAT环境验收
Other 产品或业务 产品或业务在UAT环境验收
7 发布上线 Maintainer 测试人员 基于当前master分支打tag，发起生产环境部署审批，完成发布上线
8 收尾阶段 Maintainer 开发组长/SA 将master分支合并到develop分支以及下一发布分支或开发分支（如果存在的话）
  1. 规约

5.1 Git 提交日志

  1. Git提交必须编写commit message，否则不允许提交

  2. Git提交日志必须符合【Git** 日志规范**】，否则不允许合并（直接打回Merge Request）

5.2 版本命名规范

  1. 版本号规范：采用GNU风格版本号，参考【版本命名规范】。第三位作为特性或修复版本，如1.0.1、1.0.2…

  2. Tag命名规范：v{版本号}，如：v1.0.1

5.3 分支合并规范

  1. 【禁止】将测试发布分支release_xxx和develop分支合并回feature分支

  2. 【推荐】每次发版后，及时将master合并回develop和feature分支

  3. 【推荐】feature分支合并到master并上线后即可删除

  4. 项目设置

6.1 角色分配

  1. 项目组长统一分配组员角色，指定Maintainer角色人员（测试人员全部设置为Maintainer）

6.2 分支保护

  1. 测试/发布分支（release_*）：只允许项目maintainer合并和推送

  2. 生产分支（master）：只允许项目maintainer合并和推送

6.3 Tag保护

  1. 只允许项目Maintainer能创建tag（进而触发生产环境审批/发布）

  1. 常见问题

1、如何解决多个功能，需要先后发布到UAT环境验收的问题？

方案：直接将当前迭代发布分支release_xxx，部署到UAT环境验收

常用的Linux命令

获取linux服务器所有java进程及名称

pidof java|xargs pwdx

pidof：用于查找指定名称的进程的进程号id号
-s 一次只显示一个进程号
-c 只显示运行在root目录下的进 程，这个选项只对root用户有效
-o 忽略指定进程号的进程
-x 同时显示在shell脚本运行中的相同名称

xargs：将参数列表转换成小块分段传递给其他命令,需要另外学习

pwdx [1234]：查看当前pid进程启动时的工作目录

职场与管理

德鲁克谈【自我管理】——《哈佛商业评论》史上最受欢迎的文章

文章目录

★背景介绍
★0、前言
★1、我的长处是什么？
★2、我的工作方式是怎样的？
★3、我如何学习？
★4、我的价值观是什么？
★5、我属于何处？
★6、我该做什么贡献？
★7、我要如何处理人际关系？
★8、我该如何管理后半生？

★背景介绍

　　今天转载的这篇《管理自己》，洋文叫做《Managing Oneself》。此文刊登在十年前（2008）的《哈佛商业评论》（HBR）上，号称是 HBR“有屎以来”（创刊后）重印次数最多的文章。

关于《哈佛商业评论》（Harvard Business Review）

　　《哈佛商业评论》，简称“HBR”。在管理领域，它可算是大名鼎鼎、如雷贯耳。别的不说，单凭它出自同样大名鼎鼎的【哈佛大学商学院】，就体现出这家刊物的逼格有多么高。
　　顺便说一下：2022该刊物迎来百年庆。

关于“彼得·德鲁克”（Peter F. Drucker）

此文作者德鲁克（又译“杜拉克”），被尊称为【管理学之父】。知名的《经济学人》杂志评价他是【大师中的大师】。
　　这位老兄不但著作等身，而且每本书都是质量上乘。下面列举他的【部分】著作。从中也可以看出：他创作的时间跨度很长，称得上是“与时俱进”。 

1
2
3
4
5
6
7
8
9
10
11
12
《经济人的末日》（The End of Economic Man）　1939年  
《工业人的未来》（The Future of Industrial Man）　1942年  
《管理实践》（The Practice of Management）　1954年  
《卓有成效的管理者》（The Effective Executive）　1966年  
《管理——使命、责任、实务》（Management——Tasks, Responsibilities, Practices）　1973年  
《动荡时代中的管理》（Managing in Turbulent Times）　1980年  
《变动中的管理界》（The Changing World of the Executive）　1982年  
《新现实——政府与政治、经济与企业、社会与世界》（The New Realities——in Government and Politics, in Economics and Business, in Society and World View）　1989年  
《后资本主义社会》（Post-Capitalist Society）　1993年  
《巨变时代的管理》（Managing in a Time of Great Change）　1995年  
《21世纪的管理挑战》（Management Challenges for 21st Century）　1999年  
《下一个社会的管理》（Managing in the Next Society）　2002年

关于此文

　　今天分享的这篇《Managing Oneself》实际上是摘自他1999年出版的《21世纪的管理挑战》一书的第6章（也是最后一章）。
　　为啥俺要分享此文？因为，这篇长文【对每个人都很有帮助】。通过此文的借鉴，可以帮助你更好地规划自己的职业生涯和人生。
　　这篇文章在网上有很多转载，但有些转载不全（删节了部分段落）。俺对比了几个不同的网站，汇总了一个比较全的版本；然后根据俺自己的理解，标注了重点（文中的粗体）。另外，文章中的插图也是俺从网上找来滴。

★0、前言

我们生活的这个时代充满着前所未有的机会：如果你有雄心，又不乏智慧，那么不管你从何处起步，你都可以沿着自己所选择的道路登上事业的顶峰。

不过，有了机会，也就有了责任。今天的公司并不怎么管员工的职业发展；实际上，知识工作者必须成为自己的首席执行官。你应该在公司中开辟自己的天地，知道何时改变发展道路，并在可能长达50年的职业生涯中不断努力、干出实绩。要做好这些事情，你首先要对自己有深刻的认识——不仅清楚自己的优点和缺点，也知道自己是怎样学习新知识和与别人共事的，并且还明白自己的价值观是什么、自己又能在哪些方面做出最大贡献。因为只有当所有工作都从自己的长处着眼，你才能真正做到卓尔不群。

　　历史上的伟人——拿破仑、达芬奇、莫扎特——都很善于自我管理。这在很大程度上也是他们成为伟人的原因。不过，他们属于不可多得的奇才，不但有着不同于常人的天资，而且天生就会管理自己，因而才取得了不同于常人的成就。而我们当中的大多数人，甚至包括那些还算有点天赋的人，都不得不通过学习来掌握自我管理的技巧。

　　我们必须学会自我发展，必须知道把自己放在什么样的位置上，才能做出最大的贡献，而且还必须在长达50年的职业生涯中保持着高度的警觉和投入——也就是说，我们得知道自己应该何时换工作，以及该怎么换。

★1、我的长处是什么？

　　多数人都以为他们知道自己擅长什么，其实不然！更多的情况是，人们只知道自己不擅长什么——即便是在这一点上，人们也往往认识不清。然而，一个人要有所作为，只能靠发挥自己的长处，而如果从事自己不太擅长的工作是无法取得成就的，更不用说那些自己根本干不了的事情。

　　以前的人没有什么必要去了解自己的长处，因为一个人的出身就决定了他一生的地位和职业：农民的儿子也会当农民，工匠的女儿会嫁给另一个工匠等。但是，现在人们有了选择。我们需要知己所长，才能知己所属。

　　要发现自己的长处，唯一途径就是回馈分析法（feedback analysis）。每当做出重要决定或采取重要行动时，你都可以事先记录下自己对结果的预期。9到12个月后，再将实际结果与自己的预期比较。我本人采用这种方法已有15到20年了，而每次使用都有意外的收获。