Source Control is a way for developers to manage their source code. All code in a company of any size should be under source control. However, the choice of the source control protocol used determines the level of freedom/control available to developers and source code managers.
Native filesystems offer some minor form of version control, but advanced systems offer much greater control over the versions and how they can be retrieved.
This document presents a case for Git, and why it is superior at letting developers do what they're best suited to do: code. Git gets rid of the ugly facets of version control, and it keeps users focussed on code.
SVN and CVS are primarily centralized revision control systems which is very different to how Git is set up. If you’re a company that uses CVS/SVN and relies on its software for mission-critical applications, altering your development workflow impacts your entire business.
A distributed system allows users to work at separate sites, at lightning speed. A Centralized Version System points back to a server that has the latest code, all the time. Every developer has to deal with each other's commits, a broken master branch is not easily fixable, and it is a nightmare to deal with branches from different sites. In a distributed environment, it is trivial to code in an environment that is at once isolated and team oriented. You commit your changes locally, in a copy that has all the changes from the master branch (or any branch that you pull in, really), and you get the freedom to push back your changes in one go, once everything is tested.
You can write scripts at your end, to run tests, or run scripts at the server end, to check for protocols that should be addressed. A distributed system is so much more faster because every developer has a local copy. You can scale your development team overnight and still be able to deal with noncompliant code because your new developers made a mistake. A broken branch doesn't stop the production server from doing its job.
Alternately, if a project's description changes overnight and there is a major code overhaul, smaller projects relying on the old code base don't need to worry about losing their required code. They can branch it off, and continue working.
Say you're managing a large codebase that needs a new feature for a new project that may not be required for other projects. You can create a Git branch, write in that new feature, and have it exist completely secure in its own branch, only taking what is explicitly required from the master branch. And you can have someone manage the master branch, having only the approved features in it so that it is always approved and only authorized people can write to it.
This methodology is written to bring controlled change into a codebase. In today's world of changing requirements and dynamic flows, any coder will agree that it is a necessity to be able to manage code securely.
Using feature branches is not only more reliable than directly editing production code, but it also provides organizational benefits. They let you represent development work at the same granularity as the your agile backlog. You could map requests to Clarizen tickets so that they are addressed in their own branches, for instance.
To work together, developers would need a system that encourages distributed environments, across grossly different sites. Some users might be comfortable with Linux, some might be comfortable with Windows. This environment should encourage collaboration across such environments. That being said, here are a few requirements for such a system.
- A Distributed system:
It goes without saying that a distributed team warrants a distributed system. There are scenarios where we cannot access a particular server sometimes, for whatever reason. Network speed is another issue. Having an entire snapshot of the codebase is always a boon for developers. Being able to push in your changes without breaking environments is another. A distributed system also ensures that there are many, many backups of a codebase, always available.
- Store versions comprehensively and completely:
A version control system should store all the differences between files, understanding what changed between versions rather than storing entire files. This reduces the stress on the system itself and makes it easy to retrieve older versions. This also makes it easy to branch versions and merge them later.
- A Fault-Tolerant System
Developers make mistakes. Especially so when they're working across sites. A system that we select must encourage experimentation without penalizing the users. Branches need to be actual branches, and not a folder based system like that in SVN or similar central version control systems. Branches should be easy to switch between, and it should be trivial to merge branches at any point. This is easy when a branch is a symbolic change, like that in git, unlike the system in SVN.
- A community interface that allows for coders to communicate easily
A facebook for coders and developers, in a simple sense. It should be easy for developers to collaborate. It should be easy to read some one else's code and review the changes. It should be easy to declare that something is a future feature, inviting others to add value to our changes. Similarily, the system should enable collaboration by making the conversation transparent and clear.
An example for a working, testing system of collaboration across diverse forums and situations is Github. Github encourages developers to share code across teams, document code in a very readable and accessible format, and to streamline the development process so that it is easy to follow. It allows standalone developers to mark their code for future changes, document even those planned changes, and for users to request or propose new features.
- Accessible by Everyone
The system should be accessible by everyone on our network. Of course rules can be set so that some users have more or lesser access to certain projects (see below point), but it is important that any one can upload code or ask for features on this system.
- Access Control
The system should have a way to hide code from the public users (meaning general users at GKN), but it should also encourage and allow users to publish their own code freely.
- Forking
The system should allow anyone to take up someone else's code, fork it into a new codebase, keeping all of the old codebase's changes, and carry on work. Each codebase should know how many times it was forked by other users, and if the original developer wants to accept someone else's changes, it can be arranged. This encourages a solid communique when dealing with code. Code can be reviewed and fixed, and these fixes can transfer over to all instances of running code. Alternately, if someone does not want the fixes, they can do that as well.
- Intuitive Web GUI
The system should come with an intuitive web GUI, one that allows for both reading and editing of code in the interface. It should allow developers to comment on each other's code, to raise issues, feature requests or look up various branches to see what issues are being dealt with. It should allow tagging of issues so that their timeline can be investigated and allow developers to streamline this process without much ado. This web GUI should be intuitive, and easy to use, even for unseasoned developers.
- Host Documentation in the Web GUI
The system should encourage documentation and make it easy to host the documentation online, be it a simple markdown file, such as this one, or a fully-fledged HTML file. It should also be able to render Jupyter Notebooks, as this will make collaboration for data analytics very easy.
- Command Line Tools
A developer rightly lives in the terminal. It is mandatory that the system should provide a fluid Windows and Linux compliant command line interface so that the scripts can be downloaded. This should support protocols that allow for management of libraries, similar to how PyPI does this for Python libraries. For example, it is easy to update Python libraries using repositories hosted on Github. Similar support should be provided as opposed to a multi-step process. Again, for illustrative purposes, it is this easy to install a python library from github.
pip install git+https://github.com/user/repo.git
- Support for Triggers and Hooks
Coding itself is a process that encourages automation, be it loops or functions. In this spirit, it is necessary that the system should allow developers to write hooks for their code, meaning, action to be undertaken when certain changes are made to the code. This encourages stern code quality control and prevents novices from botching things up.
- Backup & Support
The system should be easily backed up. This is trivial when it comes to a distributed system, which is why that is both the opening and closing requirements. Enterprise support is also desired, but it is also manageable by setting up a server ourselves.
Developers around the world agree that git has become the defacto source control tool of choice. Offering git to developers brings in a mindset that encourages experimentation and collaboration.
Lone developers and teams both win when offered the chance to work with git. When a company allows developers to use git, it is a sign to possible future employees that this company allows the very best tools and lets them learn cutting edge technology when it comes to software development. Limiting developers to technology that is bound behind paywalls reduces that and cripples their motivation and interest.
Git also makes it possible to work together as a team across different environments because it works on Linux and Windows. It is just as fast on the smallest of ARM processors.
With git's vast infrastructure of tools, it is easy to build a team that talks and breathes together through their code.
If you've had a developer who had to take a sudden sick leave, using a tool like Github Enterprise, Bitbucket or Gitlab will ensure that the community goes on, without losing the pace. All the documents related to the code are accessible by those who are authorized. Some people can have read access, some can have write access, everything can go through a streamlined authorization platform.
Git works, quite simply.
Did your version control server suddenly go offline? Did you have to move the server and are you tasked with repointing all your checkouts?
This is no problem with git. You can work offline, or on the go. With git you can make changes locally, push your changes when the central server is available and then have your source code manager merge the changes as per his or her process.
Did someone make a mistake? Easy peasy. Fix mistakes with git's undo commands. Correct last commits, undo an entire commit. Git leaves a trace, always. So you can even undo your undo.
By using git, we get in an entire ecosystem of developers who love working with the tools we use. CVS is outdated, and SVN is largely following suit. A large community often is an advantage by itself because an ecosystem evolves around the system. Lots of tutorials, tools, and services make Git even more attractive.
Github Enterprise goes one step beyond. It offers the power of github's vast architecture and learnings in an enterprise server. Offering Github Enterprise encourages developers across all our sites to collaborate and talk to one another about code. Engineers can search for tools, publish their tools and have them accessible by others like them across the world.
If the price is too high, Gitlab is a freer alternative. Both offer power that no other solution can match, especially now one centred around Centralized Version Control Systems.
In closing, a version control and collaboration system that we are offered should be one that brings power to the developer, and is accepted by the community at large. Git and its ecosystem bring these in large supply, offering them to us for our disposal. Frankly speaking, no other version control system can come close to the ecosystem that is Git.
Case in point: this file is on github, and all of its previous versions can be read easily here.
