Git commit partitioning

From RidgeRun Developer Wiki
Revision as of 22:01, 3 December 2014 by Tfischer (talk | contribs) (Created page with "= Problem statement = You need to add functionality to an existing code base or fix a defect. How do you decide which changes go into which git commit? = Guidelines = {| b...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Problem statement

You need to add functionality to an existing code base or fix a defect. How do you decide which changes go into which git commit?

Guidelines

Guildeline Reason
The code should build and run after each commit. This allows the git bisect command to work as expected.
There should only be one functional change per commit. This makes the code easier to review.
The first commit often cleans up the code match the coding standard. If you touching the code, make it better.
The second commit often refactors the code without changing the functionality. This makes it more straight forward to understand the commits that fix the defect or adds new functionality.