Git 101

Sunday, Dec 13, 2020

by Jeff Rainey

Git is one of those tools that is really intimidating for new users and fills them with dread. I felt this way and used to only work exclusively within a Graphical User Interface ( GUI ). But, using the GUI version without understanding what is happening can be dangerous and lead to more confusion and problems. This post is meant to explain the basics of using Git in the command line, mainly from the perspective of how I use it. I find myself having to explain these things to some people I work with and now this can be the place I point them to in the future. Time to dig in. 🚀

Before diving into using git it is important to understand the basics of what is happening to the code. One thing that helps here is using Git in the command line. I know that can seem intimidating and I once felt the same way. GUIs have come a long way and are powerful but at the end of the day, they are limited and leave you in the dark as to what is actually happening.

Under the Hood

The Git Repository

Your repository ( repo ) is not only a remote copy of your code but also a version control system with a full history of all changes that have ever been committed along the way. Github is the most popular Git repository service but there are others like BitBucket, GitLab and SourceForge. You could even host your own Git repo if you are up for a deep dive. For the purposes of this post, I will be referencing GitHub.

New Repo

To get started, create a Github account and click the “new” button to make the first repo. Give it a name and decide if this is a public or private project. Another way to do this would be to start the code on your machine and do a git init in an empty directory. I may run through that flow later in another post.

Git Clone

Now there is a repository for the project and it is time to clone it. Copy the URL from the project home page on Github. For now we will only worry with the https option. Then in the terminal, type the following with your URL and project name. Note: new-project creates a directory with that title and places the files here ( make sure you change “new-directory” to something meaningful to yourself ). Change directory ( cd ) into the new project and you are good to go.

git clone https://github.com/CDCgov/react-starter-kit.git new-project

cd new-project

Creating Your First Branch

While it is tempting to work from master, working on branches is an important habit to get into. Working on a branch essentially freeze the codebase while working on a feature or bug. Changes from master can always be merged in as commits are made on this new branch to stay current with what is going on. Creating a branch in the command line is done like this:

git checkout -b new-branch-name

Different teams have different naming conventions associated with branch names. These may correlate to work tickets or are possibly prefixed with the work type, ex: feature/mobile-nav. Having a naming convention can be nice to make switching between branches faster in the future.

Adding Changed to be Staged

Adding your changes to be staged simply means that you are choosing the files that you want to commit. There are a few different ways that you can add files to be staged. You would only do one of these and -A and -p are two I use often.

// Add a single file
git add .

// Add all changed files
git add -A

// Add files but let me see the changes in each one before I actually add them
git add -p

// Add files with shortcuts to other commands
git add -i

Committing Your Changes

Committing code changes means the code is being added to the repository history with comments about the changes that have happened. Comments are important and should be as detailed as possible. These will let others know what is happening or, if running solo, will explain to future you that may forget what happened a couple of months ago.

// Commit your work
git commit -m 'Message about your changes goes here'

Pushing your Changes and Branch to the Repository

Once all code changes are committed, the new branch needs to be pushed to the repository. If a new branch was created like discussed above, the repository will need to know about this branch. This can be done like this:

git push -u origin new-branch-name

Once the branch is in, a Pull Request ( PR ) needs to be made against the working branch. This can be done using GitHub’s GUI and often will require a review, depending on the setting of the repo.

Going Deeper

This article barely scratches the surface of what is possible with Git, but does provide enough to get started using it. This free ebook goes much deeper into Git and explains each function in extreme detail. I would recommend this book as more of a manual rather than a page turner: ProGit ebook