Version Control with Git - Introduction

In this series, I’ll be teaching you about the distributed version control system Git. If you’re not familiar with the concept of a version control systems and have never worked with one, I strongly recommend that you go through our series on SVN before starting with Git—particularly the terms we use to talk about version control. SVN is a simpler version control system and in that series, I explain most of the basic concepts of version control. Knowing SVN or some version control system is a prerequisite to understanding this series on Git.

Why Git?

Git a version control system that became widely popular in recent years; today it’s hard to find a workplace that doesn’t use Git to manage their code. So why Git? Other systems like SVN have been around for years. Git is different from other version control systems in that it is a distributed system. This means a much larger number of individuals and teams can use it without the problems that would arise with a large number of users in a system like SVN.

The major advantages of Git are:

1. The ability to work without being connected to the central server, or even without internet connection. With a system like SVN we need to work with one central server. With Git we can work completely locally—create versions, changes, and make commits. Then, when we reconnect, we can push everything to the server.
2. The ability to work with several servers at once. This is very relevant for open source projects. For instance, I can create my own version of the program on my own server, and update it on my server, while I simultaneously pull the updates from the original server. When I want to, I can easily update the version on the original server.
3. Pull requests. Smarter management of requests to merge code than SVN. This makes it much easier to do code reviews. It’s also better for teams that are separated by large geographical distances.
4. Git is based on differences (diff) while SVN is based on files. This makes Git’s performance much, much better. With Git, it’s really possible to effortlessly manage multiple branches, and the merges are also much easier. This is really important for agile projects that require more flexible merges.

Long story short, Git is significantly more suited to the needs of larger teams and agile projects that have teams spread out in different locations. If you’re working on a small team, or alone, and you’re working with older programming methods like the Waterfall model, then Git may be less suited to you.

In this article, we’ll look at installing Git, and some basic configurations.

Installing Git

If you’re working in Linux, installing Git is almost too easy:

sudo apt-get install git-all

That’s for Debian (for Fedora it’s just with yum, but still the same bundle).

In Windows, it’s still easy (relatively so). Follow this link, download the exe, and run it.

How do we check that it’s working? It’s easy. Open the console or cmd (Linux/Windows) and type git –version. You should see this:

$ git --version
git version 1.9.1

If you ran it and received this, awesome—everything is working. If not (especially if you’re on Windows) there are a few ways of solving the problem. The first is to install the GitHub software. We won’t use it in this guide, but it contains an excellent version of Git and you can run it as well from the cmd.

It doesn’t matter if it’s from the cmd or console—Git works the same way with both of them. In this guide, when I say console, I mean cmd as well.

After installing Git, You should put your name and email in the settings. Why is this important? Because then you’ll be able to see them in the log of the commits. (Not sure what commits are? That’s a good sign you didn’t go over the SVN guide yet.) Obviously, when working on a team it’s very important to know who did what.

The basic settings for Git work through the console:

git config --list

To enter our name and email, we’ll use the following syntax:

git config --global user.name "YOUR NAME"
git config --global user.email "YOUR EMAIL ADDRESS"

In order to see all of the settings, we use this command:

git config --list

On my computer for example, it looks like this:

$ git config --list
user.name=Ran Bar-Zik
user.email=ran@bar-zik.com

We can set more configurations. If a computer is under a corporate proxy, we need to configure the proxy. To do this we run:

git config --global http.proxy http://proxyuser:proxypwd@proxy.server.com:8080
git config --global https.proxy https://proxyuser:proxypwd@proxy.server.com:8080

From the moment we run these commands, all of the traffic for Git will pass through the proxy. The settings for Git can also go into a file called gitconfig, that is created automatically when Git is installed. For Linux users it’s found under:

~/.gitconfig 

In Windows, it is of course a bit more complicated, and it depends on the version. In Windows 7 is found in:

C:\Users\USERNAME\.gitconfig

You can access an editable version of the config file with this command:

git config --global --edit

But in general, what you need in most cases to get started is the name and email settings. In large companies, you’ll probably also need details of the project and various security certificates. In later stages, we’ll learn about all kinds of cool things you can do with git config. But for now, this is a good start.

In the next article we’ll learn about working with Git locally: create, commit, push, log, and all that jazz.

About the author: Ran Bar-Zik is an experienced web developer whose personal blog, Internet Israel, features articles and guides on Node.js, MongoDB, Git, SASS, jQuery, HTML 5, MySQL, and more. Translation of the original article by Aaron Raizen.