svn提交代码的时间是什么时候？

[HeBanBei]

svn提交代码的时间是什么时候？

1、每天下班之前提交，不管代码写没写完，不管存在多少明知的bug

2、经自己测试后的代码。如果没有完成或明知存在bug，则不提交。

[ckc]

提交上去的版本应该是阶段性版本， 通常应该测试通过，至少至少也要让同事可以用这些代码调试他自己的那一部分，就是说对外的接口至少是正确的。 项目组人数少的话可以提交频繁些，不过无论如何也不至于10多分钟就提交一次。 晚上下班的时候如果还有较多bug可以不用提交。 另外，这些东西不同的实际情况是应该灵活掌握的

[tzxx]

引用 1 楼 sp1234 的回复:

通常每隔10几分钟就可以提交。但是提交，一定要至少编译过。最好是运行最近3天的单元测试通过之后。 注意，一定要经常提交。那种1个小时才提交一次，说明编程人出问题了。

在我看来1个小时提交一次都算快的了，我认为不应该以时间长短来决定是否提交，还是要考虑功能的完整性或者说可用性。毕竟SVN除了保存代码的功能，对修改履历的记录以及之前版本的回溯功能更有价值一些。

[tzxx]

引用 楼主 HeBanBei 的回复:

svn提交代码的时间是什么时候？ 1、每天下班之前提交，不管代码写没写完，不管存在多少明知的bug 2、经自己测试后的代码。如果没有完成或明知存在bug，则不提交。

说一下我们目前的做法，虽然使用的是TFS，但是道理都一样。 1，是否提交代码与下不下班无关，如果代码没有写完可能不能上传，如果成员希望将代码保存到服务器上，以避免本地机器出现异常造成代码丢失，那么至少要保证编译能通过，且上传的功能部分不应影响到其他成员的开发。 2，修改履历的注释应当描述这一次提交所作的内容，比较添加了什么功能，修改了什么功能，解决了什么BUG等等，有一定的阶段性最好。添加注释的好处很多，当有必要回溯版本时，可以用来区分应该回溯到何时，当对以前的某处代码感到困惑，不明白为何做那样的处理时，可以查找到那一次编辑的履历，通过当时的注释来帮助理解当时修改的用意（这个场景在工作中遇到过多次，会很庆幸当时写了注释）。

[勤奋的小游侠]

说一下我自己的经验： 1代码首先编译通过是没有问题的 2该模块的代码基本是完成了的 满足这两点就马上传吧。 如果上面这二点没有完成，比如要搞一二天的任务，至少要保证第一点，然后也可以上传。 如果编译都通不过，或者未完成的模块会影响到其它的同事，那不管下不下班都不要上传。 只要不影响其它人的工作，做完什么就要上传什么。 如果自己的递交会影响到别人，那就要测试妥了再上传。别传一些大 bug上去让别人来帮你找。 最开始参加工作的人可能会有这种心理吧，经理报置了个任务，写了几天只完成了一半，东西上传好还是不传好？ 上传吧，东西还没有做完，可能连编译都有问题，不传吧，领导想看你的工作进度都看不了，别人看你几天没一句代码传上来，也不知道你会做不做。 这种情况，坚决要上传，你做错没关系，你是新人嘛，领导会原谅你的，说不定通过复查你的代码还能给你点提示。但是，你几天一句代码都没有，领导就有点怀疑是不是要换一个人来做了。

[gzg9002]

恩恩，膜拜大神

[HuangXi]

1. 代码经过测试后 2.提交前要先update

[shinerise]

引用 7 楼 HeBanBei 的回复:

[quote=引用 5 楼 sp1234 的回复:] [quote=引用 3 楼 HeBanBei 的回复:] 2、svn上会有很多不同时间提交的版本，以后要查找也很难找到某一个版本了。

不懂这是什么意思。既然你凭脑子机主某一个版本，还要svn干什么呢？ svn就是要能够保证随时可以回滚。如果你画画，那么每一次不确定要不要回滚的时间节点（比如说画了一个人的一条眉毛的主干部分、接下来开始修饰眉毛的尾部了），你都要提交一次。这就是svn提交的目的。 什么“每一次都要写一段文字说明”，什么“要用脑子记住总共有多少版本”，你要是有心情这样做可以做，但是没有心情就应该毅然扔掉。因为根本目的更重要。[/quote] 如果不写说明，那么如何知道哪个版本都做了哪些修改？ 比如，我想要退回到一个月前的某几天的某一个版本。可是svn上一个月前的某几天有好多次提交，而且都没有写说明。那么我怎么知道哪次提交的代码是我想要的？[/quote] 我的习惯是第一次系统测试之前是不管版本的。第一个版本发布后就纳入版本发布计划，此时代码就不允许随便修改了。这之后每一次提交都要有明确的SVN提交记录。而第一个版本之前，是不管SVN的提交记录的。

[shusong1228]

1代码首先编译通过是没有问题的 2该模块的代码基本是完成了的

[Xu_Chong_521]

