Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know that most of you would advice to go with the strategy and methodology of the project.

However I just have a quick question, from Senior point of view, what would be better to see quick small commits from a developer, or large chunk of code pushed to the branch?

share|improve this question

closed as not a real question by gnat, MainMa, Walter, Yusubov, GlenH7 Oct 22 '12 at 18:11

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

Release Early Release Often! - But ensure release isn't broken! Eric Raymond – Dipan Mehta Oct 19 '12 at 4:29

It doesn't really matter the size, but rather commit must be an atomic as possible. By that I mean that commit must not break the build, it should fix one specific bug, or add one specific feature and be independent from any other commits. If a feature requires a lot of code, well so be it. But usually this strategy naturally produces small frequent commits.

share|improve this answer
Can't agree more – Jackie Chan Oct 19 '12 at 2:08
"If a feature requires a lot of code, well so be it. But usually this strategy naturally produces small frequent commits.": Not necessarily. You can develop and test locally, and when you are confident enough you commit. You may need further commits only if you find bugs / problems later. – Giorgio Oct 19 '12 at 5:41

There are limits, but I prefer small, atomic commits.

First, it makes things easier when you're referring to why a change was made. Second, it drastically reduces the cost of making a mistake.

Two notes of caution though:

If you're using a centralised VCS, only commit when the code builds and tests run. (If you're using DVCS, replace "commit" with "push".)

Do not implicitly refer to one commit comment from another.

351: pdr: Stop foo from grommiting.
352: pdr: Ooops, got that wrong, let's try again.
353: dan: New launch page.
354: pdr: Third time lucky.

That sort of thing. Don't do it. It's very tempting when you're committing often, because you remember the commit you did five minutes ago, and commenting starts to feel like a conversation with yourself. But control yourself. It makes no sense to the poor person, two years into your future, who does a search for the last commit on given files.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.