[rjtobin]

Some other Git features that I find super useful, which past colleagues of mine haven't known about (which maybe suggests they are not universally known).

git rev-parse branch-name: gets the hash of a branch name, useful for verifying two branches are at the same place (so "git rev-parse HEAD" gets the current hash)

The ^ and ~ notations for navigating commits: my_branch^ points to the commit 1 before my_branch, and can be repeated multiple times, ie. my_branch^^^ to get the commit 3 from the top. Likewise the tilda notation allows one to jump a fixed number of commits up: my_branch~10 is the commit 10 above my_branch.

git rebase -i HEAD~10: interactively rebase the last 10 commits. Easy way to re-order, squash, drop, and/or edit the commit messages of recent history in a single git command.

[32bitkid]

This one is interesting, because if I recall correctly, if you are using the single symbol they more or less mean the same thing. You can do ~~~ or ^^^ and get to the same spot

The difference is in their numerical notion. ~N means go to my Nth first parent. Where ^N means my Nth parent, which is really only valuable/useful on merge commits (Or more specifically octopus merges that merge more than two commits)

This is why ~ and ^ in the single form mean the same thing.

So, in one mental model of the DAG you can think of ^ as horizontal navigation (Right) and ~ as vertical (Down)

[rjtobin]

Oh cool! That's good to know. Sadly too late to edit my original message, but have upvoted yours so people won't learn from my errors :)

[u801e]

> git rev-parse branch-name: gets the hash of a branch name, useful for verifying two branches are at the same place

I believe the same thing can be done by running git log --oneline -n1 branch-name (though you will also get the commit message title in addition to the sha).

> my_branch^ points to the commit 1 before my_branch, and can be repeated multiple times, ie. my_branch^^^ to get the commit 3 from the top.

The ^ notation only references the first parent of the commit. You would have to do something like commitish^2 to reference the second parent (though this would only be an issue for merge commits or any commit that has more than one parent).

[tomcatfish]

My god, we have to use git in school and no one knows about rebasing. A group member made commits with profanity in messages (ha-ha, so funny, now how about some useful messages though?) and it turned out at the end we had to submit the repo. Everyone was panicking until I told them I could change the message in literally half a minute.

Rebasing cleans up my commits so much. It is nice being able to have a chain of nice, logical commits even in the middle of a hairy refactor.

[sigjuice]

A couple of other ways to see if two branches are the same or not

  git diff branch1 branch2

git show displays any additional branches that are the same.

  $ git show -q
  commit 2ee0fd3e2717a352b6ded617184be280cb55e78c (HEAD -> master, foo)
  ...

[lordgrenville]

Just learned git rebase -i last week. Added tip: git rebase --abort at any point in the process if you're not sure if you did the right thing.