Ready, Set, GIT!
Part I — Do you Git it?
What is all the clamor about Git? Why is it so popular and where did it come from? Let’s take a look at the history of Git and its beginnings.
Git was born in 2005 and was an offshoot of a product called Bitkeeper. Git is mostly a child of Linus Torvalds, the creator of Linux when the “free usage agreement” broke down between the Linux and BitMover, Inc. the company that owned and developed Bitkeeper. Interestingly, Bitkeeper was eventually released as open-source software in May 2016 under the Apache 2.0 License. Unfortunately by that time, the die had been cast and Git was on the move.
Git has evolved and matured significantly over time. However, it still retains its original scope and meets its original goals of:
- Speed
- Simple Design
- Parallel branching mechanisms
- Ability to scale to any size project
I have used several other source code control library management tools (Version Control Systems - VCS) over the years. Yet Git differs from all of the rest mainly in the way it views the data stored in its repositories. Once you understand where the differences between Git and the other standard VCS implementations (mainly CVS and Subversion) exist, you can comprehend its simple elegance of implementation. In fact, the more you can forget about these other source code management tools, the easier it will be to work with Git. For those readers who have never used a VCS before Git, you hold a definite advantage over those of us who were trained using another tool.
I will compare Git to Subversion to explain what I consider to be the two main conceptual differences.
Subversion (and other similar VCS) view and record source code as lists of differences (or changes) in each line of code. With Subversion, a file will have each line either noted as 1) added, 2) removed, or 3) changed with a timestamp attached to each one. Over time, the file will accrue these modifications and continue to expand until a commit (sync point) is established and all changes are integrated together in a new version. However, with Git, you can look at your source code as a miniature set of files. Each time you make changes that you commit, Git takes a snapshot of the status of the entire project at that time. For efficiency and speed purposes, if the other files did not change, then those files are not snapshot, but Git does store a reference to each one of the unchanged files. Each snapshot reflects the given state of the project files at each commit point. That is why it can be easily recovered/restored to a prior point in time across the entire branch. Git only has to show you the status of every file at the referenced time of its snapshot.
Probably the greatest advantage to me (after being a Subversion user for many years) is the way Git stores a local copy of your repository on your local machine. I often switch between systems when I am working from home, the office, or on the road. Each system has a local copy of the current repository that I am working on installed. So I can work on my project from anywhere without having to be connected to a network server like I have to in order to use Subversion. I can commit changes to my local repository then apply them the next time I get connected again. With Subversion, I can edit my files but I am unable to commit my changes until I get reconnected to my network server where my repository is stored.
All in all, I am excited about learning more about Git and putting it to practical use in my new development efforts.
Next, we will look at “Part II — Git ‘R Done” where I will cover the creation of a Git account and the installation of Git on a local machine.