只要 编译通过 就可以提交 每天下班前最好提交一次 如果电脑出现问题 在修复电脑的过程代码可能不存在

[lees889]

应该是在做了修改，或者完成某个功能，且测试通过之后提交

[dgkjly]

[lizhenlzlz]

这个还是要分析下，那种更方便的管理

[super_admi]

我可以说说我的做法，但是不是适合你，我不清楚。 1.我们团队里有共用的SVN服务器，并不限制你什么时候提交代码，但提交的时候，确实是要写清楚做了哪些修改。实际上，我们在提交的时候，都比较谨慎，回滚操作非常少； 2.我在自己的机器上，建立了一个SVN服务器，在虚拟机中搭建客户环境，然后写代码。此SVN仅供我自己使用，提交次数很频繁，基本上，只要是定型的代码，立马提交（比如，刚创建好框架，提交；写好一个小模块，提交……），回滚次数也很频繁（主要是Reset到上一次提交），因为我很多时候写着写着，就会随着思考，加入了很多尝试性的代码和测试性的代码，会很乱，到最后我自己都不知道自己完成了些什么，这个时候，我就会把自己能够确定的代码复制到一个临时文件里面，然后对原有项目进行回滚。 在项目实现阶段，我只有完成一个阶段性任务，才会向共用SVN提交代码；在项目测试阶段，每修改一批BUG，我会向公共SVN提交代码。

[铁匠梁]

提交的代码都是自己测试过没有问题的 否则版本出来有什么用

[幻夢之葉]

看你什么样子的项目 就我个人来说： 1.修复Bug或者优化，一般都是做完一个提交一次 2.如果是新功能就宽松点，你可以按照自己想法来提交（比如大体框架做好了，一批关联的功能实现了或者其他等等） 我不赞同一楼的看法，有些偏激。 个人觉得提交的间隔不应该按时间性而应该按照你代码变化（是不是有功能增加，修改，提升等） 比如我有时候一天两天提交一次，有时一个小时内提交多次 还有其他回复说到的：你代码必须能编译过，并且你代码没有明知道的致命缺陷的情况下才提交代码

[gemo]

频繁提交是程序员应该具有的修养，但现在起码国内是没人重视这个 原因：提交的时机理论上是完成一个模块并自测通过。至于这个模块的粒度，自己把握。但我往往倾向于分的细一点，这样每次提交前可以方便地对比这次改动过的所有代码。如果积攒了太多改动再提交，则不好比较了。据我的观察，这样至少可以减少30%的bug。

[wangafei1988]

其实要看你是设么方向的，最好是一个模块提交一次，如果是正在使用的分支则要慎重提交，研发分支则可以提交频繁

[houhualiang]

以前我也是基本一天提交一次，一个人开发，只是为了代码的安全，但是最后我发现有很多的问题，最后就改成完成一个小的模块就提交，基本一个小时提交几次： 你的操作 提交的时候往往会写你修改了哪些内容，有时候一天的时候会修改很多内容，然后写提交日志的时候就会只写你修改的大模块的地方的功能修改，然而你可能修改了另一个模块的某个Button的样式XML，然后提交。 出现的问题：当某一天你想看看这个样式的时候，你会发现这个样式表的某个版本修改的日志竟然是完全不想关的日志，XML还好，如果要是你重构了某个JAVA中的大量代码，然而你的日志完全没用，你就会觉得这个SVN是啥J8玩意，其实完成一点提交 ，写日志确实对以后维护有好处。个人看法

[苏生米沿]

看项目来吧。如果是大项目合作的话，肯定是提交没有bug的，如果是自己接私活，那么最好下班前提交一下了。

[庄鱼]

以完整的class或template为单位提交，也就是说，提交到公共区的一定是可以被直接使用的东西，如果发现之前的版本有问题，不建议直接修改BUG提交修正版，而是重新命名一个新的名字并附注修改原因及版本差异性再提交。 越是大的项目月是不能够对已提交的代码进行更改，因为你不能确定是不是已经有人在使用你的代码，也许他已经发现提交的代码中存在的问题并已采取了措施，或者，他发现了你的代码的副作用但是可以帮他解决他的问题，他要的就是你的'BUG'，你频繁更改你的代码，或是直接修正你的BUG都有可能给别人带来大麻烦。正确的做法是在原有的代码包中加时间戳，由使用者决定采用哪一个版本。 对于新人，可以申请一个tmp区或test区，对对独立的代码、函数放在这里，也便于资深人员修改指正。由于通常tmp或test区用来存放不确定或有问题的代码，对项目组其他人员来说，也是借以拓展思路的讨论区，可以将自己的问题、想法附议上去，寻求大家帮助，同时也可以借鉴别人的做法解决自己的问题。 由于提交的东西是不可更改的，这也就保证了所有的行为都是有痕迹的，都能找到源头，因此绝不会出现恶心代码或恶心数据。这样项目才有可能是安全的。只有在大的项目版本调整时，才对已用代码或数据进行整理，甄别差异部分，剔除无用部分整合成全新代码包给新客户，对老客户只要其运行正常就不要提版本更新或升级。