Git版本控制
此文档本地目录：E:\github
自己搭建git远程服务器，而且远程服务器就在本地。具体搭建过程可以网搜《Gitblit搭建及Git协作开发流程》，此文档已经保存在gitblit安装目录下。然后上传初始项目代码至服务器。(上传步骤：在gitlit服务器浏览器界面上，新建版本库，然后在本地命令行remote add就可以了，具体实现参照参考文档)。
下面着重介绍如何应用：
- 从服务器新建本地分支
git clone –single-branch -b ZFcon ssh://xielg@127.0.0.1:29418/PIC_ASM/Controller.git |
其中—single-branch是只复制单个分支；-b 指定服务器上的分支名字；ssh://xielg@...则表示服务器地址；
- 提交代码
git push origin Develop:ZFcon |
其中Develop为本地分支名字；ZFcon为远程分支名。
- 分支管理
分支管理策略参考http://www.oschina.net/translate/a-successful-git-branching-model ，总结参考为：
2个永久分支：master和Develop。master分支的每一次提交都意味着生产新生产。
3个临时分支：Hotfxi-*、Release-*和Feature。Hotfix-*为修复bug分支，*为版本号；Release-*为预发布分支(对应于发布前提交给测试) ；Feature分支为开发新功能(最终要合并至Develop，例如在Develop上同时开发A和B功能)
下面结合实际情况：
- 新建立项目，在Develop分支上进行开发。功能完成后，提交给测试，此时建立Release-X.Y.Z其中X.Y为下一个需要发布的分支(也是master需要tag的的标签号)；Z代表可能提交多轮测试才能发布，每次提交测试，Z递增。测试完成，Release合并至Develop，Develop合并至master，master打标签，软件归档。编写产品说明书文档，整理开发心得。
- 客户现场反馈bug，新建Hotfix-X.Y，其中X.Y是当前发生bug的标签号。修改bug-提交测试-合并至Develop-if需要立即更新生产-Develop合并至master-软件归档，更新说明书，整理开发心得。
- 客户现场增加需求，新建Feature-X.Y，其中X.Y是当前已经发布的标签号。新增功能-提交测试-合并至Develop-if需要立即更新生产-Develop合并至master-软件归档，更新说明书，整理开发心得。
- 两个实际产品共用一个代码(或者只是稍微修改)，新建Dev-*和mst-*，分别对应于Develop和master，*为新产品名称。
- 其他规定：
- 分支命名：首字母均大写(除了master，master是系统名称，不能大写)。
- 标签号命名：VX.Y其中X.Y为主次版本号。两个产品共用工程时，新增加的分支为VX.Y-*。
- 提交测试必须先提交。
- 问题
- 出现"Gitblit does not allow pushes to "Controller" because it has a working copy"
解决：
- 难点
修改共性bug，如何将所有有关联的bug一起修改。
- 远程分支对应于一个产品，所有远程分支有个基线分支master，如果共享bug修改了，则将其合并至master。然后所有远程分支 rebase master，但是如果两个分支不同的地方太多了，会导致每次rebase难度都挺大。
- 现在采用的。远程分支对应于框架。不同产品的不同在本地体现，缺点：无法知道各个产品之间的联系，即A分支无法确定B分支与自己是否有共同远程分支。
- 或者脑洞开大点：远程分支Y（对应于产品）,远程分支Y又有上一级远程YP（对应框架），产品的公共bug在本地修改好后，提交至远程Y，然后Y提交至YP，其他远程分支从YP上pull，然后进行修改。(这点适合于大公司有专门的的人进行版本管理)
