Over a million developers have joined DZone.

Learning Git: Repository Basics

DZone 's Guide to

Learning Git: Repository Basics

· DevOps Zone ·
Free Resource

A repository is a specialized storage area in which you can keep track of your work. This is a simple example of what an ad hoc repository might look like:

 Volume in drive C is GNU
 Volume Serial Number is 5101-E64D

 Directory of C:\buildtools

03/15/2014  08:22 PM    
03/15/2014  08:22 PM    
03/01/2014  08:22 AM            11,843 filefixup-01.bat
03/03/2014  08:52 AM            11,943 filefixup-02.bat
03/08/2014  11:22 AM            12,050 filefixup-03.bat
03/10/2014  02:22 PM            12,352 filefixup-04.bat
03/15/2014  03:21 PM            11,878 filefixup.bat
               5 File(s)         60,066 bytes
               2 Dir(s)  467,705,196,544 bytes free


Let’s gradually uncover this example to properly introduce the basics of a version control repository.

Let’s assume we have a build process, which requires us to pre-process some files. Maybe we have to rename these files, or add a timestamp to them. Let’s assume we’re on Windows, so we’ll use a windows batch file (its suffix is BAT) to execute these steps.

We write code for this utility script, saving it to a file called filefixup.bat, in a directory called buildtools. The script works great, but a few days later we need to code up different pre-processing steps. The old BAT file still works, however, so instead of making modifications to that file, you rename it by appending the string “-01” to its name (filefixup-01.bat). This signifies to you “version 01.” and you’ve made a mental note that “version 01” is the first version of the utility that renames and adds a timestamp to the files. This new filename also gives you the ability to keep using this old version as you work on the newer version.

You start adding the newer code to the file filefixup.bat, knowing that you can always go back to filefixup-01.bat. The file with the 01 suffix is a copy of the BAT file. The file without the 01 suffix is your working copy.

After a few hours, you reach a good stopping point with the new utility program. You realize that this would be a good point to make a new version of this program. Following your convention, you make a copy of the working file, naming it filefixup-02.bat. Once again, you make another mental note that “version 02” contains your improvements.

Now your directory looks like this:

C:\buildtools> dir
 Volume in drive C is GNU
 Volume Serial Number is 5101-E64D

 Directory of C:\buildtools

03/15/2014  08:22 PM    
03/15/2014  08:22 PM    
03/01/2014  08:22 AM            11,843 filefixup-01.bat
03/03/2014  08:52 AM            11,943 filefixup-02.bat
03/03/2014  08:53 AM            11,943 filefixup.bat
               3 File(s)         60,066 bytes
               2 Dir(s)  467,905,187,544 bytes free


I hope you can see how we could get to the listing you saw at the beginning of this article. You keep making changes methodically to the program, saving it to a new filename each time you get to a logical stopping point. If you’re witty, you might even save a copy named filefixup-beforelunch.bat, to indicate the version that you were working on immediately before lunch. You’ll throw this one away, but going to lunch is a stopping point.

Over time, you can see a makeshift history by looking at your progress via the timestamps on the version files. You might back up the entire directory to a USB stick, or to a network shared drive. You might someday have to revert to an earlier version, and to do so you just copy the version that you want on top of the working file. These are the kinds of operations you could do using this ad hoc version control system.

It’s should come as no surprise that Git does all this, and more. Let’s now forget this or any other ad hoc system you might have been using before, and try out Git.

Creating a New Git Repository

The command to create a new Git repository is git init. We can type this in any directory, and instantly a Git repository will be created in that directory. That is all there is to it.


This section will have you entering commands into the Git command line. For Windows users, this means that you’ll be typing commands into Git Bash (you cannot use the DOS or PowerShell windows for these kinds of operations). For Mac and Unix/Linux users, you’ll be entering commands into the standard terminal application.

These steps navigate you to the home directory, create a new directory, and then create a Git repository in that directory.

% cd
% mkdir buildtools
% cd buildtools
% git init
% ls

One thing to note is that the last command will not print anything. There are no files in the repository because we haven’t added any yet!

Performing the above steps will create a Git repository right in the buildtools directory. There are two important things to note:

  1. No server was started.
  2. The repository is entirely local.

It’s hard to overemphasize the first item: no server was started. It’s hard to prove the non-existence of something, but on our individual machine, there are usually commands to let you see all the running processes. In Windows, you can visit the Task Explorer. In the Mac or on Unix/Linux, you can type ps -e. If you inspect these mechanisms, you won’t see a Git process running. Git doesn’t require a server. By not requiring a server, it’s very easy to decide for yourself to start version control on some directory because you don’t have to request permission from anyone, except yourself. (And yes, you should always allow yourself to use Git!)

The second item is a corollary of the first item: The repository that you created is entirely on your machine. Note that I didn’t say the repository is “running on your machine.” Nothing is running. But the Git repository files have been created, and the directory buildtools has been transformed from an ordinary directory into a version control working directory.

Figure 1 illustrates what’s happening when you type git init. You create a working directory, and when you type git init a Git repository is created. The Git repository is actually on your machine inside the working directory, not on some server somewhere over the network!

I take pains to distinguish between the working directory and the repository because they are two different things. A working directory is simply the place where you do your work. The repository is the specialized storage area in which you can save versioned files. The Git software can track files, meaning it can detect differences between files in the repository and files in the working directory.

At this point, we can now start to create files in the working directory and add them into the repository.

Above and Beyond  Git’s repository exists in a separate hidden directory named .git. In the command line, filenames or directories that begin with the period or dot are considered hidden by the ls file and directory listing command. You can see the Git repository by typing ls -a .git in our working directory (recall that this is the directory named buildtools). You can even look around in there by typing the following: % cd .git
% ls 
However, the nature of these files and directories are beyond the scope of this article. I do acknowledge that people are curious about where the repository actually lives, and this answers it: the repository lives inside the working directory. Be advised that you shouldn’t touch any of these files! They are manipulated by Git, and modifying them manually will cause issues down the road.
This article is excerpted from Learn Git in a Month of Lunches. Save 39% on Learn Git in a Month of Lunces with code 15dzamia at manning.com.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}