Pull request: Difference between revisions
From YM2149.org
Jump to navigationJump to search
(Created page with "== Commit goals == * make life easier for the reviewer * separate refactoring from actual changes * make it easier to undo functionality in the future by reverting a commit * small enough number of commits to avoid crude merge-time squashing == Commit arrangement == * although in practice refactoring is done as needed, any such commits should go first Category:Programming") |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Also see [[pull requests versus pair programming]]. | |||
== Commit goals == | == Commit goals == | ||
| Line 4: | Line 5: | ||
* separate refactoring from actual changes | * separate refactoring from actual changes | ||
* make it easier to undo functionality in the future by reverting a commit | * make it easier to undo functionality in the future by reverting a commit | ||
* small enough number of commits to avoid | * small enough number of commits to avoid heavy handed merge-time squashing | ||
* every commit should have a reference to the business ticket being delivered | |||
** this provides context for when subsequent changes are made, potentially far into the future | |||
== Commit arrangement == | == Commit arrangement == | ||
* although in practice refactoring is done as needed, any such commits should go first | * although in practice refactoring is done as needed, any such commits should go first | ||
* [[Leytonium]] has tools to semi-automate rearrangement of commits | |||
[[Category:Programming]] | [[Category:Programming]] | ||
Latest revision as of 21:06, 17 February 2025
Also see pull requests versus pair programming.
Commit goals
- make life easier for the reviewer
- separate refactoring from actual changes
- make it easier to undo functionality in the future by reverting a commit
- small enough number of commits to avoid heavy handed merge-time squashing
- every commit should have a reference to the business ticket being delivered
- this provides context for when subsequent changes are made, potentially far into the future
Commit arrangement
- although in practice refactoring is done as needed, any such commits should go first
- Leytonium has tools to semi-automate rearrangement of commits
