Git toolkit for your first job as a Software Engineer

Commands you’ll need for working with a dev team

When you’re new to the world of software engineering there are a few fundamental skills you need to acquire to do you job. Git is one of those skills.

I’ve now been a software engineer at Checkr for over 2 years (!), but during my first month on the job it seemed like there was an ever-expanding list of things to learn or skills I was deficient in. Like most Jr devs who had been building their own toy apps, I was familiar with basic Git commands to add and commit, but since I had never worked on a team with other engineers, I wasn’t comfortable with branching, merging, and fixing merge conflicts. Once I learned these commands I wrote a blogpost. For some reason, I never published it.

I’m managing an intern this summer, and on his first day I was reminded of all the things that were confusing to me when I first started. I dug up this old post, and decided it was still completely relevant.

*****

I started my first job as a Software Engineer at Checkr this past month. The first few weeks have been very exciting, as I’m getting to know my team and the company’s product, but they’ve also been intense. There is a huge void between the skillset I developed at Hackbright and the skills of a professional software engineer. While there are an abundance of blogs that discuss getting into bootcamps, doing well in bootcamps, and getting a job after a bootcamp, there are far fewer resources advising bootcamp grads on how to succeed in their first job, which skills to learn, and how to go about doing so. For this reason, I wanted to document my learning process as a junior developer and share my growing technical knowledge.

I decided that Git was a good topic to start with because it’s something that all developers will use on a daily basis regardless of their company’s tech stack, and there are just a few commands that will take your git skills from novice — I can git add git commit git push and pray I don’t run into any errors — to intermediate — I’m comfortable branching, merging, and editing my commits.

Branching

Branching is the first essential Git concept you must learn in order to work on a software team. When working on personal projects, you can easily commit to master. But when you’re on a team with others, you only want to commit code to the central branch that has been cleaned and reviewed by your teammates. While you’re still developing and debugging code, you should commit to a personal branch.

A branch takes the state of a repository at some point, splits it off, and allows you to develop and commit code without affecting the master. After your code has been approved, you can merge your changes into master and delete the branch.

When working on a team, it makes sense to name your branch using your name and a short description of what the branch is aiming to accomplish. This is how we create a new branch, called “michelle/new_feature” and switch to it:

git checkout -b michelle/new_feature

Now, if we run git branch we can see a list of all branches in the repo. To switch back to an existing branch like master, we can use git checkout master. Before switching branches, make sure to add and commit any changes on the current branch — git will complain if you don’t. Think of the checkout command as a way to “check out” edits that have been made in different branches. You can also use git checkout to view the state of a branch at a particular commit using git checkout <commit hash>.

Warning! If you have files open in an editor like Sublime Text or Atom while switching branches, it will appear as though those files have unsaved changes. Don’t fret — your most recent edits have been safely saved and committed on your last branch, but they appear as new changes on the current branch. You DO NOT want to save these changes to your current branch.

Another warning! Remember to switch to master before making a new branch (unless you intended to branch from another branch). I’ve made this mistake before, and to fix it you need to rebase onto your master branch.

Rebasing

Once you start working in branches you will inevitably fall behind on master; Other people on your team will commit new code to master before you’ve finished your feature. You now want to incorporate these new developments before making a pull request on your feature branch. This is where rebasing comes in.

Rebasing allows you to go back in time and replay the most recent commit history, making any necessary changes.

Rebasing is used for many reasons, but let’s first solve the example I just mentioned — catching your feature branch up with master. The steps are 1) go into master and pull down the must recent changes and then 2) switch back to our feature branch and insert those changes underneath the new commits we’ve made on our branch. You are essentially replaying your most recent commits on top of master’s new history. The code would look like this:

git checkout master
git pull origin master
git checkout michelle/new_feature
git rebase master
Before:
          A---B---C michelle/new_feature
         /
    D---E---F---G master

After:
                  A'--B'--C' michelle/new_feature
                 /
    D---E---F---G master

Editing commits

Editing commits can be very powerful, but with great power comes great responsibility. We are essentially rewriting our Git history, so we want to make sure we actually want to make changes.

One way to change our Git history is to simply edit one of our commit messages. We can do this using the -i flag for an interactive rebase session. We pass in an argument for the file before the one we want to change. This tells Git where to start replaying our history. In the case below, we want to edit the most recent commit, so we pass in HEAD~1 which refers to the commit before HEAD

git rebase -i HEAD~1

After entering the command above, you’ll see an option menu appear:

If we select r (for reword) and save:

Git will allow us to edit the commits message in our editor:

Squashing

I was really excited about squashing my first day of work. Squashing allows you to take several commits that you’ve built up while developing and squash them into one pristine commit to put in your pull request.

Similar to editing a commit message, we use the git rebase command in interactive mode and update the verbs before each commit. We want to pick our first commit and squash subsequent commits into it.

Git accepts abbreviations for these commands, so we can either type “s” or “squash”

Once we save, Git allows us to edit the commit messages for the two commits — we can keep one message, both message, or write an entirely new message. Then Git combines the changes from the two commits and assigns a new commit hash.

Stashing

Stashing is another really nifty tool. It allows you to stash away some uncommitted changes in a queue and pop them off at a later time.

When might you use this? Sometimes you accidentally make some edits on the wrong branch. If you catch your error before you’ve committed the changes, you can stash the changes, move to the correct branch, and pop them off there. Another example is if you want to checkout another branch but aren’t ready to commit your changes on the current branch.

git stash
git checkout -b 
git stash apply

Stashing is useful for storing away changes for a short period of time while you do some other task, but they’re easy to lose track of, so try to deposit them in the correct branch as soon as you can. Some other useful stash commands are git stash list and git stash show to list and inspect stashed changes.

Conclusion

Git is an intricate and complex software. For most software engineers, learning Git does not spark joy — you develop a medium level of competency and hope you rarely have to search the docs for something fancy to get yourself out of an intricate version control hellhole you’ve dug. However, you can accomplish most daily tasks on an engineering team with just the handful of commands I discussed above.