Ready to land that great new programming job? First, you better know how to use source code control, and the one you’re most likely to encounter is Git. But before you can successfully use Git, you need to understand some basic concepts. Let’s plunge in!

Branches and Merging

When you’re building software, you’ll often have different versions. You might have a new version that’s currently in development, and you might have a couple of older versions, each of which has a large customer base. At any time, you might need to fix bugs in any of these versions. 

In order to accomplish that, you effectively need separate sets of code for each active version. Using source code control such as Git, you can pick a version to work on at any moment. You simply “check out” the version you want, and Git updates the files in your directory structure to match the code for the version you need. Each of these distinct sets of source code is called a branch.

Branches aren’t just used for versions, however. You might be working on a specific feature for the new version of the software. Your feature isn’t ready yet, and so you don’t want all the other developers and testers to have the partially-finished code on their machines. You would start with a copy of the new version’s source code, and you would start a new branch. 

Branches can have names. Suppose you’re adding two-factor authentication; you might call your branch “feature-2fa.” The branch you started with might be called “develop.” After you finish adding the features, your code for “feature-2fa” would be mostly the same as “develop,” but there would likely be a few new source code files, and probably some changes to existing source code files. You would then combine your changes back into the “develop” branch. This process is called merging.

Staging Areas

This is a tricky concept that’s mostly unique to Git. As you’re working on a branch, making changes and adding features, you’ll likely have new files you create. By default, Git won’t recognize those files as being part of the repository (which is the collective name for all the branches and their files; most people use the term “repo” for short). Git only knows about files you explicitly tell it about; simply having a file in a directory that happens to contain a branch doesn’t automatically add it to the branch. 

Instead, you have to tell Git about the new files. To do so, Git maintains a system called “staging area,” which is like a room that will hold files until you’re ready to add them to the branch. When you want to add a new file, you add it to the staging area. Similarly, as you make changes to the files in the repository, you need to add those to the staging area. (Fortunately, Git makes that very quick and easy.) Once you have all your changes ready, you can officially save them to the branch. This process of saving them to the branch is called a commit.

If you look closely at this concept, you can see that Git maintains the branch separately from the actual files on your computer. That means you can make a bunch of changes to the code; add them to the staging area; make more changes; add those changes to the staging; and then finally commit all those changes as a single commit to the branch. (And yes, programmers use the word “commit” as both a noun and verb!) 

But suppose that, as you’re making more changes, you realize you’re doing it wrong and want to abandon those changes. Easy enough; you just grab all the last commits from the branch by checking out the branch again. Git will replace your abandoned changes with the most recent copy that was committed. And notice also that you’re checking it out right from the branch stored on your own computer, and no other computers are involved.

Commands

Ready to try it out? Make sure you have Git installed.

Then you’ll need a repository. You can make one yourself, but you can also download a practice one. How do you do that? You copy an existing one (a process called cloning). There are several practice repos out there, including this one (which also means creating an account on GitHub). To clone it, find the directory on your computer that you want the repo to be under; you don’t need to create a directory for the repo itself, just move to the parent directory that will hold it. Then type:

git clone git@github.com:grayghostvisuals/practice-git.git
cd practice-git

The second line is to switch into the repo’s directory. Next, create a new branch by typing:

git checkout -b testbranch

But replace the word “testbranch” with whatever you would like to call the branch. And that’s it! Now you have a new branch.

If you create a new file, you’ll need to add it to the staging area:

git add myfile.cpp

And finally, when you’ve made changes and added new files and want to commit all that from staging to the branch, type:

git commit -a -m ‘description’

But replace description with an actual description of your changes, inside single quotes.

Conclusion

Git might seem a little strange at first, especially if you’re coming from other version control packages. The key, however, is to practice, practice, practice. These days Git is everywhere, and many development jobs demand that you know it. If you're curious about how to add changes and check status, click on over to the next article in our Git tutorial series.