Git commit partitioning: Difference between revisions
(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...") |
mNo edit summary |
||
| Line 10: | Line 10: | ||
| The code should build and run after each commit. || This allows the <tt>git bisect</tt> command to work as expected. | | The code should build and run after each commit. || This allows the <tt>git bisect</tt> command to work as expected. | ||
|- | |- | ||
| There should only be one functional change per commit. || This makes the code easier to review. | | There should only be one functional change per commit. || This makes the code easier to review. If the commit introduces an error, it is much more obvious what is the source of the error and how to fix it. | ||
|- | |- | ||
| The first commit often cleans up the code match the coding standard. || If you touching the code, make it better. | | The first commit often cleans up the code match the coding standard. || If you touching the code, make it better. | ||
Revision as of 22:15, 3 December 2014
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. If the commit introduces an error, it is much more obvious what is the source of the error and how to fix it. |
| 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. |