An Intro to Git and Github and Why You Should Git

Post Statistics

This post has 1848 words.
This post has 10740 characters.
This post reading time is approximately 8 minute(s)

Why Git and Github?

Git, a Distributed Version Control System, is very flexiblesmart, and intuitive. It is also an industry standard among developers and designers.

What is Github?

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.

Short History of Git

Git was created in 2005 by Linus Torvalds for the development of the Linux kernel.

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 twomanaging resources as efficiently as possible.

The Linux kernel is open source

The Linux kernel is a largeopen 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.

Relationship broken between Linux kernel community and 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:

Git is easy to use while retaining original qualities

Since 2005Git has evolved into an easy to use tool and still retains these original qualities Linus Torvalds sought to achieve. It is very fastefficient with large projects, and has an incredible branching system for non-linear development.

Centralized vs Distributed Version Control

So what is centralized version controldistributed version control, and why use distributed version control such as Git instead?

Centralized Version Control

centralized version control system works on a client-server model.

There is a singlecentralizedmaster 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 .

Centralized Version Control: access to the code base

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.

Version Control: key part

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.

Version Control: new version

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

Best known Centralized Version Control systems are Concurrent Version System, and Apache Subversion.

Best known Distributed Version Control Systems

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.

Differences between CVCS and DVCS

There is no lockdown of code in a DVCS.

What does this meanMore than one developer, in fact, any number of developerscan 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 wordseach 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 locallymeaning 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 ratherpush 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?

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.

CVC vs DVC: differences

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.

So why Git, then?

Where Git might take a bit longer to get than a CVCS, in the long run, it is very flexiblesmart, and intuitive compared to CVCS.

Git Isn’t Just For Developers

Lastly, I came across a great article on Medium that sums up why Git can be great for everyoneNot just developers. It’s entitled Designers who Git. It’s worth it! My experience with incorporating GIT in my design workflow.

Related Resources

What is the Linux kernel?RedHat
A Short History of
Distributed vs Centralized Version Control Systems for Lotus