it-swarm.cn

签入源代码之前有哪些好的做法?

我的团队使用Team Foundation Server进行源代码控制,今天我在签入之前修复了一些错误和冒烟测试应用程序,但是我忘了注释一些代码。 (此代码使UI有点奇怪。)

我想在签入代码之前先知道有什么好的做法-我不想再犯这种错误。

47
Anonymous

我习惯做的一件事就是总是在即将我检入文件之前查看我要检入的每个文件的差异。

149
crudcore

您永远不要签入注释掉的代码。如果您有需要在签入之前注释掉的代码,那么您做错了。

至于规则:

  1. 取得最新
  2. 修复合并冲突
  3. 建立

    3.1修复构建错误

  4. 运行测试

    4.1修复损坏的测试

  5. 转到1(直到没有新内容为止)

仅在所有步骤完成后才能签到。

参见 签到舞蹈


其他良好做法:

  • 查看要检入的文件列表,以确保它们是预期的文件。
  • 查看每个文件的更改(删除/添加/差异)
63
Oded

在这里,我并不是想太过随意,但是这个问题的假设(以及所有答案之一)几乎适用于集中式VCS,例如TFS,SVN,Perforce等。
足够,这就是OP所使用的。

但是,另一方面,在使用DVCS(例如Mercurial和Git)时,通常不必等待签入,答案中提到的大多数内容(例如diff,获取最新内容,合并等)都是不必要的。甚至代码检查和测试之类的事情也最好在签入后执行(尽管可能在推送之前,取决于...)
(到目前为止)我在这里看到的一个例外是与工作项相关联。当然,对签到发表评论也很好...

20
AviD

我在其他答案中没有看到的三件事:

包括新文件

  • 查找不包含在变更列表中的新文件
  • 可能是Perforce等SCM特有的-您必须告诉它更改中的所有内容。

还原未更改的文件

  • 当我查看其他人的更改并且有一个包含9个文件的更改列表时,我讨厌,但其中只有3个已被修改。
  • 我还使用空格或其他无意义的更改来还原文件。

检查您提交的提交

  • 确保在提交后构建保持绿色。
  • 我以前有第二台机器,在提交后可以同步,构建和运行,因此如果出现问题,我可以轻松地进行修复。

使用Git时有两件事:

原子提交:

  • 仅分阶段进行单个功能更改以进行提交。
  • 使提交尽可能小。使它们易于修补,还原和理解。
  • 我用 git add --patch如有必要,将我的更改分为多个部分。

总结时查看差异

  • 我总是使用git commit --verbose,这样我可以在输入提交消息时看到更改的差异。 (或者我使用我的补丁 git-vim 来显示差异。)
  • 这样可以更轻松地进行更改并描述整个提交。有时候,我在这个阶段会遇到意想不到的变化。 (描述您的更改有助于您进行思考。)
8
idbrii

搜索和替换诅咒词;-)

7
Throwback1986

我在团队的服务器上执行的一些“良好实践”很简单。首先,在签入之前,应始终获取最新信息并运行本地构建,以确保没有其他人检查过与代码冲突的内容。此外,请注意本地计算机(而不是服务器)上的任何代码冲突。一旦确认您的代码(已下载最新代码)可以正常构建并正常工作,便可以进行下一步了。运行所有自动化测试,然后开始签入,以确保它们仍然可以正常运行。然后,请确保再次获取最新信息。

作为TFS管理员,可以对所有签入强制执行注释。我建议始终为您的工作添加检入注释,无论是否强制执行。如果您可以这样做,请强制执行。确保注释至少是自上次签入代码以来所做更改的一般摘要。这样,如果出现问题,您可以查看签入内容,大致了解一下在签到中进行了更改。它使调试损坏的版本更加容易。

此外,如果您具有TFS管理员权限,则可以在签入中强制进行滚动构建(以确保其他所有人都可以立即知道他们的签入是否有问题),并且可以将服务器设置为执行门控签入(如果签入的代码破坏了构建,服务器将拒绝它),或者您可以简单地让它创建一个错误并将其分配给破坏构建的任何人。

