How to Use Git Branches to Structure Your Programming Project
Pinterest Stumbleupon Whatsapp
Advertisement

Movies and television portray programming as a frantic activity Hollywood Hacks: The Best and Worst Hacking in Movies Hollywood Hacks: The Best and Worst Hacking in Movies Hollywood and hacking do not get along. While real-life hacking is hard, movie hacking often involves just pounding away on a keyboard like your fingers are going out of style. Read More . A bomb’s timer counts down, and the nerdy sidekick who was a burden up until that point works feverishly on a laptop. Code flies across the screen until she hits the final return key with a satisfying clack! The timer stops, and all is right in the world again. But programming is nothing like that. It includes design documents, UI mock-ups, and code reviews. And more than anything it involves trial-and-error, especially if you’re a beginner (like me).

Now, you may already be convinced of the value of keeping your coding projects in source control What Is Git & Why You Should Use Version Control If You’re a Developer What Is Git & Why You Should Use Version Control If You’re a Developer As web developers, a lot of the time we tend to work on local development sites then just upload everything when we’re done. This is fine when it’s just you and the changes are small,... Read More . Committing all this trial and error to your repository will make for a large and untidy project, with many revisions. Most of the commits you make will contain stuff that’s broken, so why save it? The git branch feature can help keep all this messy code away from the stuff you know works.

In this article we’ll look at what branching your code means, how to do it, and ways to manage updates to the “main” branch.

Creating a Git Branch

We’ve learned from our introduction to source control Manage Your File Versioning Like a Programmer With Git Manage Your File Versioning Like a Programmer With Git Programmers created version control systems (VCS) to solve file version control problems. Let’s look at the basics of version control using the top system today, Git. Read More that you can create a new repository with the following command in a terminal:

git init

When you do this, it creates a hidden directory in your current path, called “.git.” If you can’t see it, consult some of our prior articles on viewing hidden The Easy Way to Show Hidden Files and Folders in Windows 10, 8.1, and 7 The Easy Way to Show Hidden Files and Folders in Windows 10, 8.1, and 7 Need to see hidden files and folders in Windows? Here's how to show them in Windows 10, 8.1, and 7 so that nothing is hidden from you. Read More files Hide & Find Any File On Mac OS X Hide & Find Any File On Mac OS X There's no straightforward way to quickly hide or reveal hidden files on Mac OS X as there is on Windows – but it is possible. Read More . This directory contains all the information needed to keep the revision history of your files. Once you set your file manager to show hidden files, you can open the .git folder and see a number of sub-directories. One of these is called “refs” (shown in the below image), and its “heads” sub-directory contains listings for all the branches in your project. At the outset you’ll have just one, dubbed “master.”

git branch dotgit refs

The refs directory keeps a record of the branch, but not the branch itself. At least, not the branch you’re currently using. Those files are kept in the working directory (“~/Temp/post-programming-git-branch” in the above example) so you can access them in a normal way. Doing exactly that, we create our first file (named “first-file.txt”) in the working directory, i.e. outside the .git directory. Check this in using the trusty commands from the prior intro to git article Manage Your File Versioning Like a Programmer With Git Manage Your File Versioning Like a Programmer With Git Programmers created version control systems (VCS) to solve file version control problems. Let’s look at the basics of version control using the top system today, Git. Read More :

git branch master commit

We can see now the working directory has two files, the one we committed, and one created automatically by git (it contains the commit message we just entered).

git branch master commit msg

Now, let’s create a new git branch called “testing”:

git branch testing

Checking Out The Branch, and Working in It

We can issue the above command without any names in order to get a list of all branches, as well as which one we’re currently using (i.e. which is “checked out”):

git branch create list branch

Now, if we examine the directory structure, we’ll see “.git/refs/heads” now has two files, one each for “master” and “testing.”

git branch dotgit refs branches

Each of these is a list of the commits that comprise the branch. For example, if we examine the “master” branch with the “git log” command, we can see a line for each of the commits made to that branch.

git branch log branch

The process of “checking out” a branch means that changes you make to files will be part of that branch, but not other branches. For example, suppose we check out the testing git branch with the following command:

git checkout testing

Then we add a line of text to first-file.txt, of course committing it afterwards. If you switch back to the master branch, you’ll find the file is still blank (the cat command displays a file’s contents in the terminal):

git branch switch branches master

But returning to the “testing” branch, the file still has the added text:

git branch switch branches testing

But all we ever see in the directory proper is the single file “first-file.txt.” Where then are these two alternate versions of the same file? The .git directory accounts for these changes, but not in the way you might expect.

How Git Stores Things

