你们有什么理由希望在有人提交某些代码时收到通知吗？
我知道有一些事情，比如进行手动检查，以确保提交的代码基本上是正确的。 但除此之外呢？ 我问的原因是因为一个大项目每天都有很多提交。
I know there are things like doing manual check to make sure the codes committed is fundamentally correct. But beside that? Reason i asking is because a big project there are so many commits everyday.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
一般来说，提交通知很有用，这样您就可以了解代码中每天发生的情况。 例如，我知道何时实现了新功能，或者签入了错误修复。如果提交太多以至于在噪音中丢失，那么可能值得过滤或减少您看到的提交消息的数量（也许例如，您可以将其限制为仅适用于您正在使用的特定模块）。
话虽这么说，除了让其他开发人员有机会至少粗略地审查代码之外，它还可以通知人们：
你明白了。 基本上，它的目的是帮助提高整个团队的透明度，不仅是为了更多地关注承诺，而且是为了改善整个团队的开发周期。
Generally speaking commit notifications are useful so that you have some idea what's happening in the code on a daily basis. For example, I know when a new feature has been implemented, or a bug fix is checked in. If there's so many commits that this gets lost in the noise then it might be worth filtering or reducing the number of commit messages you see (perhaps you can limit it only to specific modules you work on, for example).
That being said, aside from giving other developers the opportunity to at least cursorily review code, it can also notify people that:
You get the idea. Basically, it's meant to help foster transparency throughout the group, not just to put more eyes on a commit but to improve the development cycle for the team as a whole.
上面提到的许多事情在收到签到通知时都很有用。 我通常将它用于以下几件事：
即使有很多通知，我也不觉得必须完整地阅读它们。 我浏览了很多，但这足以让我在需要更多信息时回到适当的提交。
Many of the things mentioned above are useful when getting notified of checkins. I typically use it for a couple of things:
Even if there are many notifications, I don't feel that they have to be read in their entirety. I skim them a bunch, but that's enough to get me back to the appropriate commits when I need more information.
如果有人对您自己正在开发的一个或多个程序进行更改，这可能会很有用。 如果您愿意的话，请注意，您可能需要解决一些可能需要进一步沟通的冲突。
我见过这样的情况：程序员 A 进行了一些更改，然后几天后就去度假了。 程序员 B 也在开发相同的程序，并且在程序员 B 提交更改时存在一些冲突。 通常这没什么大不了的，而且团队成员之间应该始终保持沟通畅通。 在这种情况下，程序员 B 对程序员 A 所做的更改有一些疑问，但不得不等待一周，直到该程序员回来。 在这种情况下，一封提醒电子邮件，甚至是自动生成的电子邮件，都会有所帮助。
只是我的两分钱。
It can be useful if someone commits a change to one or more programs that you yourself may be working on. It's a heads up, if you will, that you may need to resolve some conflicts that may require further communication.
I've seen the situation where programmer A committed some changes and then went on vacation a couple of days later. Programmer B was also working on the same programs and there were some conflicts at the time Programmer B went to commit his changes. Normally this is no biggie, plus communication should always be kept open between the team members. In this case, Programmer B had some questions about the changes made by Programmer A, but had to wait a week until that programmer had returned. A heads up email, even an auto generated one, would have been helpful in this situation.
Just my two cents.
当然，您希望密切关注所放入的代码，以便您了解团队中其他人在做什么，并且您不会仅仅编写代码而陷入困境。
即使您没有监控代码的质量，您也可以了解其他人正在做什么。
它有助于建立团队。
Sure, you want to eyeball the code getting put in so you have some idea what other people in your team are doing, and you're not stuck in a cave just writing your code.
Even if you're not monitoring the code for the quality, you can have an idea what other people are working on.
It helps build the team.
我发现它主要用于跟踪。 一般来说，此类自动通知会被过滤到我的邮件程序中的一个存储桶中，以及“smoketest 通过，smoketest 失败”类型的电子邮件......然后，当出现故障时，您可以相当直接地将其跟踪回签到集。
请注意，人们还可以通过签入曲线的形状直观地了解项目的成熟度——每天更改的代码行数与代码库总大小的函数关系。 它实际上确实给出了您何时“完成”的合理想法......
希望这有帮助！
I find it primarily useful for tracking. In general such automatic notifications get filtered off into a bucket in my mailer, along with the "smoketest passed, smoketest failed" type email...then when there is a failure, you can track it back to the set of checkins fairly straightforwardly.
Note that one can also intuit the maturity of a project by the shape of the curve of checkins--number of lines of code changed per day as a function of total size of the code base. It actually does give a reasonable idea of when you're going to be "done"...
Hope this helps!
通常我们会进行更新，让每个人都知道某些内容已经更新并且需要进行同行评审。 如果您不必分配一个用户，您可以在有时间时获取并处理它。
我看到有人发布了一个系统，当他们在代码风格注释日志中提交快速简单的“正在更改的内容”时，该系统会向 Yammer 发送 twitter 风格的消息。 整洁的。 不过现在找不到链接了。
Usually we have the updates to let everyone know that something has been updated and needs to be peer reviewed. If you don't have to assign one user you can get it and deal with it when you have time.
I saw someone posted a system that sends twitter style messages to Yammer when they commit for a quick and easy "whats been changing" in the code style comment log. Neat. Can't find the link now though.
在许多公司中，代码审查是强制性的，但是在荣誉系统上进行的。 通过电子邮件发送的提交通知为这些环境实现了“信任但验证”机制。
In many companies code reviews are mandatory, but done on the honor system. Emailed commit notifications implement a "trust, but verify" mechanism for these environments.
我主要用它来衡量项目的心跳。 每个提交消息都是一个脉冲。 随着时间的推移，您会对“正常”脉搏“听起来”是什么样子有一些了解。
正常情况下，我们会收到 4 到 6 条提交消息。 随着迭代日期的到来，这个速度会减慢到 1 或 2，并在迭代发布前几天停止。 迭代后一两天，它会再次开始恢复，如果发现错误，我们每小时可以获得 1 条提交消息，因为错误已得到修复。 正常的一天提交次数很少可能意味着开发人员在某些功能上遇到了困难，或者在 stackoverflow 上花费了太多时间。
我还发现信息丰富的提交消息非常有用。 有时，经理或测试人员甚至不必询问开发人员某个功能或错误的状态 - 只需查看提交消息以查看是否已完成任何工作。
I use it mainly to gauge the heartbeat of the project. Each commit message is a pulse. In time, you'll get an some idea on what a "normal" pulse "sounds" like.
In a normal day, we get 4 to 6 commit messages. That slows down to 1 or 2 as the iteration date comes and stops about a couple of days before the iteration release. A day or two after the iteration, it starts picking up again and if bugs are found, we can get 1 commit message per hour as bugs are fixed. A regular day with few number of commits might mean a developer is having a hard time on some functionality, or spending too much time on stackoverflow.
I also find informative commit messages very useful. Sometimes, a manager or tester doesn't even have to ask the developers the status of a feature or a bug - just look at the commit messages to see if there is any work done on it.
我的理解是，向开发人员抄送提交报告的主要原因是为了避免冲突：您会看到正在使用的文件上的提交，因此您甚至在提交之前就知道自己遇到了麻烦。 然而，这相当分散注意力，因此有一些工具（例如 Palantir、旧的 IBM Jazz）可以实际显示哪些文件正在同时编辑。
My understanding is that the main reason for CCing commit reports to developers is to avoid conflict: you see a commit on a file you are working with so you know you're in trouble even before you commit. However, this is fairly distracting so there are tools (e.g., Palantir, old IBM Jazz) that will actually show you what files are being concurrently edited.