我正在谷歌搜索一下,找不到一个好的"初学者" SVN指南,而不是"我如何使用命令"的意思; 如何控制源代码？
我想澄清的是以下主题:
你多久犯一次？人们经常按Ctrl+ s？
什么是分支,什么是标签,你如何控制它们？
什么进入SVN？只有源代码或者你在这里分享其他文件吗？(不考虑版本化文件..)
我不知道什么是分支和标签,所以我不知道目的,但我的猜测是你把东西上传到主干,当你做一个主要的构建时,你将它移动到分支？那么,在这种情况下,什么被认为是主要的构建？
当我们在这里实施Subversion时,我问自己同样的问题 - 大约20个开发人员分布在4-6个项目中.我没有找到任何一个有"答案"的好消息来源.以下是我们的答案在过去3年中如何发展的一些部分:
- 尽可能经常地提交; 我们的经验法则是,只要您完成了足够的工作就会提交,如果修改丢失,则必须重新执行此操作; 有时我每15分钟左右一次,有时候可能是几天(是的,有时我需要一天写一行代码)
- 我们使用分支,作为您之前建议的答案之一,用于不同的开发路径; 现在,对于我们的一个程序,我们有3个活动分支:1个用于主要开发,1个用于尚未完成的并行化程序,1个用于修改它以使用XML输入和输出文件;
- 我们几乎不使用标签,但我们认为我们应该使用标签来识别生产中的标签;
想想沿着一条道路前进的发展.在开发营销的某个时间或状态决定发布产品的第一个版本,因此您在标记为"1"(或"1.0"或您拥有的)的路径中设置标记.在某些其他时间,一些明亮的火花决定将程序并行化,但决定这需要数周时间,并且人们希望在此期间继续沿着主要道路走下去.所以你在路径上建立一个分叉,不同的人在不同的叉子上徘徊.
道路上的旗帜称为"标签",道路上的叉子是"分支"划分的地方.有时,分支也会一起回来.
- 我们将构建可执行文件(或系统)所需的所有材料放入存储库; 这至少意味着源代码和make文件(或Visual Studio的项目文件).但是当我们有图标和配置文件以及所有其他东西时,它会进入存储库.一些文档进入了回购路径; 当然,任何文档,例如可能是程序不可或缺的帮助文件,都是放置开发人员文档的有用位置.
我们甚至为我们的生产版本提供Windows可执行文件,为寻找软件的人提供单一位置 - 我们的Linux版本转到服务器,因此不需要存储.
- 我们不要求存储库始终能够提供构建和执行的最新版本; 有些项目是这样工作的,有些则没有; 该决定取决于项目经理,并取决于许多因素,但我认为在对程序进行重大更改时会出现故障.
该颠覆的书是关于战略的信息布局资源库,分支和标记的极好来源.
也可以看看:
您是继续在分支机构还是在主干中进行开发
分支策略
* How often do you commit? As often as one would press ctrl + s?
尽可能经常地.代码不存在,除非它在源代码管理下:)
频繁提交(此后较小的更改集)允许您轻松集成您的更改并增加不破坏某些内容的机会.
其他人注意到,当你有一段功能代码时你应该提交,但是我发现稍微提交一些代码很有用.很少有人注意到我使用源代码控制作为快速撤消/重做机制.
当我在自己的分支上工作时,我更愿意尽可能多地提交(就像我按ctrl + s一样).
* What is a Branch and what is a Tag and how do you control them?
阅读SVN书 - 这是学习SVN时应该开始的地方:
什么是分支？
标签
* What goes into the SVN?
文档,构建所需的小二进制文件以及其他具有一定价值的东西都可以用于源代码控制.
以下是有关提交频率,提交消息,项目结构,源代码管理内容以及其他一般准则的一些资源:
版本控制的最佳实践(我自己的博客)
提前入住,经常入住(编码恐怖片)(这里的评论包含很多好建议)
KDE的提交政策
这些Stack Overflow问题还包含一些可能感兴趣的有用信息:
混合两种或多种语言(如Java和C++)时组织源代码库
建议好的提交消息:格式/指南？
多久提交一次源代码管理更改？
学习版本控制,并学习它
关于基本的Subversion概念,如分支和标记,我认为这在Subversion书中得到了很好的解释.
正如您在阅读了有关该主题的更多内容后可能会意识到的那样,人们对该领域最佳实践的看法往往是变化的,有时甚至是相互矛盾的.我认为最适合您的方法是阅读其他人正在做的事情,并选择您认为对您最有意义的指导方针和做法.
如果你不了解它的目的或不同意其背后的理由,我认为采用一种做法并不是一个好主意.因此,不要盲目地遵循任何建议,而是要对自己认为最适合自己的事情做出自己的想法.此外,尝试不同的做事方式是学习和了解你最喜欢工作方式的好方法.一个很好的例子就是你如何构建存储库.没有正确或错误的方法,在实际尝试之前,通常很难知道您喜欢哪种方式.
提交频率取决于您的项目管理风格.许多人如果破坏了构建(或功能),就不会做出承诺.
分支可以以两种方式之一使用,通常:1)一个用于开发的活动分支(并且主干保持稳定),或2)用于备用dev路径的分支.
标签通常用于识别版本,因此它们不会在混合中丢失.'发布'的定义取决于您.
我认为主要问题是源控制的心理图像是混淆的.我们通常有主干和分支,但是后来我们得到了关于标签/发布的不相关的想法或者那些影响.
如果你更完全地使用树的想法,它会变得更清晰,至少对我来说是这样.
我们得到主干 - >表格分支 - >生产水果(标签/发布).
这个想法是你从一个主干增长项目,然后在主干足够稳定以保持分支时创建分支.然后当分支产生一个水果时,你从分支中取出它并将其作为标记释放.
标签本质上是可交付成果.而树干和树枝则产生它们.
京公网安备 11010802040832号 | 京ICP备19059560号-6 