您可以打开或关闭其他一些选项,以使一切井井有条,或者建议您的TFS-Admin开启以保持环境的整洁。

7
guildsbounty

如果您是从Windows检入的,请检查您的代码是否没有那些不可见的^ M字符-UNIX中的编辑器经常会给出错误/警告的原因。

还要尝试并替换制表符-不同的用户最终会看到制表符的不同之处,其中有些带有4个空格,有些为8个空格,不利于代码的可读性。

恕我直言,最好的方法是让一个预定义的脚本根据您组织的编码准则检查您的代码。源代码控制系统的负载具有此功能。

4
Fanatic23

在我的公司中,我们使用签到评论。这些内容不必详细说明,但是仅向某人显示您的变更列表中的差异并通过它们进行交谈有时会突出显示您在测试中错过的错别字。

除非您在评论中注明评论者的姓名,否则我们的源代码管理服务器将不允许您签入(以!initials形式,例如,如果Bruce Wayne进行了评论,则为!BW)。审阅者收到一封电子邮件,指出他们帮助审阅。这很容易受到明显的利用,但似乎效果很好。

4
tenpn

只要有可能,我都希望将签入与工作项相关联。这为您提供了有关更改原因的一些上下文信息,而不仅仅是更改的内容。 TFS有一个相当不错的工作项目跟踪系统,因此在办理登机手续时这很简单。

(这是对我所做更改的差异的补充)

4
mpeterson

我要做的一件事是不检入尚未真正更改的文件。这些文件可能已被无意间修改,或者可能已参与重构,这些重构要么已回滚,要么已被其他人讨论。

这样,您的变更集(与工作项关联)完全包含满足工作项所需的文件。

3
John Saunders

在这里合并所有答案并给出完整的清单

  1. [签入/签出]您不应该直接签到其他人正在使用的流。您应该有一个流策略:例如每个开发人员一个流,您可以在其中独立地签入和签出,而不会打扰其他人:您的工作将是安全的,但是在您自己的开发流中,所以[仅在您自己的开发流中]是安全的。每次签入时,您都将其与变更记录相关联,以使您的变更相对于称为变更集的变更而言是原子的(这样,您就可以分发单个的RFC /错误等...而不必交付“所有内容”)。

  2. [然后根据您的团队信息流进行调整],这意味着您可以从自己的信息流中获得其他人的更改。在该操作期间,您可以在合并对话框中看到所有的“差异”并进行遍历,或者...如果有成千上万个和/或您不使用代码,例如数据模型/ siebel项目等...依赖于非平凡合并,平凡自动和平凡手动合并,最后一类包含困难的合并。请记住,您仍在自己的流中工作。

  3. [完整的基础]如果一切正常,请检入您刚刚从团队信息流中获得的所有更改:您自己的信息流现已更新

  4. [交付]现在将您的工作交付给团队流。如果您不想交付所有内容,则还可以选择例如解决了一个特定的RFC,其中包含特定版本的文件或一组RFC /缺陷。

  5. [测试交付]应该可以,但是由于有机会同时交付了变更,因此您也可以:您可以测试您的工作是否可以与团队流中的最新变更一起使用。使用相同的合并对话框显示差异。

  6. [完成交付]完成交付,您的工作现在在团队中。

