京东商智_Git高效协作与开发

一、方案设计篇

对于团队来说，人越多，协作就会越慢，协作的成本也会越高。团队研发本质是一个异步的、延迟协作的过程，随着产品负责度和团队复杂度的增加，协作成本快速上升。

要实现沟通成本和冲突风险最小化，要尽可能实现每个人的工作是独立的。为此，一个好的、合理的技术方案是非常重要的。

1.技术方案设计

负责人进行总体技术方案设计：基于项目目标和技术全景进行解决方案的产出；梳理可能设计的子事项并按照职责切割成具体模块；明确不同模块之间所需要的串联关系。(知目标、有全景、做切割、串流程)
每个开发人员进行子模块细节方案设计：根据开发模块和任务产出子模块方案设计；细节到2人日以下的功能点粒度；明确变更数据库结构；明确上下游&前后端交互协议。
项目所有开发人员共同评审设计方案：确保每个人了解项目和子模块的目标、功能与负责人；每个人认可并清楚了解自己与上下游的串联关系；任何不明确的点在方案设计阶段确认清楚，依赖串联越早越好。

2.晚8累计需求案例

对于定义驱动生产，项目较复杂，上述方案设计与交互沟通步骤尤为重要。

总体方案：生产消费联动-date_avaliable支持time_interval
消费侧方案：date_avaliable支持time_interval方案设计
生产侧方案：自动化生产-时间协议-晚8分时\累计趋势图

开发至半段仍然发现有一些元数据存储和物理数据存储上在方案设计阶段为明确的点：

BY_HOUR       按如下格式支持：BY_HOUR           t-day time   day=1 time=20:00:00
BY_WEEK_ACCU  按如下格式支持：BY_WEEK_ACCU      ''           ''
BY_MONTH      按如下格式支持：BY_MONTH          ''           ''
天以下可用时间的startdate、enddate都写到秒
天以下可用时间的enddate保存到23:59:59类似的59秒粒度
accu_expr中  time:都到秒粒度：t-day time    day=1 time=20:00:00

不要吝啬在方案设计阶段的时间投入！

简单项目：设计时间占总时间的20%，具体开发时间占80%。
中等复杂度项目：设计时间占总时间的30-40%，具体开发时间占60-70%。
复杂项目：设计时间可能占总时间的40-50%，具体开发时间占50-60%。

二、分支管理篇

1.常见四种开发模式和五类分支

四种开发模式：TBD主干开发模式、Git-Flow模式、GitHub-Flow模式、GitLab-Flow模式

1
2
3

主干开发模式（Trunk-Based Development）：这是当团队人数较少时最常见的研发模式，特点是团队在主干上进行所有的开发工作，减少了分支的管理和维护成本。这种模式下，所有的开发者在主干上频繁地提交代码，进行持续集成。虽然这种模式在人数较少且工程能力较强的情况下表现良好，但随着参与开发的人数增加，代码提交的冲突几率也会大大增加，对工程能力的要求更高。因此，主干开发模式并不适用于所有情况，特别是在大型项目或需要高度协同开发的场景中。
Git-Flow模式：这是一种更复杂的分支管理策略，适用于需要严格管理发布版本和长期维护的项目。它明确了主分支、开发分支、发布分支和特性分支的角色，确保了代码的稳定性和可维护性。Git-Flow模式通过明确的分支策略，使得团队可以更好地管理不同版本和功能特性，适用于需要频繁发布和维护的项目。
GitHub-Flow模式和GitLab-Flow模式：这两种模式都是基于Git的版本控制系统中的工作流程，它们强调的是快速反馈和适应变化。GitHub-Flow模式鼓励小规模的迭代开发，快速发布新功能，而GitLab-Flow则更注重于团队的协同工作和代码审查。这两种模式都适合于敏捷开发和快速迭代的项目，能够快速响应市场变化和用户需求。

五类分支：master分支、develop分支、feature分支、release分支、fixbug分支

master分支：所有提供给用户使用的正式版本，都在这个主分支上发布。
develop分支：日常开发，正式对外发布时，需要将develop分支合并到master进行发布。
feature分支：为了开发某种特定功能，从develop分支上面分出来的，开发完成后，要再并入develop和master。
release分支：在发布正式版本之前，即合并到master分支之前，可能需要有一个预发布的版本进行测试。是从develop分支上面分出来的，预发布结束以后，必须合并进develop和master分支。
fixbug分支：修补bug分支。从master分支上面分出来，修补结束以后，合并进develop和master分支。

2.定义驱动生产开发建议

结合目前定义驱动生产项目开发现状，建议每一个项目需要有主开发分支，基于该主开发分支使用主干开发模式，每个开发人员在自己的子模块分支上开发。

最佳实践项：

