4 ms·
Oh, I have practically the same alias. You might be surprised at this if you use Git in append only mode, making "fix 1", "fix 2", ... commits on a branch when
by tux3 2y ago
Oh, I have practically the same alias.
You might be surprised at this if you use Git in append only mode, making "fix 1", "fix 2", ... commits on a branch when you find a problem in a previous commit
Another workflow is to keep each commit self-contained, rebase the series when you make changes, and send the v2, v3, ... of your pull request with push --force
Of course, if you do this on a shared branch that other people also want to commit on, you may want to pick a desk close to the exit, and far away from any windows
- aunderscored 2y agoHave you considered fixup commits? On shared branches they work very well. Either autosquash before pushing, or as part of your final PR prep
- tux3 2y agoOn shared branches I prefer to send pull requests, that way I can rework my draft and respond to review comments until it's ready, without pushing undercooked commits directly on the shared area What lands on the shared branch has a meaningful history, that has helped me more than once to understand the context in which an old change was made, when running git blame many months later. I feel like it should be as easy to review the history as it is to review a PR. Squashing makes this a bit harder for me. Especially when autosquash loses long commit messages. But I like to use git-absorb to automatically create fixup commits, it generally works pretty well and saves me a little bit of tedium each time!