使其更加复杂:由于您交付的工作仍然有可能=好的,但您已经在开发另一个版本,因此应始终在交付后确定基准,并指出其他用户希望从哪个基准中重新确定基准。这样可以确保其他开发人员在流中获得推荐的版本,而不是最新版本(如果您在那种情况下工作)。这也是三次检查,因此即使团队流中的最新版本“很差”,它们仍然不是其他人要改写或查看的版本,并且您的配置管理器可以将先前版本合并到下一版本来撤消您的交货。

  • 来自肿瘤的答案发生了两次:在步骤2和6中
  • 奥德(Oded)提供的登机舞步的答案:同上,但又有一层额外的内容,并基于登机/签出来确保您的工作与外界隔离,即使在以后的阶段中也总是可以轻松地排除错误
  • 答案来自guildsbounty的答案:最新是步骤2。对于构建:确实取决于您是否拥有构建...在我的世界中,您是否有数据模型,Word文档,需求表,来自Informatica,siebel,等等。是的,也Java代码,.net代码等...应该都混在一起。所以这里没有真正的“构建”,而是更多的集成,取决于是否例如,从您的“代码”构建的那个构建与所有其他构建集成在一起,因为您无法确定它是否是集成构建,并且根据其测试环境,可能需要对其进行编译,或者在更高交付时,因为它需要其他团队的帮助。
  • 来自guildsbounty的评论和必填项的答案:我认为您未在其中集成VERSIONS和变更集变更(和类型:缺陷,RFC,hotfi)的每个环境都不成熟。我认为如果您不能自动化发布说明,其中包含提交的bug和rfcs的数量,这些bug和rfcs可以单击找到涉及的确切版本(因为hello.c的版本1和版本3可以很好地交付,但是版本2应该不应该交付,因为那样的东西将会有一个更高版本的一部分,但是已经有一些菜鸟了)(所以这意味着如果您还想取出hello.3的版本,则是一个手动决定。c但是要取出版本3意味着您还必须取出所有版本RFC /缺陷所涉及的其他版本,因此您需要能够轻松,快速地使用一种工具来删除全部内容(即使有多个开发人员在同一个RFC的各个部分上工作),但至少您需要围绕它来确定等等...)。额外的文档总是很方便,但是通过关联变更集,您将获得一个完整的圆圈:版本<-变更集<-工作项<-票据/ rfc /缺陷<-需求。含义:您知道完全或完全交付了哪些需求:一个需求包含多个RFC或bug或其他内容。 RFC为多个人提供了多个工作项。该工作项对应于一个变更集,该变更集存在一组版本(例如,集成流上的hello.c的版本1和3),当然不是您的开发流中的版本1,2,3,4,5集成流中的3对应于)(因此有版本树和对其进行操作的工具)
  • 来自luis.espinal的评论:不要中断构建,需要在重新基准中再次检查并仍然交付...对于“发布经理和构建团队”,应该将变更集和基准作为其信息,因此交付量较高。 “从不直接在主分支上工作”是的,流结构可以很大也可以很简单,但从本质上说:开发人员拥有自己的流,他们交付给团队流,然后交付给发布流。 ->以便所有团队(例如文档团队,需求团队,开发团队,测试团队)的交付都在他们的团队流中,并且发布经理或配置经理掌握发布中应该使用的基准,并确保具有正确测试版本的正确文档具有正确要求和正确代码版本的docs /结果都符合发行要求。

在您的示例中,您忘记了注释掉代码。发生错误。围绕它的配置管理系统应该照顾好它。确实可以是例如数以千计的更改进入,“构建”和“集成”发生在按时间顺序链接和处理的不同服务器上的流的层次结构中。因此,即使您在5个月后将注释掉的代码在集成服务器上进行了测试,因为您的代码需要与其他代码和系统进行集成,仍然应该可以自动删除您的变更集并继续进行。因此,最佳做法或多或少是较高的。配置管理流的总体设计应注意这一点。对于个人开发人员来说,最佳实践当然是验证/单元测试。但是,从全局到“使之起作用”的最佳实践是遵循该系统,并始终为链中的后续人员提供相关变更集的元信息。

3
edelwater

根据您的SCM,以下某些应用比其他应用(或以不同的形式)应用更多,所以在这里:

  1. 不要破坏构建-仅检查编译的代码。
  2. 评论您的签到(如果您的SCM为您提供了该选项,则可以签出。)
  3. 不要长时间不检查东西。
  4. 经常检查(如果可能,每天检查几次)。
  5. 有意义地标记。
  6. 定期贴标签。
  7. 切勿直接在主分支上工作。
  8. 每个正式发布的产品都必须具有自己的标签(如果可能,还应具有一个位于主分支之外的只读分支)。如果可能,对UAT/Integration /生产前测试版本执行相同的操作。
  9. 您应该能够根据SCM和标签中的内容准确构建生产中的内容。

