Pull request: Difference between revisions
From YM2149.org
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
Also see [[pull requests versus pair programming]]. | |||
== Commit goals == | == Commit goals == | ||
| Line 5: | Line 6: | ||
* 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 heavy handed merge-time squashing | * 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
