在对一个现成的CMS系统增加和修改了多个功能后,遂渐意识到使用版本管理软件的分支功能进行新功能和原型的开发是非常必要的。
若不使用分支,新功能或试验性的代码便和主干代码混杂在一起,造成主干代码不“干净”。
这个时候就是麻烦的开始,只要新功能未开发完成,就一直不敢上传任何代码,就算是修复其它功能的bug后上传个别文件也是胆战心惊的。
加上新功能的开发延期是常有的事,整个开发就被新功能牵制住,无法灵活调整。
使用分支功能,则可以把新功能或原型放在分支上进行开发,什么时候开发完什么时候合并,开发时不会对主干造成影响。
这样主干就可以进行修复现有bug,上传等正常的更新和维护操作。
我使用过的两个版本管理工具SVN和Git都支持分支,Git的分支功能比SVN要好,所以打算使用Git的分支功能。
不过团队原本的版本管理使用的是SVN,而且SVN的权限管理比Git要好,SVN在Windows下的安装和配置也比Git要容易,所以不打算完全转到Git上,只是使用Git的分支功能帮助开发新功能和原型。
具体做法是:
首先,原本使用SVN管理的目录称为“SVN主目录”,准备新建立的Git管理的目录称为“Git主目录”,两个目录是互相独立的,所使用的数据库也互相独立。
在SVN主目录中增加Git的管理,git master分支跟SVN最新版本一致。
Git主目录中 master分支与SVN主目录中的git master分支进行同步。
Git主目录中的其它分支就是各功能或原型的开发分支。
Git主目录中其它分支跟master合并完成后,推送到SVN主目录中的Git的dev分支中。
在SVN主目录中对Git的dev和master分支合并后,提交上SVN。
不同开发人员Git主目录分支间的同步通过Git主目录直接进行。
这个过程中,Git主目录只与SVN主目录中的git进行同步,不同开发人员分支开发进度的同步直接使用Git主目录完成(不经SVN),直至分支开发完成,合并入master(相当于主干)后,再提交上SVN。
这个方法的优点是:通过Git强大的分支功能实现主干和分支的并行维护与开发。
这个方法的缺点是:分支最后的合并和同步到SVN的操作有点麻烦,并且SVN中没有分支开发过程中的提交记录。
若不使用分支,新功能或试验性的代码便和主干代码混杂在一起,造成主干代码不“干净”。
这个时候就是麻烦的开始,只要新功能未开发完成,就一直不敢上传任何代码,就算是修复其它功能的bug后上传个别文件也是胆战心惊的。
加上新功能的开发延期是常有的事,整个开发就被新功能牵制住,无法灵活调整。
使用分支功能,则可以把新功能或原型放在分支上进行开发,什么时候开发完什么时候合并,开发时不会对主干造成影响。
这样主干就可以进行修复现有bug,上传等正常的更新和维护操作。
我使用过的两个版本管理工具SVN和Git都支持分支,Git的分支功能比SVN要好,所以打算使用Git的分支功能。
不过团队原本的版本管理使用的是SVN,而且SVN的权限管理比Git要好,SVN在Windows下的安装和配置也比Git要容易,所以不打算完全转到Git上,只是使用Git的分支功能帮助开发新功能和原型。
具体做法是:
首先,原本使用SVN管理的目录称为“SVN主目录”,准备新建立的Git管理的目录称为“Git主目录”,两个目录是互相独立的,所使用的数据库也互相独立。
在SVN主目录中增加Git的管理,git master分支跟SVN最新版本一致。
Git主目录中 master分支与SVN主目录中的git master分支进行同步。
Git主目录中的其它分支就是各功能或原型的开发分支。
Git主目录中其它分支跟master合并完成后,推送到SVN主目录中的Git的dev分支中。
在SVN主目录中对Git的dev和master分支合并后,提交上SVN。
不同开发人员Git主目录分支间的同步通过Git主目录直接进行。
这个过程中,Git主目录只与SVN主目录中的git进行同步,不同开发人员分支开发进度的同步直接使用Git主目录完成(不经SVN),直至分支开发完成,合并入master(相当于主干)后,再提交上SVN。
这个方法的优点是:通过Git强大的分支功能实现主干和分支的并行维护与开发。
这个方法的缺点是:分支最后的合并和同步到SVN的操作有点麻烦,并且SVN中没有分支开发过程中的提交记录。