Is there any reason why you all want to be notify whenever someone commit some codes?

Question

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.

Answer 1

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!

Answer 2

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.

Answer 3

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.

Answer 4

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:

• it's a good time to run an update from source control and merge any new changes if needed
• Hey, someone found a regex parsing bug in Foo but forgot to update Bar with it
• Oh, Bob's working on the Baz module, I should ask him to take a look at this too

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.

Answer 5

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.

Answer 6

Many of the things mentioned above are useful when getting notified of checkins. I typically use it for a couple of things:

• If the project breaks in some way, sometimes I can more quickly hone in on the problem because I've been aware of the checkins that have been going into the system. It might point me to a solution more quickly
• It provides an easily searchable set of checkins (at least because i receive them in email). Yes, your source control system has all that info, but it might not be easy to search the entire checkin comment. With email, it's pretty trivial for me to go back and search for a user, module, keyword, etc and have Outlook cough up the relevant emails.
• I can easily keep track of younger developers and what they are doing. It gives me a chance to see when they are checking in code and what they are doing with the code. It gives ongoing chances to mentor outside of other regularly scheduled things like code reviews.
• It provides a way for the team to track progress and note when they might be checking in conflicts.

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.