If you were to examine a repository for other version control systems such as Subversion, you’d find they maintain one copy per revision for each individual file. This means if you have a repository of one file, then create two branches, the repo contains two different copies of that file. In fact, you actually use “svn copy” as the command to create a branch in Subversion! On the other hand, git operates on the concept of “changes.”

git branch svn copy

The output of the above tells us the entire contents of “trunk” (SVN’s version of “master”) has been copied. A look in a file manager confirms this:

git branch svn copy fileman

The “.git/objects” directory is what holds all these little changes, and each one is tracked with an ID. For example, in the below image, you’ll see files with long ID-style names. Each lives in a folder named with two hexadecimal characters (8c and 8d below).

git branch dotgit objects fileman

Together, these folder and file names make up the ID for a particular change (actually a SHA1 hash). You can explore their contents using the git cat-file command. Based on their modified dates, we can see the one beginning “8d” came first, and it shows nothing. While the one starting “8c” contains the line of text we added to the file in the “testing” branch.

git branch objects gitcat

The takeaway is that git branches (including the default “master”) aren’t separate “folders” containing copies of files. Rather, they’re lists of changes made to files over time. This is more efficient storage-wise, but the result is the same. Anything you do (break?) in a git branch stays in there until you merge it.

Strategies for Merging Back to the Main Branch (To Delete, or Not Delete?)

Suppose you had an existing project with a number of files, which you then branched into “testing,” and did some work on it. Now you want to get those changes back into the “master” branch. You can do with the following from the “master” branch:

git merge testing

Provided there aren’t conflicts, the change consisting of the new text will be applied to “master.” The result is “first-file.txt” will be identical in both branches. Yet there were never really alternate versions of the file.

Now comes the question, what to do with the branch? There are two common strategies for dealing with branches.

How to Use Git Branches to Structure Your Programming Project git branch master develop

  1. One is to keep a git branch like “testing” to play around in (shown above). You try some things out and, if you can make them work merge the changes back into “master.” Then you can end work on that branch, or even get rid of it entirely. This means your “master” is the most stable version of the code, because it should only contain things you know work. You can also think of this approach as using “feature branches.” This is because their purpose is to refine one (or several) specific additions to the code.
  2. A different approach is to do all your main work in the “master” branch, making commits along the way. Once you’re happy with the functionality, you create a branch within it which you’ll do bug-fixing and the like. This results in more of a “release branch” (shown below), as they end with the release. It also means your “master” branch is typically the most unstable version of your code.

How to Use Git Branches to Structure Your Programming Project atlassian git branches

Use Whichever Method Is Best For You

The first approach here is more common when working with git. Its other features (specifically tags) make it easy to mark a particular snapshot of the code as “stable.” It also lends itself better to larger, collaborative projects. But when working on your own personal projects, feel free to use whichever of these makes the most sense to you. The great thing about using git is that you capture all your changes, so you can always go back and find something. And organizing your project with git branches makes that a little easier to do.

How do you approach branches in your projects? Do you use them to experiment, then trash them afterwards? Or do they represent a detailed history of your work on the project?

Let us know below in the comments if you have any clever ways of dealing with branches in your git projects!

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Jan
    December 30, 2017 at 11:39 am

    Great stuff, but when it comes to merging branches back into master it would be nice ro explain pull requests.

    • Aaron Peters
      January 3, 2018 at 5:17 pm

      Hi Jan,

      Good point, I'm actually planning on covering that in a subsequent article on multi-person collaboration in general. Thanks for the shout though!

      Aaron

  2. Thant Zin
    December 29, 2017 at 8:39 am

    Suddenly, you showed "svn copy" in the middle of explaining Git. But, one has no experience of SVN nor Git, that might cause a bit of confusion.

    Otherwise, this is a very good article.

    Thanks!

    • Aaron Peters
      January 3, 2018 at 5:18 pm

      Thanks Thant, I appreciate it!

      You have a point there, I only mentioned svn copy to illustrate the difference between how the two systems store things. But point taken.

      Aaron

  3. Nidisj
    December 29, 2017 at 5:42 am

    Great article - thanks!

    • Aaron Peters
      January 3, 2018 at 5:19 pm

      Cheers Nidisj, glad you liked it!

      Aaron

  4. Bob Noheart
    December 29, 2017 at 1:41 am

    We have trunk (our stable branch), devel (unstable branch), and feature/bug fix branches.

    • Aaron Peters
      January 3, 2018 at 5:20 pm

      Hi Bob,

      Yeah, this was getting a little long as it was, but I think some more in-depth explanation of how some places structure their branches would be useful info. I'll pitch it to my editor and see how it goes...

      Thanks!