This post has 1848 words.
This post has 10740 characters.
This post reading time is approximately 8 minute(s)
Git, a Distributed Version Control System, is very flexible, smart, and intuitive. It is also an industry standard among developers and designers.
Github provides hosting for software development version control using Git. It is a subsidiary of Microsoft, which acquired Github in 2018 for $7.5 billion. It offers all of the distributed version control and source code management functionality of Git, as well as adding its own features. It is probably the most accessibly social and most widely used Git hosting provider.
Git was created in 2005 by Linus Torvalds for the development of the Linux kernel.
The Linux kernel is the main component of the Linux operating system (OS) and the core interface between a computer’s hardware and its processes. It communicates between the two, managing resources as efficiently as possible.
The Linux kernel is a large, open source project. During most of the time that the Linux kernel was maintained (1992-2002), changes to the software were passed around as patches and archived files. In 2002, the kernel project began using a proprietary Distributed Version Control System (DVCS) called Bitkeeper.
In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed Bitkeeper broke down, and the tool‘s free of charge status was revoked. This got Linus Torvalds to create his own tool based on what he learned from working with BitKeeper.
Some of his goals in creating this new tool were:
Since 2005, Git has evolved into an easy to use tool and still retains these original qualities Linus Torvalds sought to achieve. It is very fast, efficient with large projects, and has an incredible branching system for non-linear development.
So what is centralized version control, distributed version control, and why use distributed version control such as Git instead?
A centralized version control system works on a client-server model.
There is a single, centralized, master copy of the code base, and pieces of the code that developers are working on are typically locked, or checked out, so that ONLY one developer is allowed to work on that part of the code at any one time .
Access to the code base and lock down is controlled by the server. When the developer checks their code back in, the lock down is released, so it’s available to other developers to check out.
A key part of any Version Control System (VCS) is the ability to keep track of changes that are made to the code. When a piece is checked in, a new version of that piece is created and entered or logged.
When everyone has finished working on their own piece(s) of the whole, and it’s time for a new release (version) of the application, a new version is created. That usually means entering the version numbers of all the parts that make up the application to make that version of the application.
Best known Centralized Version Control systems are Concurrent Version System, and Apache Subversion.
The best known Distributed Version Control systems are Git and Mercurial. We will be focusing on Git in this course, as it is the most popular to use and an industry standard.
There is no lockdown of code in a DVCS.
What does this mean? More than one developer, in fact, any number of developers, can be working on the code at any given time.
Every set of new changes that a developer makes to the code contains all the history of the code at the point in time he or she grabbed it from the remote repository and the new history created from the new changes he or she makes locally.
In other words, each developer has his/her own copy of the complete project in its current state at the time each developer grabs a copy or clones it locally, meaning to their desktop.
When they are done with their changes, they don’t have to wait for the last person who checked out the code to check it back in as with CVC. They can simply check it back in, or rather, push it to remote whenever they want. This has certain implications which I will discuss a bit later.
The performance of DVCS is better. There is no waiting for lockdowns to be unlocked across potentially slow networks or networks which aren't online at all. In addition, as mentioned previously, the complete code as it’s represented remotely at a given time, is on each developer’s local system.
Branching and merging of repositories is much easier to achieve in a DVCS because they are built into the system itself. We will see practical application of that when we set ourselves up with Git and Github and push our project from from our local computer to remote.
With a DVCS, you don’t need to be connected to a network all the time. You don’t even need to be connected to a network when you want to view your changes via localhost. You do, however, need to be connected to a network (internet) when downloading packages from npm or updating packages on your machine installed with Homebrew, for example. You also need to be connected to the internet when pushing changes to Github.
CVCS are purportedly easier to understand. I have never worked with one, so I personally can’t attest to that.Access control is easier, since everything is controlled from one place. That CAN be true.
This really pertains to the potential for conflicts that arise when developers independently try to push (merge) their changes to a project to remote.
This happens when developers are working on the same code piece and have two different versions of that piece.
This of course is not possible. There can only be ONE version.
They have to choose between the two versions.
Which version is better? This is when some orchestration of Git commits and merging of code to the remote master branch have to come into play.
With CVCS, you don’t have to merge different versions of the same code unless you explicitly want to, so you avoid the trickiness of merging in DVCS.
Where Git might take a bit longer to get than a CVCS, in the long run, it is very flexible, smart, and intuitive compared to CVCS.
Lastly, I came across a great article on Medium that sums up why Git can be great for everyone. Not just developers. It’s entitled Designers who Git. It’s worth it! My experience with incorporating GIT in my design workflow.
What is the Linux kernel?: RedHat
A Short History of Git: git-scm.com
Distributed vs Centralized Version Control Systems for Lotus Notes: teamstudio.com