Learn to love Git. Part two: making changes.

❤ Yes, you can learn to love Git. ❤

In part one, we talked about the basics of Git and getting things set up. You learned about Git, in general, the difference between remote and local repositories and how to get a project set up for collaboration with Git. Now we’ll go over how to make and commit changes to your code.

Now that you’ve got a project set up on your machine, we’ll work on how to use Git to manage making changes safely and tracking your work. You’ll be able to use whatever text editing method you’d like to create, change, move, copy, rename or delete files within your local repository.

Keeping things in sync

Before you begin to make changes, you’ll want to make sure your local repo is in sync with your remote repository. To get that going we’ll “git pull” the remote repo, which, along with “git push” is how you keep remote and local repos in sync.

Open Terminal and type the following:

git pull origin master

This tells Git to go to your remote repository, check to see if there are any changes, and then pull those changes down. It’s a good idea to do this before you make changes, even if, as in this case, you’re pretty sure there’s nothing new to get.

Ok, now let’s add a new file!

Within the “recipes” folder you’ll see more folders containing, yep, you guessed it: recipes. To get an idea of how Git works, let’s add a recipe of your own.

This is as simple as creating a new file, within any directory inside of your local repository. You can do this however you want (no need to use Terminal, for example) but let’s say you wanted to add a recipe for sous vide pork chops, you would go back to Terminal and enter the following commands:

cd recipes
cd foods
cd meats
touch sous-vide-pork-chop.html.md

The above shows navigating to the “meats” folder and using the “touch” command to create a new file. You could do it via Finder or any other way, the idea is to get an empty file with an html.md extension for you to edit and add your recipe. You can also just copy one of the existing files in that directory, edit it and save it as a new file. That might be the easiest way. The good thing about Git is that you can’t really hurt anything.

Now open that new file in a text editor (I prefer Sublime), add a recipe, and save it. You’ve now added a new file to the project. The next thing you need to do is tell Git to keep track of that file.

Adding and tracking files

“git add” puts files into the staging area. “git commit” records a snapshot of any changes within those files to the project’s Git history.

In general, Git has two ways it looks at files:

Untracked: these are files that are not yet under version control. This means that Git is not watching this file for changes. The file could be new, or something you simply don’t want Git to pay attention to.

Tracked: these are files that Git is watching to keep track of changes.

Right now this new file is untracked. We need to tell Git to start tracking it. Type the following into Terminal.

git status

This will give you the current status of your local repository and an overview of any changes you’ve made. You should see something like this:

Git status shows you the current status of your repository.

That line in red is the new file. Git is telling me that, as of this moment, it’s not tracking it. Let’s fix that with the following command.

git add sous-vide-pork-chop.html.md

The “git add” command tells Git to begin tracking changes in that file. What you’ve done here is add the file to the “staging area” to get it ready to commit. You could continue to make changes to it, and Git will record them, but they are not added to the staging area. It can get a bit complicated, so let’s see what that looks like. If you make a change to the file, such as adding an ingredient, and run:

git status

You’ll see something like the following, with your original change (the new file) showing as “ready to be committed” and the new change (the modification) as “not staged.”

Git has staged the new file, but hasn’t yet tracked the modification.

If you run “git add” on that file again, the modification will be staged as well. Assuming you’re done making changes for now, you’ll be ready to commit those changes. Go ahead and do that now.

Committing your changes

Using the command “git commit” lets you tell Git that you’re ready to “save” your changes. It will round up any changes you made and added (via “git add”) and move them from the staging area and save, or “commit” them to the project’s history. This might sound more permanent than it is. A commit is really just a marker in time, a snap shot of the current state of your repository, where Git takes all the changes you’ve staged and records them.

Let’s see what that looks like. Type the following into Terminal, replacing the text in quotes with whatever makes sense to describe your recipe or changes:

git commit -m "added sous-vide pork chop recipe"

Here’s how that breaks down. “Git commit” is the command. The “-m” is an option that tells Git you’re going to leave a message along with your commit. The bit between the quotes is the commit message. A best practice for committing files is to give them a descriptive message, explaining what you’ve just saved. This is helpful for a variety of reasons, and doubly so when you’re working with others on the same project.

You’ve now saved your work into a commit and, if needed, you could revert your changes back to before you made any changes. Each time you commit your staged changes you’ll be recording a snapshot of your project, thus safely saving your work.

The “git add” and “git commit” commands are the building blocks of the Git workflow, used to record all changes made to a project into the repository’s history. They’re also the primary commands you’ll be using when collaborating with others, which we’ll cover next time.

Pushing your changes up to a remote repository

Now that you’ve added a file and some changes to your local repo, you’ll want to sync those back up to your remote repository on Bitbucket. This is known as “pushing” and is essentially the same as pulling but in reverse. Type the following:

git push origin master

This pushes your local changes up to “origin,” which is the remote repository you created on Bitbucket earlier. “Master” is the main branch of that repository. Don’t worry too much about that now, I’ll explain that in detail later.

The general Git workflow goes something like this:

Make sure your remote and your local repositories are in sync → make some changes to your project → use “git add” to stage those changes → use “git commit” to commit them → push your changes back up to your remote repository.

That’s it for part two. In part three we’ll dive deeper into how Git helps you collaborate with others.

Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.