To developers repositories like GitHub, BitBucket, Tortoise SVN, VSS, etc. are so ingrained in what we do every day that we don’t even consider why others might question their need. Clients, however, inquire all the time as to their necessity. Here, I want to briefly delve into repositories, differences between them and why they’re needed.
Just like its name suggest, a repository is a bucket for data. However, a code repository would’t be nearly as beneficial to developers if the only thing it did was store data. The biggest benefits code repositories give us is version control and a central place accessible to all team members where all code is established to be up to date. Version control becomes more important on bigger projects and projects that involve multiple developers. However, consider even the simplest example of having a front-end developer and server-side developer working on different parts of a website simultaneously. Without a repository they would need to send code files back and forth to each other. Any time that a file hits the email as an attachment it would be considered obsolete. If one of the developers edits the code, they will have to send another attachment and another and another.
Emailing code files also doesn’t provide us with the tremendously life-saving benefits of branching. Branching is a close cousin of versioning, however it’s not entirely the same. Branching allows developers to maintain different versions of the code that are all up to date. For example, imagine two developers are working on the same project. They start off from the same set of code files, however each creates their own branch and only works on the parts of the project they were assigned. These two branches, along with the original branch, live side by side until the developers are completed with their portions of the code and merge all their changes into one branch. This very simple example explains the benefits of branching, however, branching abilities get much more complex where branches are branched from branches and merge with other branches. We don’t need to discuss these here as your developers will be the ones dealing with branching and merging and there’s plenty of articles available on how to do so.
Here’s a simple example of branching…
Before GitHub and BitBucket, version control was mostly set up on a remove server that developers had to have the access to in order to download code. VSS and Tortoise SVN were more desktop applications rather than online services. You had to install them directly to your machine, log into a specific endpoint for the desired code and download the code to your laptop. You also had to have a license and subscription to use the software that wasn’t exactly cheep. Because of this, programmers would mostly get the repository software through companies they’ve worked for instead of purchasing it for their own projects.
GitHub revolutionized the entire process by making a repository more accessible by placing it on the web, having a free tier and a subscription model that freelancers could afford. Another huge attraction that GitHub gave freelancers is the ability to have public repositories – i.e. repositories that anyone can view. Now, of course, I don’t know of any legitimate developers that work on projects who’s clients want the code in any way being public. However, it is still a good way to showcase your development techniques even if through code examples. Without it, there would be no other way to do it short of sending recruiters code files. Now, it is common for recruiters to simply ask for a link to your GitHub account.
Another huge benefit to online-available repositories is the standardization of code delivery and transfer between developers. This is huge for anyone hiring multiple developers for their project currently or in the future. Consider what you would need to do if your first developer did not put all of your code in an online repository. You would have to keep all of the code zipped up on your own machine and deliver to each developer individually. You would also need to maintain versioning manually and take care of merging of code files from different developers yourself. With online repositories, all you need to do is send each developer a link.
Last note I will add about repositories is: be careful of the public ones. It is very easy to create a public repository and store all your sensitive configuration data for the world to see. You will usually have to pay for a private repository, but it’s very beneficial to do so. The alternatives can be devastating to your project’s success. I write a bit more about that in Basic Server-Side Security Concepts in Access Point #3: Direct Access to Code.
