When mentoring a junior, I noticed he had an alias `gpf`, which he apparently picked up from another developer.
I had a serious conversation with him, explaining that I'm not in the habit of telling him how to configure his shell, edit or general work environment. But an alias for `git push -f`, that I cannot condone. When you're doing that, the two seconds it takes to type it out should be rather low on the list of priorities.
So we had a good talk, and he genuinely understood the point I was trying to make. When I was about to leave, he looked at me sheepishly and asked:
On my last project I was the only person who had --force permissions on bitbucket. In six years I used it twice on purpose, and once on accident (and then once again to undo the mistake).
If you want to do a push -f to a branch that only you are working on to finish a rebase -i to make the commits you did in haste make sense, then go for it. But nobody should be forcing to master unless it's to undo a really big fuckup.
One was merging a PR with giant files accidentally attached, the other was re-exporting from perforce because they totally fucked 'git blame' and I wasn't having any of that.
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
On 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!
I had a serious conversation with him, explaining that I'm not in the habit of telling him how to configure his shell, edit or general work environment. But an alias for `git push -f`, that I cannot condone. When you're doing that, the two seconds it takes to type it out should be rather low on the list of priorities.
So we had a good talk, and he genuinely understood the point I was trying to make. When I was about to leave, he looked at me sheepishly and asked:
"So I guess you want me to remove this one too?"
gacpf - git add . && git commit --amend && git push --force