What is Version Control?

Version control is a general term for anything comprised of text. Wikipedia pages, Glorbumbo's Wiki/Tailor pages, Google Docs, etc have version control built in. The primary role of version control is to organize and manage the versions of a piece of text over time. Google docs, for instance, gives you the ability to see historical versions of your document, and optionally recreate them. Wikipedia, Glorbumbo's Wiki, and Tailor all do something similar, saving a copy of each page every time it is updated, so that the history of how the page was changed is visible. The general approach is this: when changes are made, a version of the text is stored permanently in a timeline, often represented by the changes made since the most recently stored previous version. This helps when needing to revert text, or reference deleted text. It also creates a paper trail of purpose and intent behind each section of words.

Version control for most text primarily serves an archival purpose. While reverting and referencing old versions is useful from the historical sense, it doesn't often provide benefits to the act of writing itself. Most of these mediums have betters ways to collaborate, better ways to revise copies, and better ways to denote when something is finished. Software development, however, does not have any of these things.

When it comes to software development, Git is used as version control, and it does so on the same principles as other mediums. Versions of the code are stored as versions on a timeline, each representing changes from the previous version. However, the totality of software, along with it's fragility, means that if one person makes a change, the whole program could stop functioning. Patching a bug as someone else is writing a new feature could make both tasks break each other in the process, and figuring out what exactly went wrong becomes a nightmare. Collaboration in code cannot be everybody editing the same code at the same time without everything falling apart.

This is where version control becomes critical for software development. Instead of all messing with the same code on a server somewhere, you take a specific version in the timeline, pull it out to make a bunch of changes to add a feature, fix a bug, or do some cleanup, then take those changes and add them back into the timeline of versions. Due to the development of bugs and features being isolated while they are in active development, they don't break each other. The version history itself also allows for tracking down the evolution of bugs and exploits, and being able to investigate them as they first appeared. The strict timeline also allows for a full manual intervention of instances where two different changes clash with each other.

Git, along with it's competitors, can do all these things. However, to understand how, we first must understand the exact way that these version timelines interact.