Git is a source control management system, hence http://git-scm.com. By source this actually refers to any file of any type. We can add any file that we want to the system and begin tracking modifications to that file. As we create other related files we can add those to the system as well. This means that we can organize a group of files together and track them as a whole. From the perspective of a developer we can think of this as our source files for a project we are coding. For instance, in a C# project this would be all the .cs files. Now this grouping of files actually has a special name as well, a repository. Let’s review:

git – source control management software that tracks the modifications to one or more files

source – a file that we wish to track modifications through the software

repository – a group of files organized into a single set and tracked together as one group.

So how does git work? Well, let’s think about this in terms of the computer we are on and the file system that the computer has. A computer has a file system and consists of files and folders. Those files and folders are created to provide a desired structure so that we can easily find files that we are searching for. Git uses this structure for its repositories. A repository is really nothing more than a folder with files and other folders that we wish to track within the repository. Although, only the files are really being tracked for modifications, the repository can contain subfolders as well. A repository exists locally then and can be thought of as being on the machine we are working on. Therefore any modifications we make would be done locally on the computer we are working on.

So wait… we are going to work with everything locally? but what about portability to other machines, collaborating with other developers or just saving a copy to a central location so that if our machine’s hard drive is lost we don’t lose all our changes. Git solves this too… Git has the concept of a remote repository as well. A remote is a location that we intend to copy our changes to periodically. This could be another server within the network, an online host (such as GitHub or Bitbucket) or really any other directory that we want to copy the local repository. Our only interaction with this remote will be to copy (push) changes and retrieve (pull) changes from the remote. The remote itself will be a repository but one we won’t directly modify. Instead we work locally and push those changes that way.

Let’s take a look at a possible structure here.

Let’s start with a _repos folder. This folder will not be a git repository but instead be the folder that we create all our other repositories in. This way if we need work in more than one repository at a time we can differentiate between them using separate folders within this folder. For instance:

+ _repos
|-+ project1
|-+ project2

In this example we have two projects. Each directory, project1 and project2, are both git repositories. They are different repositories tracking files for two completely different projects. If we need to start working on another project we would just create another directory. The important thing is that we not put a repository within the folder of another repository (this is something more advanced and if we are just starting out, it is best to avoid). So we would never put project2 folder inside of project1. All the repos would go inside the _repos folder.

Once we get the folder structure of git we have a good base level knowledge to get setup and get git going with the basic commands… something I will save for another post.