The main idea behind Git is to store code in atomic snapshots—commits. Ideally, every commit should represent one logical step in development—say, an addition of one function. For each commit, you can add a message, explaining the change. They can also be tagged. This tag can be later used for ease of navigation between commits. When committed, files are archived in a special folder, named after the commit hash. Git keeps track of all the files that were changed, and stores a copy of only those in a new commit. You can always switch to another commit, revert code to the previous state, look at the history, or create "diffs," side-by-side comparisons of what changed between the two versions of the file.

Another important concept is branches. Technically, they are similar to tags. Imagine that you have a working project but want to add some features. To keep everything safe, you don't want to mix the current (working) code with the one you're working on. To do so, you can create another branch of the code base, and develop in parallel – all the new commits will be kept separate from the original branch (called the master) until you explicitly merge them. You can keep as many branches as you want at the same time; that way, two developers can work securely in parallel, without any interaction or conflicts; that is, until they decide to merge their branches, or merge them to the same third branch. In some cases, repositories maintain a few dedicated branches constantly, for example, with one code base for Windows machines, and a slightly different copy for Linux.