Whether you are a professional or an amateur developer, you've likely heard about the concept of version control. You may know that adding a new feature, fixing broken ones, or stepping back to a previous condition is a daily routine.
This implies the use of a powerful tool that can help you take care of your work, allowing you to move around your project quickly and without friction.
There are many tools for this job on the market, both proprietary and open source. Usually, you will find Version Control Systems (VCS) and Distributed Version Control Systems (DVCS). Some examples of centralized tools are Concurrent Version System (CVS), Subversion (SVN), Team Foundation Server (TFS) and Perforce, while in DVCS, you can find Bazaar, Mercurial, and Git. The main difference between the two families is the constraint—in the centralized system—to have a remote server where get and put your files; if the network is down, you are in trouble. In DVCS instead, you can have or not a remote server (even more than one), but you can work offline, too. All your modifications are locally recorded so that you can sync them some other time. Today, Git is the DVCS that has gained public favor more than others, growing quickly from a niche tool to mainstream.
Git has rapidly grown as the de facto to version source code. It is the second famous child of Linus Torvalds, who, after creating the Linux kernel, forged this versioning software to keep trace of his millions lines of code.
In this first chapter, we will start at the very beginning, assuming that you do not have Git on your machine. This book is intended for developers who never used Git or used it a little bit, but who are scared to throw themselves headlong into it.
If you have never installed Git, this is your chapter. If you already have a working Git box, you can quickly read through it to check whether everything is right.
Git is open source software. If you are running a Windows machine, you can download it for free from http://git-scm.com. At the time of writing this book, the current version of Git is 1.9.5. If you are a Mac user, you can download it from http://git-scm.com/downloads; here, you can find the
*.dmg file, too. Finally, if you are a Linux user, you probably have Git out of the box (if not, use the
apt-get install git command or equivalent). Here, I won't go into too much detail about the installation process itself; I will only provide a few recommendations for Windows users shown in the following screenshot:
Enabling Windows Explorer integration is generally useful; you will benefit from a convenient way to open a Git prompt in any folder by right-clicking on the contextual menu.
Git is provided with an embedded Windows-compatible version of the famous Bash shell from Linux, which we will use extensively. By doing this, we will also make Git available to third-party applications, such as GUIs and so on. It will come in handy when we give some GUI tools a try.
Open a prompt and simply type
git (or the equivalent,
git --help), as shown in the following screenshot:
If Git has been installed correctly, typing
git without specifying anything else will result in a short help page, with a list of common commands. If not, try reinstalling Git, ensuring that you have checked the Use Git from the Windows Command Prompt option. Otherwise, Git will be available only within the embedded Bash shell.
So, we have Git up and running! Are you excited? Let's begin to type!
The first step is to set up a new repository (or repo, for short). A repo
is a container for your entire project; every file or subfolder within it belongs to that repository, in a consistent manner. Physically, a repository is nothing other than a folder that contains a special
.git folder, the folder where the magic happens.
Let's try to make our first repo. Choose a folder you like, and type the
git init command, as shown here:
Whoa! What just happened? Git created a
.git subfolder. The subfolder (normally hidden in Windows) contains some files and folders, as shown in the next screenshot:
At this point, it is not important for us to understand what is inside this folder. The only thing you have to know is that you do not have to touch it, ever! If you delete it or if you modify files inside by hand, you could get into trouble. Have I frightened you enough?
Now that we have a repo, we can start to put files inside it. Git can trace the history of any gender of files, text based or binary, small or large, with the same efficiency (more or less, large files are always a problem).
And now what? Is that all? No! We have to tell Git to put this file in your repo, explicitly. Git doesn't do anything that you don't want it to. If you have some spare files or temp ones in your repo, Git will not be compatible with them, but will only remind you that there are some files in your repo that are not under version control (in the next chapter, we will see how to instruct Git to ignore them when necessary).
Ok, back to the topic. I want
MyFile.txt under the control of Git, so let's add it, as shown here:
git add command tells Git that we want it to take care of that file and check it for future modifications.
Has Git obeyed us? Let's see.
git status command, we can check the status of the repo, as shown in the following screenshot:
As we can see, Git has accomplished its work as expected. In this image, we can read words such as
unstage. We will look at them briefly, but for the moment, let's ignore them.
At this point, Git knows about
MyFile.txt, but we have to perform another step to fix the snapshot of its content. We have to commit it using the appropriate
git commit command. This time, we will add some flavor to our command, using the
-m) subcommand, as shown here:
Press the Enter key.
With the commit of
MyFile.txt, we have finally fired up our repo. It now has a
master branch with a file within it. We will play with branches in the forthcoming chapters. Right now, think of it as a course of our repository, and keep in mind that a repository can have multiple courses that often cross each other.
As you can see, Bash shell warns us that there are some modifications painting the name of the modified files in red. Here, the
git status command informs us that there is a file with some modifications and that we need to commit it if we want to save this modification step in the repository history.
However, what does
no changes added to commit mean? It is simple. Git makes you take a second look at what you want to include in the next commit. If you have touched two files but you want to commit only one, you can add only that one.
If you try to do a commit without skipping the
add step, nothing will happen. We will see this behavior in depth in the next chapter.
So, let's add the file again for the purpose of getting things ready for the next commit.
Fasten your seatbelts! You are now entering into a piece of code history!
What is that? It's
Vim (Vi Improved), an ancient and powerful text editor. You can configure Git to use your own preferred editor, but if you don't do it, this is what you have to deal with. Vim is powerful, but for newcomers, it can be a pain to use. It has a strange way of dealing with text, so to start typing, you have to press
i for inserting text, as shown in the following screenshot:
Once you have typed your commit message, you can press Esc to get out of the editing mode. Then, you can type the
:w command to write changes and the
:q command to quit. You can also type the command in pairs as
Note that when you saved the commit message in Vim, Git automatically dispatches the commit work, as you can see in the preceding screenshot.
Well done! Now, it's time to recap.
In this chapter, you learned that Git is not so difficult to install, even on a non-Unix platform such as Windows.
Once you have chosen a directory to include in a Git repository, you can see that initializing a new Git repository is as easy as executing a
git init command, and nothing more. Don't worry now about saving it on a remote server and so on. It's not mandatory to save it; you can do this when you need to, preserving the entire history of your repo. This is a killer feature of Git and DVCS in general. You can comfortably work offline and push your work to a remote location when the network is available, without hassle.
In the end, we discovered one of the most important character traits of Git: it will do nothing if you don't mention it explicitly. You also learned a little bit about the
add command. We were obliged to perform a
git add command for a file when we committed it to Git the very first time. Then, we used another command when we modified it. This is because if you modify a file, Git does not expect that you want it to be automatically added to the next commit (and it's right, I'll say).
In the next chapter, we will discover some fundamentals of Git.