首选版本控制方法

我是源/版本控制领域的新手,我一直在做尽可能多的阅读,以便了解人们用于自己的源/版本控制的不同技术.

我注意到的一件事是,开发人员的方法在两个(可能更多？)组中有一个非常明显的突破:一组更喜欢将其主干保持在一个始终稳定的状态,并在分支中执行所有维护和未来的开发,同时其他人更喜欢在后备箱中进行所有开发,并使其保持在不太稳定的状态.

我很好奇StackOverflow的社区更喜欢什么,或者你有自己的方法.

注意:如果它有助于定制答案,我应该注意到我是一个单独的开发人员(在同一个项目中最多会有两三个人)主要在ASP.NET和SQL Server 2005中工作

我确信你已经注意到在网上搜索关于这个主题的答案,这是最好的答案是"它取决于"的事情之一,并且正如大多数回复所表明的,这是一个权衡您希望能够提交/合并新代码与管理广泛版本历史记录之间的容易程度,您可以轻松回滚以进行支持或调试.

我在一家小公司工作,这意味着在任何给定时间,我们可以在尚未提交到存储库的开发人员计算机上拥有3或4个不同版本的代码.我们使用TortoiseSVN作为我们的版本控制系统,这使我们能够毫不费力地进行分支/合并,并且能够非常容易地查看更新日志或将本地副本还原到早期版本.

基于你的问题,我想我们会属于那些试图在任何时候都保持稳定Trunk的开发人员群体,我们分支新代码并在将其合并回Trunk之前对其进行测试.我们还努力保留每个版本的"快照",以便在必要时我们可以轻松查看早期版本并重新构建它,而无需为将来的版本添加任何新功能(这也很棒)跟踪错误的机制,因为您可以使用早期版本的代码来帮助确定特定错误何时首次引入代码.但是,有一点需要注意的是,如果您的应用程序引用与您的版本分开维护的公共代码代码,你也需要跟踪它!).

在存储库上,它最终看起来像这样:

树干

v1.0.1.x发布

v1.0.2.x发布

v1.0.2.x Bug-Fix A < - (这些被合并回Trunk,但保留在repo上)

v1.0.2.x错误修复B.

v1.1.1.x发布

v1.2.1.x开发< - (这将合并回Trunk,并替换为Release文件夹)

v1.2.1.x新功能A < - (这些将合并回开发分支)

v1.2.1.x新功能B.

当我刚开始在公司工作时,我们的版本结构并不那么复杂,根据我的经验,我会说,如果你有任何需要跟踪早期版本的话,那么这样做是值得的.在一起(就像我之前所说,它不一定非常像这样,只要它符合您的个人需求),保持良好的文档记录,以便所有贡献者都可以维护它(替代方案是创建者最终"保姆" "回购,很快就会浪费时间,并鼓励所有开发人员遵循它.一开始可能感觉很费劲,但是第一次需要利用它时你会很感激.

祝好运!

我在后备箱中完成所有开发工作.我是一个单一的开发人员,不想处理分支的麻烦.当我的代码稳定时,我只标记当前版本.例如,我标记版本1.0,2.0 beta,2.0版本候选版本1,版本2.0等.如果您维护旧版本的错误修复和支持,分支可能是更好的选择但是因为我不这样做我不喜欢不用担心.