GIT is a distributed VCS (version control system) which emphasize speed. Most people forget that a version control system is not just for working with programing codes, but with any type of file that needs to be versioned. Thus GIT can be useful for anyone who wants to maintain and manage versions/changes to any file type, whether it may be a source code, a textual document (for example, your graduation thesis), images and so on. Exactly, it can help from a student to a graphic designer or a developer.
At this point you ask me, "But what about the infrastructure to maintain a version control system?", this is another point that everybody is wrong about! You can use Git only on your desktop, without relying on a server, but of course it also works remotely using the client-server model.
So I’ll be creating a series of articles called in which I have the intention to help all those who want to learn how to use this powerful tool. So join me in this series where I’ll teach (and learn) how to install, configure and use GIT, either locally (on your desktop) or remotely (through a server).
What a VCS Is?
Before speaking about GIT is really important to point out what a VCS is. In order to accomplish this task I’ll ask a Wikipedia a little help…
A VCS, version (or versioning) control system, is a piece of software which aims to manage versions of a generic file during it’s production process. This systems are commonly used during software development to control different source code and documentations versions.
The main advantages tracking changes using a version control system during software development or development of any document are:
- History Control: We can analyze the development history and easily undo changes when needed, as well as recovery of older stable versions. Most implementations allow us to analyze the changes in detail, since the first version to the last.
- Team Work: A version control system allows multiple people to work on the same set of documents at the same time and minimizes editing conflict issues. It is also possible to have a sophisticated control of access for each user or user group.
- Stable Versions Marking and Rescue: Most systems allows you to mark where the document was a stable version, providing an easy way to retrieved in the future.
- Project Branches: Most implementations brings the possibility to split the project into multiple lines of development that can be worked in parallel, without interfering with each other.
Basically a VCS uses a "repository", which is a place to store files that need to be versioned. This repository is usually located on a server, but can also be located on your own machine. The main idea of a VCS revolves around the following process:
- Retrieve a copy from the remote repository;
- Make changes in the files;
- Make a commit, confirming the changes and inserting a message to describe them;
- Send the changes back to the remote server.
Besides GIT there are many other version control systems like free CVS, Mercurial, Git, SVN, RCS, Bazaar, among others.
For more information about the CVS concept I recommend reading this Wikipedia article.
What About GIT?
GIT was initially developed by Linus Torvalds to assist in the development of the Linux kernel. It is an open source free software developed in C, Shell Script and Perl and is currently distributed under the GNU GPLv2.
It stands out by its simplicity, flexibility and automate tasks (using hooks). It’s possible to automatically perform an JBoss application deployment after updating to the code repository, for example. But no hurry, we will first learn the basics, how to use GIT only locally (on your desktop) and latter we will learn how to use it on a server.
Installing and Configuring GIT
Installing GIT is really simple, for those who use Arch Linux the following command is enough:
$ sudo pacman -S git
For the Debian and Ubuntu users, and many other similar distributions (Linux Mint, Ubuntu, Kubuntu e etc.), use the following command:
$ sudo apt-get install git-core
After installing we need to configure your personal information to the GIT client. Exactly, in order to identify who made a certain change GIT needs a name and an email. For this purpose use the following command:
$ git config --global user.name "Your Name"
$ git config --global user.email "your@email.com"
But pay attention, these settings made above are global, which means that it will be used for all the repositories you may come to work with. If you must use another "identity" in a certain repository, use the following command inside this specific repository:
$ cd my_repo
$ git config user.name "My Other Name"
$ git config user.email "other@email.com"
Other optional setting that I consider extremely usefull is core.editor, which alters the default editor that GIT calls when you need to write your commits message. By default it calls VI, but since I got used to the VIM improvements, I rather change this settings:
$ git config --global core.editor vim
Colorful Git!
Other great GIT settings it the colored output, making easier to identify some specific contexts. To activate this functionality use the following commands:
$ git config --global color.branch auto
$ git config --global color.diff auto
$ git config --global color.grep auto
$ git config --global color.status auto
An example of GIT’s colored output is shown below:
Local and Global Settings?!
Thats wright, with GIT you can have global settings, witch work for all repositories, and local settings, that are only used within an specific repository. A local configuration takes precedence over a global setting, in other words, it "overrides" the global setting.
The global configuration is stored in ~/.gitconfig, while the local configuration is stored in $REPO/.git/config. In the next group snippets I’ll show, and comment, the setup of a global editor against a different local editor:
$ cat ~/.gitconfig | grep editor
$ git config --global core.editor vim
$ git config core.editor
vim
$ cat ~/.gitconfig | grep editor
editor = vim
This snippet shows that there is no editor set the GIT (as ~/.Gitconfig in line 1). After we setup the GIT to use VIM (line 2) then ensure that this setup worked fine (lines 3 and 5). Now let’s see how the GIT behaves in a different repository:
$ cd repo1
$ git config core.editor
vim
$ cat .git/config | grep editor
According to line 2, we see that the editor use VIM (because it is configured globally), although no local configuration was present (line 4). Now let’s configure a different editor just for this repository:
$ git config core.editor emacs
$ git config core.editor
emacs
$ cat .git/config | grep editor
editor = emacs
We can see that by changing the editor to emacs (without using the key --global) a new key was created in the local configuration file. As expected, the global setting applies to all repositories that do not overwrite this setting. For more configuration options see the section "Variables" in the command git config --help or man git-config. There are several interesting options such as compression, case sensitive, abbreviations, alias, diff options and many others.
In the next article I’ll show how to create a local repository, make some changes and (the fun part) go back in time! Untill then…
Comments
comments powered by Disqus