Git版本控制

此文档本地目录：E:github

自己搭建git远程服务器，而且远程服务器就在本地。具体搭建过程可以网搜《Gitblit搭建及Git协作开发流程》，此文档已经保存在gitblit安装目录下。然后上传初始项目代码至服务器。(上传步骤：在gitlit服务器浏览器界面上，新建版本库，然后在本地命令行remote add就可以了，具体实现参照参考文档)。

下面着重介绍如何应用：

1. 从服务器新建本地分支

git clone –single-branch -b ZFcon ssh://xielg@127.0.0.1:29418/PIC_ASM/Controller.git

其中—single-branch是只复制单个分支；-b 指定服务器上的分支名字；ssh://xielg@...则表示服务器地址；

1. 提交代码

git push origin Develop:ZFcon

其中Develop为本地分支名字；ZFcon为远程分支名。

1. 分支管理

   分支管理策略参考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功能)

   下面结合实际情况：

   1. 新建立项目，在Develop分支上进行开发。功能完成后，提交给测试，此时建立Release-X.Y.Z其中X.Y为下一个需要发布的分支(也是master需要tag的的标签号)；Z代表可能提交多轮测试才能发布，每次提交测试，Z递增。测试完成，Release合并至Develop，Develop合并至master，master打标签，软件归档。编写产品说明书文档，整理开发心得。
   2. 客户现场反馈bug，新建Hotfix-X.Y，其中X.Y是当前发生bug的标签号。修改bug-提交测试-合并至Develop-if需要立即更新生产-Develop合并至master-软件归档，更新说明书，整理开发心得。
   3. 客户现场增加需求，新建Feature-X.Y，其中X.Y是当前已经发布的标签号。新增功能-提交测试-合并至Develop-if需要立即更新生产-Develop合并至master-软件归档，更新说明书，整理开发心得。
   4. 两个实际产品共用一个代码(或者只是稍微修改)，新建Dev-*和mst-*，分别对应于Develop和master，*为新产品名称。
   5. 其他规定：
      1. 分支命名：首字母均大写(除了master，master是系统名称，不能大写)。
      2. 标签号命名：VX.Y其中X.Y为主次版本号。两个产品共用工程时，新增加的分支为VX.Y-*。
      3. 提交测试必须先提交。
2. 问题
   1. 出现"Gitblit does not allow pushes to "Controller" because it has a working copy"

   

   解决：

3. 难点

   修改共性bug，如何将所有有关联的bug一起修改。

   1. 远程分支对应于一个产品，所有远程分支有个基线分支master，如果共享bug修改了，则将其合并至master。然后所有远程分支 rebase master，但是如果两个分支不同的地方太多了，会导致每次rebase难度都挺大。
   2. 现在采用的。远程分支对应于框架。不同产品的不同在本地体现，缺点：无法知道各个产品之间的联系，即A分支无法确定B分支与自己是否有共同远程分支。
   3. 或者脑洞开大点：远程分支Y（对应于产品）,远程分支Y又有上一级远程YP（对应框架），产品的公共bug在本地修改好后，提交至远程Y，然后Y提交至YP，其他远程分支从YP上pull，然后进行修改。(这点适合于大公司有专门的的人进行版本管理)