Git skills you need

Given that Git knowledge is a very sort after skill. I figured I might as well place this here for anyone that needs the reference.

Table of Content

• Git? What's that?
• Checking if you are up-to-date with master
• You want to view your project at a very specific moment in time
• You dont need your current changes anymore for some reason
• More on git reset
• Your boss wants you to fix Bug B yesterday, but you currently working on Feature D
• Your version of master/develop is ahead of the remote version and now git doesn't want to pull the latest changes
• Abort! Abort!
• And that's all folksfor now at least

Of late, I've been noticing more and more articles on git commands popping up on my LinkedIn feed. Could be the algorithm or maybe it's just my selection bias kicking in honestly, but none the less I've also noted how lacking in terms of context these examples are. Just because you tell someone that they can skip back a few commits on a branch doesn't help them understand why or when to do so. Now, I don't know how to fish but I'm quite sure it ain't only about throwing a bobber with a string attached into water. There's the type of bobber, bait, and all this is determined by the type of fish you want to catch.

That's the whole premise behind this article. For this guide to be a sort of "cheat sheet" for you to resolve some of the more common issues with git. Or if you want it in the fishing context, how to catch different fish using different techniques (forgive me animal lovers).

Now, you don't need to know how to use git in the command line, your visual source control tool of choice will suffice.

Oh and one last thing, if you think I missed something please do comment, this is a live document so suggestions are very welcome.

Git? What's that?

Unfortunately, this is not a "how to use git for beginners" tutorial. And, no I won't be linking to anything useful, we are supposed to be pro googlers/bingers here, right?

Anyhow, I'm assuming you've used git before and just want an extra reference. But I'll touch up on a few things so that we are on the same page.

A commit is a collection of changes that you plan on storing at that point in time.

A branch is a collection of commits.

Your git history is the order in which commits are placed in your branch. These not being in an order git expects when pulling in changes from the server can lead to,... fun problems.

There are local branches and remote branches. Local branches are stored on your computer. Remote branches are stored on a server. When you pull/fetch a remote branch it's stored as a local branch with the "remote" name prefixed in it's branch name. So if you had a branch called feature stored on your remote server and the remote name stored on your PC is "origin", then the branch will be given the name "origin/feature".

So, when you run git pull on the feature branch, git usually runs, based on some settings, git fetch into git merge origin/feature. git fetch being the command that pulls the remote branch code onto your PC.

Now, that you're up to speed on some of git's vocabulary, we can get started, yes?

Checking if you are up-to-date with Master

Before visual source control tools became mainstream, the common way of checking ones changes was using git status. But now it's mostly used to check if there are new changes on the remote branch.

Though it can't be trusted if git hasn't gotten the latest information from the remote server yet (trust me, this happens more times than you'd want it to).

The paranoid among us might want to git fetch before using git status just incase and the rest of us with trust issues can just go on and git pull just to make sure.

You want to view your project at a very specific moment in time

For this, you use the git checkout <branch-name | commit-id> command. You can use this to switch branches by passing in a branch name or view a specific commit by handing in the first 7 characters of a commit id.

But that's not all, you can also use the tilde (~) symbol followed by a number to go back from a commit to whenever back you want. So, let's say you want to checkout something that was written 2 commits from the "tip" of the branch, you can checkout into your branch and then git checkout HEAD~2. Voila. You are now viewing the project's state 2 commits behind the current branch.

(Btw, HEAD is the latest commit on your branch or the "tip" of the branch).

You don't need your current changes anymore for some reason

git reset --hard. git reset is a super useful tool to have but also quite dangerous if you are new. In this situation if you are certain that you don't need those changes you'll be fine, but this tool can bring a lot of pain if you aren't careful.

More on git reset

Now, git reset comes in two flavours, git reset --soft and git reset --hard. For now, I'll talk about the latter only, the former will be in a different example. Using the --hard flag clears the working area (deletes all your changes), leaving you with what you had when you checked into that branch (granted you didn't check in without changes).

Your boss wants you to fix Bug B yesterday, but you currently working on Feature D

OK, this btw, happens more frequently than one would want. So there's a couple of ways to fix this. Clone your project a second time into a second folder and do your changes from there. Or git stash -u.

I'm obviously assuming you choose the tech savvy method. git stash -u allows you to store your changes temporarily on the side whilst you either switch branches or do something else.

So in this situation, when you are currently half way through creating Feature D but the boss wants Bug B squashed now/yesterday, you can git stash -u (the -u flag makes certain new files are also stashed) and then you go on your business.

Now, when you need to use those changes again, you just git stash apply and done. Your changes are in. Something to note is that you can also use git stash pop which removes the changes entirely from the stash and puts them into your working area. This, of course, makes me queasy, so I avoid it. Because if something goes wrong when applying your changes, I always fear losing the stashed content. I know this probably won't happen, but I don't trust tech that much.

Your version of master/develop is ahead of the remote version and now git doesn't want to pull the latest changes.

This is quite a common issue, especially for newcomers. If you see git complain about differing git histories, then this solution could work for you.

This is unfortunately where git reset becomes very dangerous. By using the tricks learnt from the git checkout HEAD~2 and the git reset --hard examples, we can reset to the commit that had master's latest changes (e.g. if we are ahead of master by 2 commits then this should work, git reset HEAD~2). By default, git reset will use the --soft flag which leaves the changes that were in your commits in your work area (i.e. you don't lose the changes from what your code was only the commits).

The dangerous part is when you use the --hard flag, 'cause this will clear your changes after resetting, so you lose your commits and you lose your changes. If you reset to the wrong commit then there's no way back unless you had the foresight to backup the branch. Which is what I usually do when I'm using git reset. In a touchy situation.

Anyways, if you don't have your commits seating in a branch already but need to make sure your version of master isn't ahead of the remote version of master. Then use git reset HEAD~<number of commits ahead of master>. There's a good chance you still can't pull at this point. So your best bet is to stash your changes afterwards using git stash -u. Then pulling using git pull and applying the stash git stash apply. If you get any merge conflicts, that's good.

Abort! Abort!

If you want to abort a merge that's a bit too fancy for you git <command> --abort usually does the trick. Actually, you can use the --abort flag on many commands that wait for you to do x for process y to finish.

And that's all folks,...for now at least

If you have any examples to add, please add them to the comment section, also if you see any typing errors I would appreciate the heads up.