Git isn't the only option!

When I was first posed this statement, I was completely caught off guard. What do you mean Git isn't the only option? How else could someone track their changes and work on source code as a team? In my short software engineering career, I've always assumed that Git was the best and only answer in the realm of version control systems (VCS).

That was until at my job, I was made aware that one of our projects used Subversion, or SVN for source control. What even is that?

The main difference between Git and SVN is that Git is distributed and SVN is centralized. The way these two architectures are implemented amplify what the real differences are.

In this post, I'm going to explain what Git and SVN are, give a brief history of each system, analyze some of their advantages, and address some common questions that I personally had about them.

Quick note: There are other version control systems out there, but these are two of the most popular and relevant to me. I will briefly identify some alternatives later on.

What is a VCS?

A version control system is software that helps developers efficiently communicate and track code changes over time.

Using a VCS provides numerous benefits such as improved code transparency (who made the change, what exactly was changed, when the change was made), faster product development, and assists in disaster recovery.

What is Git?

Ah, the one we all know and kind of love? I personally have a love-hate relationship with Git. It annoys me when can't remember what and how "set-upstream" works, but I always appreciate that it has my back when need to trace that bug that was introduced in a previous commit weeks ago.

Git was created in 2005 by Linus Torvalds and other developers of the Linux kernel. Yes, The Linus Torvalds creator of Linux. After Linus found that current source-control management systems could not meet the scale of the Linux kernel, he prompted the start of Git development.

Git is a distributed VCS, meaning that you have to clone the entire central repository (repo) to make a change. This ensures that when making your changes, you have the entire history of the code in your newly cloned local repo.

After you have made your changes, you can merge them with the branch that everyone refers to as the 'main' branch on the central repo. For anyone that now wants the latest code changes, they need to update their local version of the code by pulling the new changes from the central repo.

Git focuses on the file changes and metadata, rather than the entire file tree. It uses optimized algorithms and sophisticated compression techniques to ensure great performance.

So Git is Github, right?

Nope. Although they may sound the same, these guys are completely different. In short, Git is a system for managing source code changes and Github is a cloud provider for hosting Git repos (among many other features).

Anyone can implement Git in some way, but one of the services Github provides is hosting your central repo. So as long as Github is online (knocks on wood), all of your code and its history are safe on their servers and can be accessed anywhere you have an internet connection.

What is Subversion?

So what is this Git alternative you speak of? Well it's called Subversion, or SVN for short.

Predating Git by 5 years, the SVN project was started in 2000 by CollabNet to create an open-source VCS. It aimed to improve upon the revision control system called Concurrent Version System (or CVS). Since 2010, SVN has been developed by Apache Software Foundation as well as becoming a part of the Apache Top-Level Projects.

SVN is a centralized, network-aware VCS. Therefore, all of your data is stored on a central server and the only way to access it, is via a network connection.

The process of making code changes is slightly simpler than Git, with one less step. Rather than cloning the entire repo, you get a working copy directly from the central repo. Then you commit those changes to the repo where you can merge them.

Pros of Git

• Stashing Work. Git allows users to take their current code changes and "stash" them to be accessed at a later time.

I've used this feature many times when working on one thing and something with a higher priority comes through the pipeline. I simply stage and stash my changes, complete the new task, and pop and apply my stashed changes to continue where I left off.

• Easier merging. This is what Git was made to do. It was built for teams and communities to better manage all of their code changes.

• Works offline. Unlike SVN, when you have the entire repo on your own machine, you don't have to be connected to a server to make any changes. You simply can make the changes without connection to the central repo, then once back online, you can then merge your changes with the central repo.

Pros of Subversion

• Handles binary files. Both SVN and Git use a model called Copy-Modify-Merge. This is fine for mergeable files, but SVN also uses the model of Lock-Modify-Unlock which is perfect for un-mergeable assets like binary files. No concurrent modifications can then be made on these files.

• Simpler. SVN removes the step to clone the entire repo to a client's local machine before making changes, eliminating a huge step in the Git process. Your team all works from one repo.

• Access Control. (This is my favorite feature of SVN)
  Have you ever noticed that everyone with access to a Git repo all have the same user permissions? In certain enterprise settings this is a huge no-no. SVN actually allows for granular path-based user permissions enabling you to allow/deny users to read/write specific folders and files.

FAQs

Why is Git so popular?

There are many aspects that could contribute to the popularity of Git. Those include:

• The dominance of Github influenced many users to naturally adopt Git
• Its fast branching and merging capabilities
• Its ability to enable users to work on code offline
• Its scalability
• Linus Torvalds started it

What are some other VCSs?

• Mercurial - a free, distributed source control management tool.
• CVS (Concurrent Versions System) - a centralized VCS.
• Fossil - a simple, high-reliability, distributed software configuration management system.
• GNU Bazaar - a distributed and client–server revision control system sponsored by Canonical.

Conclusion

So which should you use? I can't be the one to tell you that, but I can tell you that I prefer Git for almost everything.

Although, it's good to know the useful alternatives out there that utilize the centralized and distributed architectures. There's always a good solution depending on your use case.

• If you are a beginner, I would just start with Git because it is the most widely used VCS.

• If you've been using Git for a while, try investigating some of the other VCS mentioned. Just knowing they exist can be very helpful if there comes a time when your looking for one for a specific use case.

Thanks for reading! If you want more tech tips, software stuff, and bussin' blogs, you can throw me a follow on Twitter🔥🤘🏽🐶