我应该多久对源代码管理进行一次更改？每个小功能之后,还是仅适用于大型功能？
我正在开展一个项目,并有一个长期的功能来实现.目前,我正在承诺每一部分工作,即每个子功能实现和错误修复.在发现错误后我为某些功能添加了一大块测试之后,我甚至做出了承诺.
但是,我很担心这种模式.在一个富有成效的工作日里,我可能会做出10次提交.鉴于我正在使用Subversion,这些提交会影响整个存储库,所以我想知道这么多确实是一个好习惯吗？
Chr*_*ann 190
任何时候我完成编译和运行代码的"完整思考",我办理登机手续.这通常最终会在15-60分钟之间.有时它可能会更长,但我总是试图检查我是否有很多代码更改,我不想在失败的情况下重写.我通常还会确保我的代码编译,并在我回家之前的工作日结束时办理登机手续.
我不担心做"太多"提交/签到.当你必须重写某些内容时,它真的很糟糕,为了以防万一,能够以小的增量回滚是很好的.
ben*_*ado 80
当你说你担心你的"提交影响整个存储库"时 - 你指的是整个存储库的版本号增加的事实吗？我不知道Subversion使用多少位来存储它,但我很确定你不会用完修订号! 许多提交都不是问题. 你可以比隔壁的家伙多十次,你根本不会增加你的碳足迹.
应该为它的功能命名一个函数或方法,如果名称太长,它就会做得太多.我尝试将相同的规则应用于签到:签到注释应该准确描述更改完成的内容,如果注释太长,我可能会立即改变太多.
pax*_*blo 11
我遵循开源咒语(释义) - 提前提交,经常提交.
基本上每当我认为我添加了有用的功能(无论多小)而没有为其他团队成员引入问题时.
这种提交常用策略在持续集成环境中特别有用,因为它允许针对其他开发工作进行集成测试,从而及早发现问题.
Kev*_*ner 10
不要提交实际上不起作用的代码.不要将您的存储库用作备份解决方案.
相反,请以自动方式在本地备份不完整的代码.Time Machine照顾我,有很多免费程序可供其他平台使用.
我使用的经验法则是签入的文件组可以通过单个签到注释覆盖时签到.
这通常是为了确保签到是原子的,并且评论可以被其他开发人员轻松消化.
当您的更改影响具有应用程序范围的配置文件(例如spring上下文文件或struts配置文件)时尤其如此.如果在签入之前进行了多个"组"更改,则它们的影响会在配置文件中重叠,从而导致两个组相互合并.
我认为你不应该经常这么担心.这里重要的是什么,何时以及为什么.说你必须每3小时或每24小时提交一次真的没有意义.如果你有事情需要提交,请不要.
以下是我推荐的版本控制最佳实践的摘录:
[...]如果您同时对项目进行了许多更改,请将它们拆分为逻辑部分并在多个会话中提交它们.这使得跟踪单个更改的历史记录变得更加容易,这将在以后尝试查找和修复错误时节省大量时间.例如,如果要实现功能A,B和C并修复错误1,2和3,则应该总共至少提交六次提交,每个功能一个,每个错误一个.如果您正在处理大型功能或进行大量重构,请考虑将您的工作分成更小的部分,并在每个部分完成后进行提交.此外,在对多个逻辑模块实施独立更改时,请分别对每个模块提交更改,即使它们是更大更改的一部分.
理想情况下,您永远不应该让您的办公室在硬盘上进行未提交的更改.如果您正在处理更改会影响其他人的项目,请考虑使用分支来实现更改,并在完成后将它们合并回主干.当提交对其他项目(以及其他人依赖)的库或项目的更改时,请确保不通过提交无法编译的代码来中断其构建.但是,拥有不编译的代码并不是避免提交的借口.改为使用分支.[...]
你当前的模式是有道理的.请记住如何使用此源代码控件:如果必须回滚,或者如果要进行差异,该怎么办？在这些情况下,您描述的块看起来恰好是正确的差异:差异将显示您在实现bug#(在签入日志中指定)中确切改变了什么,或者确切地说新代码用于实现功能的内容.类似地,回滚一次只能触摸一件事.
在完成一大堆工作后,我也想承诺,这通常是一天几次.我认为在小型提交中比在大型提交中看到的更容易.如果您担心过多的提交,可以考虑创建一个分支,并在整个功能完成后将其合并回主干.
这是一篇相关的博客文章:编码恐怖:提前入住,经常入住
正如其他人所说，尝试提交一个足够“完整”的逻辑块，以免妨碍其他开发人员（例如，它构建并通过自动化测试）。
每个开发团队/公司必须为每个分支定义什么是“足够完整”的。例如，您可能有仅需要代码才能构建的功能分支，也需要代码才能通过自动化测试的主干，以及指示某些内容已通过 QA 测试的标签......或类似的内容。
我并不是说这是一个值得遵循的好模式；我并不是说这是一个值得遵循的模式。我只是指出，如何“完成”取决于您的团队/公司的政策。
| 归档时间： |
|
| 查看次数： |
27890 次 |
| 最近记录： |