You want to leave your ? job to become a web developer. I want to help. Head over to Rad Devon to sign up for a free mentoring session!

Git Basic Workflow

We’ve looked at a quick example of how you might commit, but we missed a lot of the context around that. Let’s look at a simple workflow for how you might use git.

git init

The first step is to initialize a git repository. The repository is just the container that stores all the version history for a project. You do that by navigating to the project directory on your computer in the terminal and running git init from there.

You can do this just after you’ve created a new directory for a brand new project, or you can do it in an existing project directory if you want to start using Git version control with that project. This is an important command, but you’ll only use it once per project.

git add

Now you have a repository initialized in your project directory, but it doesn’t know which files it needs to care about. By default, it won’t care about any of them. You tell it which files to track using git add.

You could just start adding files one by one until you have added everything you care about, but that sounds like a lot of work. You probably want most of the files under version control. Wouldn’t it be easier to tell Git which files you don’t want it to care about and then add everything else? Fortunately, Git has a way to do that too.

Create a text file in the root directory of your project named .gitignore. (Take the note of the leading dot. This makes the file invisible so that it doesn’t clutter up your directory listings. If you leave it out, Git won’t know what to ignore.) This is just a standard text file. Each line is a file pattern. Git will ignore any files matching any of these patterns.

These patterns are the same kinds of patterns you use in other terminal commands. Maybe you’ve deleted all the text files in a directory by using rm *.txt. *.txt is a file pattern. They can have wildcards (like *) that match anything, or they can simply be the name of a file or directory (like node-modules). If you want to know more about the .gitignore file, check out the Git documentation.

? Which Files to Ignore

You know how to ignore files now, but it may not be obvious which files you’d want to ignore. In general, you only want files that you have written yourself in source control. In a simple project like just some HTML and CSS, that might be everything. If your project has dependencies or gets built inside the project directory, you would want to ignore those. You’d also want to ignore any editor configuration files or any files that are specific to you or your computer.

Here’s an example .gitignore file from a GatsbyJS project:

node_modules/
public
.gatsby-context.js
.DS_Store
.intermediate-representation/
.cache/
yarn.lock

node_modules is ignored because it’s where dependencies are installed. public gets ignored because that’s where the project gets built. .DS_Store is a file macOS creates in every directory. .gatsby-context.js is generated automatically by Gatsby. yarn.lock should be in version control according to Yarn, but Gatsby’s project scaffolding adds it to the ignore file.

If you have all the files you don’t want in version control ignored using a .gitignore file, you can now add everything else with git add ..

git status

git status shows you which files are staged, which have changes that aren’tstaged, and which files are not yet watched (but also not ignored). I run it pretty often between other commands just to see exactly what state everything is in and make sure I haven’t accidentally staged something I thought was ignored.

git commit

Once you have some changes (or newly added files) staged with git add, you’ll create a commit with git commit. Again, this creates a snapshot you’ll be able to revert back to if something goes wrong. A commit can capture a single save to a single file. It can capture multiple saves to a single file. A single commit can represent one save each to many files or many saves to many files.

When you’re thinking about how often to commit, keep in mind that you won’t be able to get back to any state between commits. If you do a week’s worth of work but forget to commit, committing once at the end, the only history you have is a single commit for all that work. That means, if you need to revert, you can either revert the entire week’s work or none of it.

The Git Loop

Now that you have your project in place, you’ll start going through the Git loop. Here’s what it looks like:

1. Make your changes
2. Save them
3. Stage your changes with git add
4. Commit changes with git commit
5. Repeat

You’ll occasionally run git status to make sure everything is tracked and staged as you’d expect, but, otherwise, this is the bulk of your Git life as a web developer. You don’t know everything you’ll ever need to know to use Git (You can’t even revert changes which is core to the value of version control.), but you probably won’t need to do anything else for a while. When that time comes, use your search skills to find the commands to accomplish the task in front of you. (It’s one of my core principles of becoming a web developer: learn what you need to know just in time!)

Building a Git Habit

Your challenge for now is to build a habit around using Git… even when you don’t need to. You’ll need to be using Git when you really screw something up, but, once that has happened, it will be too late to start using it.

Make sure each new project starts with a git commit and you’re committing as you go. Get into the habit now so that when the day does come that you need to go back to last week (and it will), you’ll already have your Git safety net in place.