For any developers reading, this will be a fairly straight forward question to answer and, thus, presumably will also be well versed in the commands used to operate Git. But for most its a bit of a grey area or a jargon filled, mine field of technical expressions and assumed prior knowledge. So I’ll try and abstract away from the stats and more about the origin and motive of how its come about and why its pretty important stuff.
WHAT: Git is a piece of source code management software, or technically, a software configuration management tool (SCM). Github is like a staging server, that uses git to send code to and from its servers to individual developers that want to contribute to a project or component or plugin (softwares).
WHY: Source code is the code used to build websites, softwares and programs and needs to be managed like many other things. Many of these are complex, time consuming and require numerous contributors, each with their own specialist knowledge. With all this precision and careful efforts, there needs to be a secure and stable system so no work is lost, overwritten or damaged by others contributing. These systems were already existing but they were slow, verbose and unscalable for larger projects.
BACKSTORY: With several SCM’s being built in the past, Linus Torvalds (creator of Git and Linux) saw the errors in these previous builds and deliberately attempted to avoid conventional approaches to solve these issues, leading to a unique design. (I’ll attempt to briefly in the next few paragraphs). This is the SCM that has massively superceded them all and he smashed the performance targets he set out to improve. This was the core reason why Git was built, to improve speed and security for code based projects. This is potentially why its difficult to explain what Git actually is because of its conceptual nature. So one has to acquaint with what it does.
HOW: Git tracks and records paths of workflows between repositories (i.e folder with a project in it to another folder with a project in it). A hidden folder within this project folder can be created via the terminal to start all the monitoring and tracking Git does so well (UI’s can be used as well). It tracks the progress each time the work is pushed to the staging or production servers that host the project. These are often publicly accessible and allow other developers to either view or pull back down from that server to their machine to work on the same project. This pushing and pulling (at its most basic) is essentially a collection of contributors working as sum of individual effort and then sending their latest updates back up to the server.
THE REAL POINT OF IT IS: With Git in charge of the source code distribution, it takes care of (nearly all) human errors and stores revisions of changes by creating tags attached to all push and pulls (theres a lot more here but I’m trying to keep it brief). It essentially takes snapshots of your project each time the encrypted communication between server and computer happens (push and pulls) and its stored in that hidden git folder for later possible analysis or modifictions. This prevents overwriting each other, easily create different versions or features without worry of loosing, fragmenting or damaging previous work. Carefree collaborative code conduct.
THE BEST THING IS: Providing you’ve retrieved the latest updates, every machine/person working on it all has the latest version, anywhere at anytime, with all the previous amends, tags, metadata, differences, revisions, features and files. So even if the production (live) server lost everything, there’s at least one other machine that has all the latest files that can be readily pushed back upto the server. This differs to previous centralized version control systems, and was less robust especially so in this scenerio. And on top of that, it weighs hardly anything when looking at the extensive retention of associated data it stores for each individual project.
SO TO ROUND UP WHY WE USE IT: It’s quick, secure, extensible, scalable, cheap on CPU resource, extremely organised and its free. It’s just a tad fiddly to learn at first. To me that seems like a reasonable trade off for the benefits of this tool, as with anything in life that you put more into. Without digging further (not the aim of this article) its difficult to really see its concepts visually as to why its so useful in alot of tech related projects today. More reading can be found at the official site and this is a relatively readable place to start: http://git-scm.com/about/branching-and-merging.
