Origins
Git was invented by Linus Torvalds to use with the Linux kernel. There were performance and political, aka licensing, issues with the previous version control system that the kernel used.
Selected Features, from Wikipedia
- Strong support for non-linear development
- Distributed development
- Efficient handling of large projects
- Pluggable merge strategies
- Toolkit-based design
Description
Git is a distributed system, modeled on a file system with built in versioning. Linus wrote it for speed in the use-cases he cared about with the kernel:
- Patches supplied by email or grab from other user’s repositories
- Pick and choose among patches provided
- Merging many patches per day
- All users comfortable with the command line
I have used it for about a year, and found it very useful, with a few caveats. I use it at home a lot. It allows me to propagate data between systems very quickly, so I use it as backup for my own work at home. I started with a single repository containing several small unrelated projects and non-software files, such as my career-tools folder which contains resumes, personal cards, graphics and sample letters. I learned the hard way that putting it on a USB key requires keeping free space on the stick greater than the total size of the repository. I haven’t gotten around to breaking it up into a couple dozen separate repositories, but I will. Also, I learned that a 600MB repo takes a long boring while to update on really slow media such as a USB stick.
When using Git, you grab a copy of the whole repository on your local machine. That’s what makes it a “distributed” version control system. You “commit” your changes to your copy of the repository. To share them with others, you then “push” them to a central repository when you are ready, or ask others to “pull” from your repository. This basically means committing all changes twice: locally, then centrally.
At work I used Git with a small team of three people. I learned that, like using a stick-shift transmission, Git requires a commitment to learning that is higher than on an automatic transmission.
Some people use manual transmissions inefficiently and in ways that I cringe at, shifting too often or not often enough, not matching revs, and have no idea how or when to double clutch. Modern car transmissions are designed to survive this treatment. Keep those people away from trucks.
Git is like a manual transmission. You should commit to learning more about it than you think you need to know. There is always more to learn. Also, you can use “work flows” with it that are difficult to do with Subversion or most other VCS’s.
The Linux kernel team has thousands of developers who contribute to it, hundreds who contribute frequently, from sites around the world. Their work flow might not work in a centralized repository. A simplified version of their work flow (assuming the change is perfect) goes like this. You grab a copy of the latest “blessed” kernel code from the canonical git repository on GitHub, make changes, test them, and then tell the person in charge of that part of the kernel. This person grabs the code from your GitHub copy of the kernel repository, or receives it from you by email, examines it, tests it, merges it with other changes in the same part of the code and submits it upstream to one of Linus’s main “lieutenants”. This gatekeeper will similarly examine it, merge it with other changes, test it, and promote it to Linus who may choose to accept it.
This work flow is very different from a “small” environment where, of maybe a hundred developers on a project, 5 or 20 are working on one part of a project and have that part of the code to themselves. Git works with these teams as well. It is fast and supports complex merges.
Git also supports different work flows that you may not be used to. For instance, I knew a team that used git internally, and then submitted changes centrally to the corporate Subversion repository. This had several advantages. The team leader could filter submissions from new employees. They could do local commits to their own repository frequently, say at 5 minute intervals on a temporary branch, share with their team mates on a common branch when a small change was ready, and not be delayed by the slow submit time to the Subversion server in England. Changes could be “summarized” in the corporate Subversion repository, so that all those unfinished changes in the 5 minute commits were not seen, and failed, by the Continuous Integration server.
Git also supports using a central repository that people can push their changes to. This is a repository that has no “working copy”, just the repository database.
“Tags” and “branches” are a local idea in git. This means you have to push your tags manually so that other people can see them. Also, if you don’t explicitly copy your branch to the server, git will happily push your changes but you will not be able to find them easily as they are not on a branch on the central repository.
How to lose your changes in git: Create a new branch locally, make changes, push them to the server that does not have that branch, and delete that branch locally, forgetting to merge to a main branch. That’s a bit like trying to shift down from third to second on an uphill, taking too long and then stalling because the truck is going too slow for second gear when you finally complete the shift. In this case, my co-worker recovered because he found the commit ID on a scrollback log in the terminal window where he did the commit.
Git works best when someone on your team is an expert and everyone takes time to learn more than the minimum.
Main Git web pages
- http://en.wikipedia.org/wiki/Git_(software)
- http://git-scm.com/
- http://whygitisbetterthanx.com/
- http://unspecified.wordpress.com/2010/03/26/why-git-aint-better-than-x/
GUI tools for Git
There are now GUI tools for Windows, and plugins for many IDE’s.
- http://en.wikipedia.org/wiki/Git_(software)#External_links
Tagged:
Linux,
software,
team tools 
CompTIA Linux+ Complete Study Guide Exams LX0-101 and LX0-102, Roderick W. Smith, (- 2010)