事情的起因是笔者正在做的项目，是一个小团队，团队成员不到5人，且项目处于第一个生产版本的创建过程中，为没有合适的Git模型而犹豫了很久，最终确定的模型和最初的也有不同。特此记录，主要是为了个人总结，也便于读者阅读。
首先基于对大型开源项目的认知，笔者首先确定了多分支作为项目管理的支柱，因为在大型开源项目中，多分支的运用可谓是随处可见。但是此处笔者忽略了一个问题，多分支管理的基础内容已经形成了，且担心众多来路不明的开发者进行合并造成项目的问题。且多分支机制主要用于对现有的某个功能进行替代。
在此基础上，笔者决定远程使用单一分支，本地使用双分支，即个人的工作分支和远程dev分支对应的本地分支dev。这种双分支结构的好处就是可以很好的划分个人的工作和远程的工作，但是在实际应用中就会发现，每次进行小的修改之后都需要重新删除分支并创建新分支，而且双分支会造成操作上的问题。
最终笔者和团队成员一起确认了单本地分支和单远程分支的模型，单本地分支不允许项目成员先合并再拉取，必须坚持先拉取，再本地commit，再推送的过程，这既是将冲突解决的责任放在后一个人身上，也可以很好的实现将时间上的并行工作转化为串行工作，即先推送到远程的人拥有逻辑上的优先顺序。
这种流程的问题是对于一个比较大的需求，可能需要开发很久，以往笔者的做法是将其拆分成多个小任务然后分别提交一堆git commit，但这种操作对于协作项目是错误的，因为git本身并不是保存历史版本的工具，对于这些没有实现这个需求的commit，也不便于回退和测试。因此采用现在的工作流是正确的，也是将Git从管理历史版本的网盘工具变成了真正的结合软件工程的项目管理工具。