Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Modern Version Control With Git, Part 2

In the first part of this series1, I introduced you to the Git version control system. We looked at the history of the project, highlighted well-known open-source projects that use it (Ruby on Rails, jQuery and the Linux kernel), discussed its key features and went over a very basic workflow scenario. In this second part, we’ll go into more detail and get our hands dirty with a look at a real-world workflow.

Improve Development Quality Link

“Complex” is often used to describe the Git version control system2 (VCS). At least compared to classic VCS’ like Subversion, Git does indeed have a steeper learning curve.

When inviting people to learn a “complex” new technology, you’ll hardly get volunteers. But what if the technology could improve software quality and maybe even your own way of developing software? Git is such a technology for which investing time is worth it. Moreover, desktop clients such as Tower3 for Mac OS (disclaimer: this is the author’s product) and Tortoise Git4 for Windows make a lot of the tasks easier.

Installation and Help Link

If a recent version of Git is not installed on your machine, you can quickly and easily catch up by, for example, reading the instructions in Scott Chacon’s free eBook Pro Git5. I’ll mention commands only briefly in this article. To get more detailed descriptions and parameter listings, you can use git help <command> in the command line or browse the GitRef6 online.

Creating And Cloning Repositories Link

Having a repository is the most basic requirement for working in Git. If there is not one for your current project or if you’re starting afresh, then create a new repository in the current location by executing git init in the command line. If a remote repository already exists on a server, then you can get it via git clone on your machine. You can learn more about git clone on the GitRef website7.

Committing Changes Link

After working for some time, you’ll have a couple of new, deleted or modified files that you’ll want to save to your local repository as commits. As a first step, we’ll use git status to show us which changes we currently have in our working directory.

To add certain changes to the next commit, you have to explicitly add them to Git’s “staging area.” The command git add is used for this purpose. Let’s look at a concrete scenario:


git add Link

The paragraph that begins “Changes to be committed” lists all of the files that will be included in the next commit. The changes had to be added to the staging area via git add.

The paragraph that begins “Changes not staged for commit” lists all of the files that have been changed but that have not been added to the staging area. Therefore, they won’t be included in our next commit but will remain simply as changes in our working directory.

The last paragraph lists “Untracked files,” files that aren’t under version control yet. In other words they are unknown to Git.

You might have spotted a little peculiarity: error.html is listed twice! That’s because we staged some of the changes in this file, while leaving other changes in the same file unstaged. This feature — staging individual files or even parts of a file — enables us to create extremely granular commits that really only contain related changes.

git commit Link

After having composed the commit exactly as we want it to be, we can save it to our local repository via git commit.

Commit History Link


Once a repository contains a couple of commits, we should look into its history (or “log”). The git log command gives us an overview of the last few commits. Git log’s default output shows each commit with its SHA-1 hash (which is the equivalent of a revision number in a classic centralized VCS, or CVCS), its author, the date and the message used.

Customizing git log Link

You can bend the presentation of git log almost completely to your will. Using the parameter --oneline, for example, reduces the output to a single line per commit. Using -p adds the “diff” (or patch) to every commit, thereby showing you what detailed changes were introduced. Customization can be taken to the point where you have your very own output format:


Branching And Merging Link

Branching is often referred to as Git’s killer feature, and rightly so. If you already know the term from another VCS like Subversion, then take an unbiased, fresh look at the topic. Using branches in Git is extremely easy and fast because they have been a core feature since the very beginning. They’re certainly one of the most important tools in a developer’s daily work. But what are they actually used for?

Branches allow you to cleanly separate variants or features in your code base. “Separation of concerns” is a good term for this.

When to Use Branching Link

Take the following scenario. At a certain point, you decide to develop a new feature. To separate it from your other development work, you create a new branch, based on the current status. The git branch command creates the new branch, while git checkout makes it your current working branch.

After having implemented a couple of new features, you commit the current status to this branch (C2 in the sketch below). But you haven’t yet finished developing the new feature when an urgent bug report forces you to continue working on your code’s main line (your production or “live” code).

After having switched back (via git checkout) to your master branch, you commit the fix for the problem (C3). Again, you switch to your feature branch and commit some more changes (C4) to complete the development for this feature. Finally, you use git merge to unite the two branches again (C5).


Imagine this scenario without branches. Because you already had changes that belonged to an unfinished, not yet releasable feature, you would have been mixing two different concerns (the experimental feature and the bug fix in your production code).

With only one feature, the problem might not have been major. But in larger projects, with numerous parallel features and development stages, such processes quickly become confusing and error-prone without branches.

Of course, Git is not the only VCS that uses the concept of branches, but it does make branching easier, faster and more effortless than any other system. As soon as you discover branching in Git, switching your active branch a dozen times a day or creating a new branch for every bug fix, however small, becomes totally run of the mill. Greater clarity and a clear separation of code is worthwhile in the long run.

The currently active branch is called “HEAD” in Git. Switching the HEAD is done with the git checkout command (not related to the checkout command in SVN). Your working directory will then contain the files that belong to this branch (or, more precisely, that belong to the last commit in this branch).

Sharing Code: Working With Remote Repositories Link

Remote repositories are used to make your code available to teammates and to integrate code from other developers into your local repository. With git remote add, you can connect any number of remotes to your local repository.

To publish local commits from your current branch to a remote repository, use the git push command.

Integrating remote changes into your local repository, on the other hand, is done via git fetch. This downloads all of the changes from the remote server to your local computer, but it does not modify the files in your working directory in any way!

You can decide for yourself when to integrate the downloaded changes into your current HEAD via git merge. Alternatively, you can use git pull to combine downloading and merging into one step.


What’s Next? Link

In the third and final part of this series, we’ll look at some more advanced concepts of Git, and highlight some useful tips and tricks.

(al) (kw)

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


Tobias Günther is CEO and frontend developer at fournova. With his team he develops the Git desktop client Tower for Mac OS X.

  1. 1

    MVC with git :P

  2. 2

    Andrew Pryde

    August 3, 2011 4:41 am

    Git is definitely the king of version control in my humble opinion though I have never seen the necessity for a visual interface when git has such an straight forward command line syntax.

  3. 3

    Luca Degasperi

    August 3, 2011 4:49 am

    What about some hands on with git. There are many difficult terms and mechanics in git, an article about working on an example project step by step could be the definitive guide to git!

  4. 4

    Bob the Builder

    August 3, 2011 5:17 am

    What terminal font is that in the screenshots?

  5. 5

    Thank you for this, it came at just the right time, as I’m planning to switch from subversion to git very soon. Some advice for switchers like me would be much appreciated in the next article :)


↑ Back to top