When you're working on a complex project, it's nice to be able to keep track of the changes you've made. When you're collaborating with a group of other people, it's even more important.
Enter Git, a free open source version control system developed by Linus Torvalds, the father of Linux. It enables you to keep multiple snapshots of your text-based content so that you can go back and compare previous versions with each other. This makes it great for your own programming projects, so that you can document the changes you've made over time, but you can use it for other kinds of content too. Writers can also use it to document the changes to their prose, for example.
Git really comes into its own when used by multiple people at once, because they can copy a centrally hosted project to their own machine, make changes to it, and then copy it back. This is the basis for online Git-compliant services like GitHub.
Git works on Linux, Windows, and macOS. Install it with a simple command line install (sudo apt-get install git on Ubuntu), and then configure it by writing a Git config file. This file should at the very least contain your name and email address to stop Git bugging you for it later. Set this globally with:
| git config --global user.name "<Your Name>" git config --global user.email "<Your email>" |
The global config file is stored in the user home directory for your chosen OS. You can also use the --local flag to set separate configurations for a single project repository, or --system to apply the configuration for all other users of that machine.
Working with repositories
Git creates repositories for each project that you want to track on your system. A project is a group of files located in a single directory. Set up an empty directory called test_project and while inside it create a repository using git init. This creates a hidden .git directory in the same location that holds the metadata Git needs to maintain snapshots.
You can get a picture of Git's current state using git status. It will tell you:
| On branch master No commits yet |
Commits are snapshots of your files, and to create one we must first have a file. Create a file called test_file.txt containing the text "This is line one".
Checking Git's status again lists this as an untracked file. Git knows it's there, but isn't watching it for you. Change that using git add test_file.txt Now git status lists this as a file to be committed.
This file is now staged. Git knows this is a file we want to track, but it hasn't taken a snapshot of it yet. Let's do that now:
| git commit -m "create file" |
git commit is like triggering the shutter on a camera. It preserves a snapshot of that file as it is. The -m flag and subsequent text attaches a message to the snapshot so that we can remember the change we made to it. If you don't include this, Git will open your default text editor and make you type one.
git status won't list the file anymore because it's all up to date in the git repository. However, as soon as we make another change to the file and check the git status, the file is listed once again under changed files not staged for commit. You must git add that file again before committing it for a second snapshot.
Try this by adding a second line to the file: "This is line two". Then type git status to see its changed stage and git add test_file.txt again before committing it with:
| git commit -m "add line two" |
You can easily see what you've done to files in a repository over time by listing the history of your commits:
| git log |
This shows you the unique ID for each commit, along with the date, the author, and the message.
What if you want to go back and look at an old version of a file? Find the commit ID for that file in the log and then check it out by using that ID with this command:
| git checkout <commit ID> |
Note that Git now says it is in 'detached HEAD' state, back at the first commit. The HEAD is the most recent commit in your history (think of it like the head of an old cassette player as it reads its way through a tape). Checking out another commit means moving away from the HEAD back to another point in history, like rewinding the tape.
Now, if you open test_file.txt in your text editor, you should see the original version with just line one. Close that file and restore your HEAD using:
| git checkout master |
Your file will be restored to the most current version.
Branching out
Checkout isn't just useful for looking at old snapshots. You can also use it to create and work on new branches. Git is like a tree, in that repositories have a central approved 'trunk' called the master, along with branches that you can create to work on side projects. Let's say you want to go back and rewrite a chunk of your web application to use a new JavaScript engine, or rework chapter 3 of your novel. Instead of changing your approved master code immediately, you can create a branch to work on. Do this now:
| git checkout -b test_branch |
This checks out the branch (moving the HEAD to the front of that branch), while the -b flag automatically creates the branch at the same time. Typing git status tells you you're on that branch. Now, add a file called test_file_2.txt with the line "First line". Then:
| git add test_file_2.txt git commit -m "create test file for this branch" |
List the files in this directory and you'll see your two files: test_file.txt and test_file_2.txt.
Now go back to the master branch:
| git checkout master |
List the files again, and test_file_2.txt has disappeared. What happened?
When you branched your project, you created a shadow copy of all the project's tracked files, enabling you to work on them and make all the mistakes you want without disrupting the master project. However the master branch can't see changes made in the branch because it's separate.
Once you've finished making changes to the branch, you'll often want to merge them back into the main master trunk. You can do that by making sure you're in the master repository and then using this command for our test_branch:
| git merge test_branch |
Now, if you list the files in your directory, you can see the test_file_2.txt file from your branch. Now you can delete that branch with git branch -d test_branch.
There are lots of other things to learn about git, including cloning a remote repository from a place like GitHub using git clone. This lets you quickly copy an entire project to work on locally. You can even send changes that you've made locally back to the remote repository. You can use git as a powerful tool not only to keep track of your own projects, but to work on open source projects with a large community of other contributors. And because it's free, it's easy to git started.
