Git: things you have to know

• This article is a short introduction into Git for a novice who has never used this version control system before. 
• It can also be used as a helper and a refresher for those who already work with Git but are a little bit confused about it (and they are allowed to be!).

Please drop me a line of comment if you believe there is something missing in this short tutorial.

About Git

Unlike subversion (SVN) systems, Git is a distributed version control system (VCS). This means that: 

• It is decentralized.
• Git keeps track of the source across multiple repositories. These can be stored locally or remotely, and you can commit your changes between repositories.
• The history of a project is downloaded to your local computer and can be accessed quickly from there (no need for constant connection to the server!). This is a feature which differentiates Git from VCSs such as subversion systems, which are centralized (that is, based on client-server architecture). Thanks to this feature, Git works faster than subversion systems!
• As different from other VCSs, such as subversion systems, Git does not take into consideration only changes between subsequent file revisions, but makes a complete snapshot of the file system during each commit. Although this is more complicated than only comparing two versions of a file, it allows e.g. to automatically register changed file names. If you change a file name, Git will still recognize the file. In other words, the perspective of Git is more holistic when compared to other VCSs. 

If you change the content of any file in a repository to which Git is connected, Git will notice that. The system does not base on the name of the file; what Git stores in its database are SHA-1 hashes (see the dictionary note about SHA-1). In other words, every file and directory is checksummed before storing in the Git database and then Git refers to that file or directory by the checksum. This mechanism guarantees integrity.

A problem appears when you need to commit a binary file; Git does not have a mechanism for comparing versions of such files.

 

Before starting with Git

There are several steps to take if you want to work with Git and to do this effectively:

1. To use Git on your computer, you need to install it first. It can be downloaded free of charge from the official site.
2. Atlassian's SourceTree is a practical tool which will be very handy if you don't want to use the default terminal. It connects to your local repositories and to the remote ones, to which you can push your local changes after committing them locally. SourceTree is available for free – you can download it from the official page. 
   
   
   
   


3. There are also alternatives to SourceTree, such as Smart Git (free for personal use). And if you are accustomed to TortoiseSVN, there is even a TortoiseGit, also available for free on the TortoiseSVN website. In some ways, TortoiseGit is better than SourceTree, especially since it allows to easily search commit history from a certain day or period. As shown in the picture below, TortoiseGit adds a set of functionalities which are available when clicking on a repository folder(s) with the right mouse button.
   
   
   
TortoiseSVN also changes the appearance of your project folders, so that you will instantly see if there is some pending commit in a folder, for instance.

4. Be sure to learn what you can do with Git. You may check this post on useful Git commands.

Working with Git

There are six fundamental steps which are followed for every small part that you want to add to the Git repository:

1) Go to the main branch (usually called master, also quite often develop);
2) Create a new branch (often called a feature if it is a new functionality, or bugfix if it fixes a bug);
3) Commit your work;
4) Go back to the main branch;
5) Merge the modifications ("copy" them from the new branch to the main branch);
6) Delete the new branch if you want to, since it is not necessary any longer. 

Usually, in a commercial project, somebody else has to check ("review") your commit after a commit to the remote version of your new local branch. If they accept the commit, they can merge it with the main branch and they have the possibility to delete your remote branch.
  

Important notes for a novice

There are several points you have to remember about when working with Git:

• Unlike in SVN, after you commit your work, it is only committed locally (on your computer). You have to push or commit and push your changes for them to be visible to others on the remote branch. A commit is only a method of "saving" your changes to your own computer, on a branch that you have created on your disk. 
• In Git, there is a difference between a fetch and a pull. A fetch gets a list of changes from the remote repository but it does not apply them in your local repository. A pull additionally applies the changes downloaded from the server to your source code. So if you are currently working on some changes in the code, it is usually safer to fetch, and after you have committed all your work, it will usually be time to pull, and then to merge the changes you have fetched (they will be automatically pushed when you merge). 
• Copying an existing (remote) repository to your local computer is called "cloning" in Git.

See also: Advanced C# terms explained.