3 ms·
I use git add -p to split apart what I intend to eventually fully get into the repo. Usually, this means separating whitespace cleanup from meaningful commits.
by Pistos2 15y ago
I use git add -p to split apart what I intend to eventually fully get into the repo. Usually, this means separating whitespace cleanup from meaningful commits. Sometimes I use it to make my commits "distinctly describable" -- instead of a big commit saying (in effect) "I did lots and lots of stuff generally to do with BigTask", I am able to describe various steps of that work, e.g. "Refactored models.", "Added supporting .js file for foo mechanism.", "Migration for bar process.", "Controller method and view for baz form."
Generally, I reserve the "make sure it works" step for just before _pushing_ (i.e. making public), rather than just before committing.
I always use either `git commit -av` or `git add -p`, so I can preview what I'm about to do. I never use the freewheeling `git commit -m`.
- zerd 15y agoProblem with not testing your "micro-commits" is that when someone is looking at old revisions to figure out where something went wrong, there is a chance that it won't compile, or will crash because you didn't test that exact commit.
- Pistos2 15y agoI prefer smaller commits to larger ones because it isolates things (both improvements and breakage). I use git bisect when needed. You can always squash small commits into larger ones if really necessary, but teasing apart large commits into small, logical steps or components is much harder. Smaller commits are more "mobile" in that they can be cherry picked (in or out).
- davvid 15y agoAfter preparing the index with `git add -p` you can use `git stash --keep-index` before committing to help test your changes. This is a good practice to follow for exactly the reason you describe.