Live data from Hacker News

Some bad Git situations and how I got myself out of them

ohshitgit.com

11–20 of 352 posts

Re: Some bad Git situations and how I got myself out of them

#12
I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down.

Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right.

Sure git is not the friendliest of beasts but what it lacks in interface, it more than makes up in internal consistency and trying to learn it "inside out" is a better long term investment than having a list of ways to solve "git problems".

Re: Some bad Git situations and how I got myself out of them

#13
post #8

The screwed up and committed to master should end with: git reset --hard origin/master (assuming that the remote is called "origin") With the example in the text, you have to know the number of commits you've made to master.

It was also a bit pointless to checkout a new branch just to switch back. The whole thing should be git branch some-new-branch-name git reset --hard origin/master git checkout some-new-branch-name

The "committed to wrong branch" case is also a little overly complex. I'd just do:

    git checkout correct-branch
    git cherry-pick wrong-branch
    git checkout wrong-branch
    git reset --hard HEAD~

Re: Some bad Git situations and how I got myself out of them

#16

Surprised there was nothing on messed-up merges or rebases. They're some of the worst to get out of when you're not totally comfortable with git yet.

And reflog. It sort of like revision control of your branches and commands. Very useful to extricate oneself from various situations.

Re: Some bad Git situations and how I got myself out of them

#17

The screwed up and committed to master should end with: git reset --hard origin/master (assuming that the remote is called "origin") With the example in the text, you have to know the number of commits you've made to master.

the website's example is for when you only want to undo just the last commit you made.

Re: Some bad Git situations and how I got myself out of them

#18

I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down. Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right. Sure git is not the friendliest of beasts but what it lacks in interface, it more than m…

I think there's a bit of that in git in particular.

The irony is that if you think of git in terms of deltas, with branches just being tags to commits, and "git commit" actually being "git commit + move branch", then a lot of stuff is easier to reason about.

Like, if you get the notion of working tree, staging area, commits, and branches on a deep-ish level, things get easier. Things can still be hard, but there's a lot less "does running this cause everything to disappear???"

I think it would be possible to make this awesome page even more awesome with a little "annotated version" that gives the details of what you're actually doing.

Re: Some bad Git situations and how I got myself out of them

#19

> Oh shit, I accidentally committed to the wrong branch! Other ways to do it (that don't require to retype the commit message): - rebase onto the correct branch: git branch foo git reset --hard HEAD~ git rebase --onto name-of-the-correct-branch HEAD foo git checkout name-of-the-correct-branch git merge foo git branch -D foo - cherry-pick git reset --hard HEAD~ git checkout name-of-the-correct-branch git cherry-pick n…

Or use git branch -m to rename master to something else, then checkout master anew.

Re: Some bad Git situations and how I got myself out of them

#20
I absolutely love git now.

I'm still at uni (at a highly ranked but actually crap university where we don't learn git properly) and this year was my 'year in industry' as we call it in the UK, and my first proper experience with git, aside from `git init` at the end of my project and pushing it to a repo.

I've become so much more confident with git. Seriously, with one caveat (i.e., you haven't pushed your changes to a branch which other developers are working on), it is almost impossible to break irrevocably. Even if you do accidentally break master/develop/whatever, it only causes a bit of hassle and grumbling.

Highly recommend that everyone take a bit of time to learn about "undoing" git commands, whether that's through soft resets, hard resets to origin, or the reflog.

Reflog is also useful for figuring out how someone else broke something and explaining what they did wrong, since you can see what branch they were on at what commit and what commands they ran.

I think git's main problem is the somewhat arcane language it uses, and lack of understanding of what's actually happening behind those words like "rebase", "commit", "patch", "reset" etc.

Post reply on HN