An Amazing Technology I discovered While Preparing for Boot Camp
As a self-proclaimed software enthusiast, I was quite embarrassed when I first came across the term ‘version control’. You may wonder why? Well, ‘version control’ is a term any software person should be familiar with.
I had often wondered how a software team with members working from various remote locations could efficiently work together on a project. But I had simply concluded that they would have to share the various tasks among themselves and put everything back together at the end. “But, how exactly were they supposed to do that,” I had gone ahead to ask myself. “They would probably send the finished modules to whoever among them was responsible for coupling the project together,” I had replied. Case dismissed.
But, wait a second! What if the project was far too complex for the different modules to be separated and worked-on in isolation of others? Well, I had no answer to that. The previous suggestion would definitely not work in this case, as file conflicts would be almost impossible to resolve, unless the team had a geeky version of the infamous John Wick who, as we all know, specialized in impossible tasks.
Now, even if it was possible to resolve the file conflicts, it would be a very time-wasting ordeal, and, therefore, an unfeasible option. So, the mystery remained unraveled until a few months ago when I came across the term ‘version control’. I was going through my home study curriculum in preparation for Andela’s technical assessment for the Andela Fellowship Cycle 37, when I stumbled across the term. What exactly was version control, and what did it entail? I read on, curious to find answers to my questions. I was wowed, as I realized that I was looking at the answer to that riddle of long ago. The John Wick I thought never existed, materialized in front of me in the form of the version control system. Version control systems were the solution to the puzzle of how to collaboratively work on a project as a team, regardless of the location of members and seamlessly put everything together. These wonders provided a way to enable concurrent work on a project, easily to revert changes, document file modifications, and separate production code from development code. Also, all project files would be stored on a remote server, guaranteeing their safety.
And what was more? They can be used, not just for software projects, but for many other types of projects. The advantages offered were countless. All that was required was the initial effort of getting acquainted with the workflow and terminology, and you were pretty much good to go. The learning curve for most types of version control systems is short. Here’s how it works.
Project files are stored in repositories or repos (which are more or less like the folders on your computer), so you have to first create a new repository whenever you want to start a project. Once you create a repository, a default branch is created in your new repo known as the ‘master’ branch. A branch is basically a path along your project’s working path, and the ‘master’ branch is the main branch of your project’s working path. It contains production-ready (customer-consumable) code, which means that the version of your project that has been tested and proven bug-free and functional is what you have on the master branch at all times. Normally, you would create a separate branch for all development work. This branch will initially contain a copy of your master branch, and, consequently, any change that has not been proven production-ready. Whenever you want to add some new feature, you create a new branch for it, and merge changes back to the development branch. When development code has been tested and proven deployable, all changes are then merged into the master branch. That way, the master branch grows step-wise with production-ready code, while the development branch is somewhere ahead with code that has not yet been proven entirely function and bug-free.
As a newbie, it might be a bit hard to understand how to work with a version control system, but with practice it becomes quite easy and practicable. The workflow can be easily explained with a simple illustration. Consider a bunch of teenagers who must find their way to freedom from the heart of a very mighty labyrinth. Let us assume that there are beacons place at arbitrary points along the singular path that leads to the outside. Everyday they have to try to find at least a beacon. So at the start of each day, they all split up and go their separate ways into the labyrinth, ensuring to leave a trail of their movements, so that they can always find their way back to camp at the end of the day. Whenever they do find a beacon, they move their camp along that path, to set it up once again at the location of the beacon, and then continue their search for the next beacon. Eventually they keep moving their camp along the correct path until they are outside the labyrinth. Every day, they split up and go searching for the next beacon, and it might take days before they eventually find it. But whatever happens, they never move their camp until they have found a new beacon.
There are several terms associated with version control systems like: staging, push, pull, commit, and pull request, but I would not try to explain them, since, on the one hand, I don’t fully understand some of them, and, on the other hand, they might add unnecessary complexity to the simple piece I had in mind when I started writing this post. My intent was to share with you about my amazing discovery of version control systems. If you would like to know more about them or even use one, feel free to do a search on Google; resources are very much available and plenty. I can assure you that with a good version control system, you, or your team, will never get lost in the labyrinth. Good luck!