Anything remotely related to git heightens my anxiety, I don’t know why but there is always this element of the unknown when it comes to git that’s stayed with me from coding boot camp. In an attempt to mitigate my fears, I’ve started chipping away at all the capabilities this versioning language offers. Let’s talk about git checkout!
git checkout
The appeal of using git is that you have access to a non-linear stream of work. You can access your work from yesterday, make changes and choose to use that version; you can make a copy of your work (branch) and make changes that won’t affect the original. Git checkout helps you navigate the versions of your repository. There are three things git checkout can navigate:
1. Branches
2. Commits
3. Files
git checkout <branch>
If I create a new repository, I will default to the master branch. This is the base branch; if I don’t create any other branches, all my commits and workflow will be linear. Let’s say my project involves multiple people working on varying features, having a linear workflow would not be ideal. My commits would overlap with Bob’s and the shared history would become very complicated. So I create a branch from master:
> git checkout -b "New-Branch"This command creates a new branch “New-Branch” and then redirects you to that branch. You can go back to the master branch or any other existing branch with git checkout <branch-name>.
git checkout <commit>
For many of my pet projects, I will undoubtedly arrive at a situation where I wish myself back to the day before when my code was working, where today it does not. Well, thank goodness for git checkout, because it allows me to time travel! Take the following series of commits:
5736f5a - Added even more code... ooops, it's broken
fe9848c - Added more code, but it's still working
ba7ce11 - Code is workingAt commitba7ce11 and fe9848c I know my code was working. So I want to go back to those commits and see if I can track down where I went wrong, or how I can solve my problem in a way that won’t break the app.
> git checkout ba7ce11You might see a message like this:
Note: checking out 'ba7ce11'.You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout.If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example:git checkout -b <new-branch-name>HEAD is now at ba7ce11 Code is working
And in your terminal you may see ((HEAD detached at ba7ce11)) instead of your branch name. You’ve checked out of your branch to your previous commit. If you want to save the changes you make to the commit, then you can create a new branch.
git checkout <file>
This command really saved me when I started working at my first job. Up until that point, most of the projects I worked on were my own or were with one other person. I hardly ever encountered major discrepancies from the github repository. However, ever since I started working on a project with 20+ engineers, I can’t tell you the number of times I had to rope another engineer into helping me resolve why the code wouldn’t work on my computer.
After a Sprint I like to update my local repositories with any changes that might have been merged into the master branch, and many times that might mean an npm install. Weird, why is my package-lock.json showing up as being modified? All I did was pull down the master branch in Github to my local computer. Wait, why isn’t anything working anymore?!!!
> git checkout package-lock.jsonMagic, the file reverts back to the version I pulled down from Github (the upstream master). Hurray! I used this command plenty of other times when I wanted a quick revert back to before-I-wrote-broken-code. You can even checkout to a past version of the file (so like a git checkout <commit> but only for the specific file).
Check(it)out
There are a lot of things that git checkout can do for you, but I know that it has saved me from myself plenty of times. Add that to your list of tools to consider the next time you want to traverse your code history!