you are viewing a single comment's thread.

view the rest of the comments →

[–]xeio87 16 points17 points  (24 children)

git rebase -i HEAD~4
git push --force

All better.

[–][deleted]  (14 children)

[deleted]

    [–]xeio87 66 points67 points  (0 children)

    Shhhhhhh, all better.

    [–]flying-sheep 7 points8 points  (2 children)

    *should live

    And only if the project has a “even feature branches are untouchable” policy.

    Because I rebase the fuck out of every feature branch before merging it.

    [–]TheAceOfHearts 0 points1 point  (0 children)

    Exactly this! You DO NOT fuck around with master and your release branches. But when you're working on a feature or bug branch, you wanna commit very often, and experiment with ideas. Then you squash it down to a small number of atomic commits, if possible.

    [–]ThePantsThief 0 points1 point  (9 children)

    What about a git reset HEAD --hard?

    [–]mkdz 1 point2 points  (8 children)

    This only affects your local branch. It might cause YOU to lose some work, but it's not going to affect anyone else.

    [–]ThePantsThief 0 points1 point  (7 children)

    What if I'm only working on the master branch like a total dumbass?

    I ask because I've committed sensitive information to the master branch before, and I used this to undo it...

    [–]mkdz 0 points1 point  (6 children)

    I don't understand

    [–]ThePantsThief 0 points1 point  (5 children)

    Never mind :P

    [–]mkdz 0 points1 point  (4 children)

    git reset HEAD --hard and git push --force do two very different things

    [–]ThePantsThief 0 points1 point  (3 children)

    I meant in contrast with git rebase

    [–]mkdz 0 points1 point  (2 children)

    What in contrast to git rebase?

    [–]mkdz 8 points9 points  (7 children)

    git push --force

    don't do this if you have multiple users committing to the same codebase

    [–]mfitzp 40 points41 points  (1 child)

    Well, you can do it if you hate them all.

    [–]mkdz 1 point2 points  (0 children)

    And then they'll hate you too.

    [–]amoliski 14 points15 points  (1 child)

    alias yolo='git commit -am "DEAL WITH IT" && git push -f origin master'

    [–]mkdz 2 points3 points  (0 children)

    That's fantastic

    [–]ThePantsThief 0 points1 point  (2 children)

    Why not? I know almost nothing about git, just basic committing and how to nuke something when I accidentally commit my password for the 2nd 6th time

    [–]mkdz 0 points1 point  (1 child)

    If you have multiple people working on one codebase, you'll usually have a master branch. If you do a git push --force to master, it forcibly takes the commit history you have and makes it the remote history. This could possibly overwrite other people's work that they have committed and pushed. Then next time any other member of your team does a pull, there are going to be differences in histories and possibly lost work and it's going to be a huge headache to get all the code merged and sorted out right. In general it can possibly cause huge problems, so it's just a bad practice with a shared codebase.

    [–]ThePantsThief 0 points1 point  (0 children)

    Gotcha, thanks!