The `git push --force` command didn't quite make the cut, but if you can think of a place where it fits into the current tutorial I'm certainly open to adding it. Maybe it fits in as an exercise somewhere?
UPDATE: yebyen has suggested this was a meant as a joke. If so—good one!
UPDATE 2: I don't mean to imply that force-pushing isn't useful! As several commenters below have noted, it most certainly is. But it's also most certainly dangerous.
I've seen `git push -f` used quite a bit over my career. Maybe it's bad practice, but it's useful for:
1. Organizations that want single-commit branches (e.g., where there's a lot of cherry picking going on in a git-flow style to get certain features pushed out) but you also want to keep 'savepoint' commits while developing. Squashing a bunch of commits requires a -f if you've already pushed.
2. Rebasing a branch (without making a bubble merge).
3. For truly small quick fixes you notice when you've just pushed to CI (like you left in a debug or a focus on some tests).
Much more than that. `git push -f` and `git rebase -i` are essential tools to keep a history where every commit passes CI. And that is very important for `git bisect`ing things later.
They are also necessary to keep a history where `git blame` can be used effectively.
Rebasing shared branches is pretty nasty. Do people really keep a policy of "every branch must pass CI" ?
I like rebase on my branches so I merge as a single commit at the head of the branch I am merging into, but rebasing a shared branch is total ick.
As for needing every branch to pass CI forever to use git bisect.. that seems a bit extreme. I think I have used git bisect like 3 times in the past 5 years? And each time I wrote a very simple unit test and fed it into git bisect and was able to figure it out without a problem. If you are using git bisect constantly I guess I can see, but that has another smell. Who cares when it was broke, just fix the broke thing!!
On shared branches, I think the rules are different. Rebasing a shared branch is very sticky. But for single-dev branches, I think rebasing/forcing is fine -- do what you want until it enters the main stream.
git -f on a shared branch is a surefire way to lose commits. OMFG. It's better not to allow it at all. git revert will undo damage adequately, just not cleanly.
I think that was supposed to be a joke. Enough git to be dangerous... what about some dangerous git command which potentially destroys some important history... [stopgirl.gif]
Your books are great, I've been buying Learn Enough to be Dangerous preorders for topics I already know well because I learned so much from the Rails Tutorial dot-org. Thanks!
Heh, I almost replied that `git push --force` might be a little too dangerous! But the truth is it barely didn't make the cut, and I wouldn't mind finding a place to work it in.
UPDATE: yebyen has suggested this was a meant as a joke. If so—good one!
UPDATE 2: I don't mean to imply that force-pushing isn't useful! As several commenters below have noted, it most certainly is. But it's also most certainly dangerous.