Git commit partitioning: Difference between revisions
mNo edit summary |
m (→Guidelines) |
||
Line 12: | Line 12: | ||
| 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. | | 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. There should be no functional change. | ||
|- | |- | ||
| 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. | | 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. |
Revision as of 22:17, 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. There should be no functional change. |
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. |