定期拉取主分支：在你的分支上工作时，定期从远程仓库拉取主分支的更新，以避免你的分支与主分支的差异过大。这样可以减少合并时出现的冲突。
小而频繁的提交：每次提交都应该是小的、独立的、可重复的和有意义的。这样可以使代码审查更加容易，并且在出现问题时更容易回溯。（master合并到主开发分支merge与rebase的选择）
避免多分支修改同一文件：避免在多个分支上同时修改同一文件的同一部分，减少冲突出现。
沟通和协调：在团队中进行多分支协同开发时，良好的沟通和协调至关重要。确保所有人都了解当前的分支情况和谁在处理哪个任务。

三、规范命名篇

1.分支命名

规范良好的分支命名，可以快速清晰地告诉其他人这个分支的目的和内容，有助于在大型项目中管理和维护众多的分支，且一些自动化工具和 CI/CD 流程可以根据分支命名模式自动执行特定任务。

1	<type>_<version>_<describe>

字段	范例	说明
type	feature	用于开发新功能的分支
fix	修复特定版本中的错误
release	用于准备发布的版本，允许进行最后的调整
hotfix	用于紧急修复生产环境中的问题
docs	文档变更分支
refactor	重构变更分支
test	测试分支
version	v1.0.0、v1.0、v1、1.0.0	版本编号
describe	feature_v1_sz_8pm_trend	分支改动目的或功能的精炼概括

案例：feature_v1.0.0_authentication

2.commit命名

规范良好commit message可以加快代码review的流程，帮助我们编写良好的版本发布日志，也方便让之后的维护者了解代码里出现特定变化和feature被添加的原因。

业界应用的比较广泛的是Angular Git Commit Guidelines规范

<type>(<scope>): <subject>



<body>



<footer>

字段	范例	说明
type	feat、fix、docs、style、perf、test、chore、refactor等	提交类型。
scope	core	可选项，本次commit波及的范围。
subject	feature_v1_sz_8pm_trend	简明扼要地阐述下本次commit的主旨，使用祈使句，结尾无需添加标点，不超过50个字符。
body	背景…细节…	可选项，同样使用祈使句，在主体内容中我们需要把本次commit详细地描述一下，比如此次变更的动机，内容必须大于20个字符。
footer	issue	可选项，描述下与之关联的issue或break change。

Angular Git Commit Guidelines中推荐的type类型如下

feat：新增功能。
fix：修复 bug。
docs：仅文档更改。
style：不影响代码含义的更改（空白、格式设置、缺失分号等）。
refactor：既不修复 bug 也不添加特性的代码更改。
perf：改进性能的代码更改。
test：添加缺少的测试或更正现有测试。
chore：对构建过程或辅助工具和库（如文档）的更改。
delete：删除功能或文件。
modify：修改功能。
build：改变构建流程，新增依赖库、工具等（例如 webpack、gulp、npm 修改）。
test：测试用例的新增、修改。
ci：自动化流程配置修改。
revert：回滚到上一个版本。

案例：

)

四、代码审查篇

Code Review，即代码审查，是一种通过人工评审代码以发现并修正错误的实践。首先，它可以显著降低软件中的缺陷比例；其次，它促进了知识共享，通过评审的过程，团队成员可以相互学习，增强对系统的整体理解；最后，CR是一种预防措施，它有助于维护代码的清晰和统一，减轻技术债务，提升系统的稳定性。

代码审查checklist清单：

模块	简介（优先级从高到低）
设计	代码是否设计良好并适合您的系统？例如，API设计简单清晰，代码交互、系统交互恰当，技术组件、中间件使用得当等。
功能	代码的行为是否符合作者的预期，代码的行为方式对其用户有好处？例如，边界处理、异常死循环、非法的输入输出、大报文处理、兼容性问题、线程安全/并发问题、Exception处理等。
安全性	代码是否安全合规？例如，确保依赖服务SLA符合预期，超时和重试配置得当，避免产生慢SQL、大量锁等待、线程阻塞/耗尽等。
可观测性	是否在上线后可观测代码运行的行为，发生异常时可及时感知？例如，确保方法添加了必要的监控埋点、有正确的日志级别及日志内容。
复杂性	代码可以更简单吗？当其他开发人员将来遇到此代码时，他们是否能够轻松理解和使用此代码？
测试	代码是否具有正确且设计良好的自动化测试？
命名	开发人员是否为变量、类、方法等选择了明确的名称？命名应遵守代码规范，且能够准确表达代码的意图，而又不至于过长难以阅读。
注释	注释是否清晰有用？注释清晰无歧义，应解释代码“为什么”，而不是“是什么”。注释更应解释一些代码外的隐含信息，例如，设计的取舍、业务背景、某些看起来很tricky的实现，以及解释正则表达式、特定算法等内容。
风格	是否遵循一致的代码风格？风格无所谓好坏，但保持一致性的风格，会让其他团队成员更容易理解。
文档	是否需要更新相关API说明、Readme等文档？