Let's talk about some of the basic concepts in design features that underlie the git revision control system. Now, if you've used any other version control system, many of the basic commands that git uses may be familiar, operations like getting files, committing changes, comparing with earlier versions, logging the history, any serious revision control system has to have analogous commands and ability to do such things. But underneath the hood, git is quite different than earlier revision control systems. One important example is that in git, a file is not an essential object. Common operations, which may be rather cumbersome or difficult in other revision control systems, such as renaming a file or moving it from one directory to another, are very simple when using git. Git also uses these long hexadecimal identifiers that are associated with particular commits. They may look a little strange, but they're more than just a complicated name. They incorporate checksums that are used to verify the contents of the repositories and the changes that are made during a commit. Because git grew out of the Linux kernel development community, which is far-flung and widely distributed, it was designed to meet the needs of a very distributed development community. It has, of course, by now been adopted by many additional projects, literally millions on GitHub, for example, but its basic structure and motivation shows its roots to this day. So, here are some of those design features. One, you facilitate distributed development. So, developers can work in parallel no matter where they are and don't have to constantly resynchronize. They can do that when it's convenient. It scales to large numbers of developers. It doesn't become more complicated when there are large numbers of developers. You can get high speed and maximum efficiency. Especially when you're working over the internet, it's nice to be able to avoid copying large files, and other information, to use compression, and not tie up networks, especially if you have people with high latency or slow speed. You have a strong web of integrity and trust, no unauthorized alterations can be made. You can ensure repositories are authentic ones and there's various kinds of cryptographic hash functions used to make sure this is true. Everybody's accountable for all changes, each line of code, which has been changed, you can blame somebody for. So, it's very important when unraveling the history of a project, especially if there's some legal claim about who actually owns the code, etc. You keep some data in a repository immutable, or unchangeable, such as the history of the project in some Orwellian fashion, go back and change the history. Transactions or changes are done atomically, that means either all the changes go through or none do. You don't leave things in an undetermined or corrupted state. It's very easy to branch into different branches, development branches, or subsystem branches. It's also easy to merge branches into the master branch or subbranches, etc. There are very robust methods for doing those things. Each repository is independent. Each repository has all its history in it. You have a free unencumbered license. Git is covered by the GPL version 2. You can still develop things using git that have other licenses or even proprietary. So, that's a brief overview of the concepts and design features of git.
