RJ.*_*RJ. 13 .net c# asp.net tfs
我在一组4个.Net开发人员中工作.我们很少同时在同一个项目上工作,但它确实不时发生.我们使用TFS进行源代码控制.我最近的一个例子是我昨晚刚刚投入生产的一个项目,其中包括2个WCF服务和一个Web应用程序前端.我在一个名为"prod"的分支机构工作,因为该应用程序是全新的,从未见过光明的一天.现在该项目已经上线,我需要分支prod分支的功能,错误等...
那么最好的方法是什么？
我是否可以简单地创建一个新分支并对旧分支进行归档,而不再使用它？
当我想部署到生产环境时,是否会分支,然后将我的分支更改合并回prod分支？
那么文件和汇编版本呢？他们目前在1.0.0.0.他们什么时候改变,为什么？如果我修复了一个小bug,那么哪个数字会改变？如果我添加一个功能,哪个数字会发生变化？
我所寻找的是您发现的有效管理源代码控制的最佳方式.我工作过的大多数地方似乎总是与源控制系统在一起或其他地方爆炸,我只想找出你发现的效果最好的地方.
Pét*_*rök 11
最好有一个单独的分支来支持每个已发布的版本,另一个用于继续开发.这样,您可以始终为旧版本生成错误修复版本,而不依赖于您在主分支上处理的新功能.
从长远来看,最好将主分支保留为开发分支,并为每个特定版本创建单独的支持分支; 这样可以缩短分支路径.(我参与了一个项目,其中实际工作分支的路径就像main/release_1.0/release_1.1/release_1.5/release_2.0/release_2.1......你不想走那条路:-)
当然,您需要定期将支持分支上的任何修复程序合并回主分支 - 至少在创建下一个版本之前.我的经验是,绝对不建议将合并留到最后一分钟 - 合并的时间越晚,两个分支之间的差异越大,因此遇到麻烦的机会就越大.如果合并更改的复杂性超过某个阈值,自动合并工具就会放弃......并且手合并并不好玩.
版本控制在很大程度上可以是个人偏好的问题.在一个小项目中,您可能对major.minor版本方案感到满意,在较大的项目中,您可能希望使用补丁和/或构建版本号进行更精细的控制.
您需要制定版本策略然后坚持下去.例如,如果您使用major.minor版本方案,请增加bugfix版本的次要版本,以及新功能版本的主要版本.
| 归档时间： |
|
| 查看次数： |
367 次 |
| 最近记录： |