[〜#〜] note [〜#〜]:上面的某些项目看起来很明显,但是您不相信实际上有多少人在主分支上工作或首先对生产进行更改- 然后手动创建增量以进行版本控制...直接在主分支上...并带有标签。像发酵的胆汁和未洗过的腋窝汁混合在一起的甜味...是的,就像那样。

2
luis.espinal

有个人检查清单。当您搞砸时,请在入口处将其启动为空。当它成为第二自然属性时,将其从列表中删除。

运行测试。如果他们通过了,则将其检入。如果您搞砸了并且某些东西无法通过测试,则编写一个测试。

2
ctrl-alt-delor

总是总是,请确保所做的任何更改都不会破坏构建。尤其是细微的变化,看似微不足道。

一旦做了很小的改动,我就认为在离开周末之前不会造成任何问题。可以肯定的是,几乎没有什么变化使构建中断,并且没有为我们的项目执行每晚的测试运行。问答主管对此不太满意,这是正确的。

1
gablin

运行您一直在努力的单元测试。绿色很好。

1
Naftuli Kay

确保代码格式正确(例如,对于Java:选择代码,然后在Eclipse中按Ctrl-Shift-F)。但是要小心整个文档。

1
Rune Aamodt

我们做以下...

  1. 测试-我们要确保它能正常工作。至少,我们想知道它不会破坏任何东西。

  2. 代码审查,或至少是一个伙伴检查-这是确保知识传布并确保人们与时俱进的好方法。它还有助于在检入之前捕获错误。

  3. 发送预先通知-签到之前将预先通知发送给该组。目的不仅是让其他人知道正在更改的文件或区域,而且还可以使他们提前意识到(如果他们选择注意的话),以防预期这些更改会影响到它们。

  4. 发送预先通知的几个小时后,将执行签入,并通过电子邮件通知该小组。小组中的每个人都可以知道何时完成有关错误或功能的特定工作。

  5. 签入通知的副本将粘贴到与错误或功能关联的修复记录中。在搜索记录时,我们发现了解修补程序/功能的含义非常方便。

1
Sparky

查找可以作为独立单元进入的部分更改。

通常,当我对代码进行有效的修复或增强时,已经有很多更改。其中一些特定于我要进行的行为更改;其他人则在重构,以使更改更加整洁。

我更喜欢使用其自己的更改描述分别检查每个重构,如下所示:

重新处理:将X重命名为Y

X以前很有意义,因为...但是现在应该是Y。这与问题9的工作有关。

然后,一旦签入每个良好的重构,最终的行为更改通常就变得微不足道了。

另外,某些更改会影响许多行代码,但并不是很有趣,而其他更改则非常本地化,但会产生重要影响。如果一起检查这些更改,则可能很难读取差异。因此,我将它们分开。

后来,当有人阅读变更历史时,很明显事情是如何到达当前事务状态的,为什么会这样。撤消我的行为更改也很简单,因为它不会与大量其他编辑纠缠在一起。

1
Jay Bazuzi

我为我的工作保留了本地汞回购协议。

  • 每当我检入某些东西时,我都会检查差异并确保所有更改都是可接受的。
  • 我尝试记下签到的关键功能。
  • 我尝试将每个提交大小保持为一项关键功能。

我并不是说这些是最好的,但是它们确实为我工作。

0
Paul Nathan

退还从某人那里借来的东西时,要做些什么。确保它干净且形状良好。如果您搞砸了,请确保在将代码退还给所有者(大多数情况下是您的雇主)之前进行清洁。

0
Jason

当我编写不知道要检入的代码时,我在它之前添加一个包含“ // TEMP:”的行,并在其后添加“ // END TEMP。”。这与在签入之前进行差异比较一起,保证了我不会错误地签入该代码。

0
user17815

彻底测试您添加或更改的所有内容。尝试所有可能想到的情况。不要将测试留给质量检查人员。如果我每次做了些小改动后都拥有一个三明治,然后为了安全起见尝试了一些测试用例,并立即发现问题,那么我将拥有很多三明治。我通常会对自己大声说:“我很高兴我尝试了……”

您说更改后UI变得奇怪。如果您只运行程序并在签入之前查看了UI,您是否注意到了问题?

0
Ken