前言
这几天跟一位大哥在探讨项目管理的一些曲折离奇的事情。谈谈体会，说说感想，展望展望未来。本文不适合PPT选手，也不适合跪太久的人，更不适合KPI洗脑的大佬，以上大佬求放过。 ##什么时候开始思考项目工程化 在我的开发生涯中，经历过多次将一个小项目通过不断迭代升级重构成一个大项目，这里小项目的定义可以说是项目功能较为单一、子系统量小或者是单系，而大项目的定义则是一个功能复杂，带有n个子系统共同维护的项目，中间无论小项目还是大项目都需要经历需求定义、项目开发、项目测试、项目上线、项目维护这些步骤，一开始对于小项目，在项目管理上比较粗糙，为什么呢？因为项目体量小，功能单一，相对来说开发测试维护都比较简单迅速，不需要一开始投入那么多精力去做项目开发测试维护的规划，但是随着迭代升级，小项目变成了大项目，这时候当一个开发者拿到项目到手上的时候，就只有完整的代码，这时候，我相信绝大部分的开发者都会崩溃，当然崩溃完之后，花费很多点时间总能掌握项目的，这时候回到我们的问题，从什么时候开始需要思考项目工程化？，对，就是当你的项目完全崩溃完之后，就是项目工程化的开始。
项目工程化的标准是什么？
我们期望我们的项目是具备一定的开发、测试、维护的效率以及可持续性，让需求、开发、测试、运维按照规范各司其职，分工协作来推动项目的进程，将时间花在对的地方。而不是多个人在一个坑里游啊游的。
项目工程化我们需要咋搞？咋整？
李嘉诚说买房子的标准是，位置、位置,还是位置。而我要说的是，规范、规范、还是规范。 规范是C，其他都是辅助。没有了C，辅助再好也是疲软。 讲到这里，想起多年前的一件事情。曾几时何，我觉得写单元测试就是多余，浪费时间，耽误开发进度的。为什么这么说尼？因为一开始我认为写单元测试这种基本都是形式主义。还不如直接写完程序，调用接口联调收工就ok了，没必要整这么复杂。但是结果尼？开发的童鞋高高兴兴去提测，测试的童鞋高高兴兴提bug，然后开发的童鞋又高高兴兴的去改bug,然后开始了无限的for循环。到什么时候break尼？直到质量过关。其实这个结果正常，也能接受。但是尼？很多时候由于开发的童鞋疏忽，导致很多同种类的bug出现一次又一次。甚至出现了明明还没有开发完现有的功能需求，这个for循环就已经很大了。导致项目很紧。最后莫名其妙的开始加班、加班、加班。其实将这么多，无非就是规范的问题。
什么是规范
-git规范 -设计架构规范 -单元测试 -代码书写规范 -适合的框架和技术运用在适合的位置 -通过使用自动化工具，加速开发进程。 -api规范 今天咱们只谈git的管理规范，剩下的后面一一讲解
提交规范
任何提交到git上的代码必须CodeReview 并且所提交的代码必须是自测通过的。
多分支管理
再多人协作的时候，每一个分支应该表示一个功能需求，这样做的好处在于，当需求变更或者取消，直接弃用即可。再多分支的情况下，特别要注意合并分支的时机。合并应该发生在测试完后进行，而在进行合并的时候，会出现各种奇奇怪怪的问题，因此封版的时间一般灰度前三天。在此期间对整个迭代需求进行回归测试，不允许存在bug以外的修改。这样做也是降低线上事故率。
多分支管理规范
随着项目进程的推进，需求越来越多。分支也越来越多。分支一多，发生的问题也越来越多，那我们如何管理这些分支尼？相信做过开发的童鞋应该对分包在熟悉不过了，但是git是没有层级关系的，无法直观的建立分包关系，这样就需要我们给分支名称前加/来达到我们想要的效果，那是不是可以随便给分支各种加，答案是no，上面讲过无规律不成方圆，因此在建立分支的时候，也有自己一套规范
多分支命名规范
如果是需求主分支，请以版本名+/+faeture-branch,例如：v1.0.1/feature-branch 如果是需求功能点分支，请版本名+/+feature+需求名称，例如：v1.0.1/feature-exam-count 如果是bug分支，请以版本名+/+fixbig-bug名称，例如：v1.0.1/fixbug-login-fix 除了以上版本，应该还存在release分支，他们的合并顺序应该是，bug分支或需求功能分支，合并到需求主分支，需求主分支合并到release分支，而release分支在完成合并后，应当进行一次打版。打版后的代码进行正常打版即可。 到此，可能有些小伙伴会有一个疑问？例如突然发现某一个版本（v1.0.3）出现bug，需要紧急打版一个修复版v1.0.3/fixbug-pay-fix，而线上有v2.1.1（基于v1.0.3）还在正常迭代。那么这个修复版，何时合并？为了遗忘，一般建议在打版后，即可合并分支bug。
分支依赖冲突
多分支开发在项目中，总是会出现大大小小，多多少少的依赖冲突，面对这样的问题，其实也没有好的办法，只能说经验，来少走些湾路。 1.如果a功能与b功能属于弱依赖，两个功能同步开发。开发完后，合并提测 2.如果a功能与b功能属于强依赖，还是建议同分支开发。
