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?
1
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.
2
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.