Have you ever found yourself ready to get started on an awesome project, but stumbled across the age-old question; what the heck is the difference between Git and Github? Don’t worry, after reading this, you will finally be able to sleep at night and solidify the difference between Git and Github! Let’s stop jabbering and jump right in shall we?

Git was developed by Linus Torvalds, the creator of Linux back in 2005 for the development of the Linux kernel. Linux had been using BitKeeper, a version control system, for almost all their projects. But then the copyright holder of BitKeeper, Larry McVoy, withdrew free use of the product after claiming that Andrew Tridgell had created SourcePuller by reverse-engineering the BitKeeper protocols. Linux’s found itself in a situation where it needed a replacement, a need for creating a free, open-source version control system. It took them less than a year to come up with the maiden version of Git.

Git runs locally on a computer, does not require any cloud hosting service to operate, and it is self-sufficient. Git is also a version control system that allows you to save different states of your project and roll back to previous versions if necessary.

A version control system (VCS) is a system that records all the changes made to a file or a set of files through commits (aka snapshots). You can think of commits like when you would save your progress on a video game. When a game saves, it records all the new progress to the initial save file: Fully recording all changes and maintaining previously recorded changes.

Anyway, let’s say you have an image called ElonMuskMeme.py and you are actively making changes to it, the VCS will be able to keep track of these specific changes so that you can go back to any previous versions of your image before you made any edits. This creates an environment that structures programmer collaboration to the best of its ability, which is exactly what every programmer is looking for!

If you go inside the mind of Git, it thinks about its data differently than the majority of other VCS out there. Other systems store their information as a list of file-based changes. Other VCS’s think of the information it stores as a set of files including the changes made to each file over time (this is commonly described as delta-based version control as seen below).

Git on the other hand thinks of its data more like a series of snapshots of a miniature filesystem. With Git, Every time you commit, or save, the state of your project, Git essentially takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots exactly like the picture below.

Git has three main states that your files can be stored as. These sections correspond to three stages of a project — modified, staged, and committed.

Now that we are familiar with the modified staged, and committed states we can get into the three main sections of a Git project: the working tree, the staging area, and the Git directory.

The working tree includes all the files you currently are working on. Within the working tree, you can modify and change the files any way you please — for example, using a text editor to make small changes to markdown content. It can be seen as a file system where you can view, edit, and modify your current files. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.

The staging area is a file, generally contained in your Git directory. The staging area is used before you commit a change to your repository. It’s a safe area where you can examine changes, organize those that will be committed, and discard any that won’t be committed. You also exclude changes here when working with partially staged files. Its technical name in Git parlance is the “index”, but the phrase “staging area” works just as well.

The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.

1. You modify files in your working tree.

2. You selectively stage just those changes you want to be part of your next commit, which adds only those changes to the staging area.

3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.

Overall git is just a really powerful version control system for tracking changes to files and coordinating work between multiple people. Working on team projects has never been easier! You can upload your project to an online repository so that anyone else from your team can contribute. Because of git, multiple people are able to work together on the same file at the same time without having any issues. What used to take hours of going back and forth on different versions of a document, you can now do in minutes from anywhere you are.

Seeing the need for a more efficient way of sharing and managing source code between developers, software engineer Tom Preston-Werner began working on GitHub in March 2008. It used to be used by a few daring people and even fewer companies. The small bootstrapped startup business raised $1 million in funding from an angel investor. By September 2008, they raised $100 million from venture capitalists and that December. Less than two years later, it has become a central hub for software development and reached 1 million users. As the startup was showing mass potential for their rapidly growing startup they were acquired by Microsoft for $7.5 billion. It all started because of a simple text editor that was created over a few months time.

GitHub is a web-based hosting service for software development projects that use the Git revision control system. It offers all of the distributed version control and source code management functionality of Git as well as adding its own features. It provides access control and several collaboration features such as bug tracking, feature requests, task management, and wikis for every project.

Getting started with Github can be a little intimidating. All these repositories pull requests and branches. What does all of that mean? Well, that's what we’re going to find out.

A repository in the context of GitHub is a file that contains a list of instructions for interpreting, updating, and compiling computer code. It is most commonly used by programmers and web developers to beta-test and update new versions of computer code. A list of beneficials can be seen from GitHub’s handy online source Github Docs;

You can use repositories to manage your work and collaborate with others.

You can use issues to collect user feedback, report software bugs, and organize tasks you’d like to accomplish. For more information, see “About issues.”

You can use discussions to ask and answer questions, share information, make announcements, and conduct or participate in conversations about a project. For more information, see “About discussions.”

You can use pull requests to propose changes to a repository. For more information, see “About pull requests.”

You can use project boards to organize and prioritize your issues and pull requests. For more information, see “About project boards.”

GitHub is an awesome place for developers to store their code. It has a ton of features that are useful for other developers. One of those features is the ability to create pull requests. It can be a little confusing what this actually means and how it works, especially if you don’t use Git. But in the simplest of terms, A GitHub pull request allows you to send code changes on an existing project or repository from your personal account to the original owner of that repository. Once the owner has accepted your request, the code will be merged into the original repository.

What is a GitHub branch? A Github branch, or just branch, is a different path you can take in the version control structure. It is important to think of branches not as copies of your repository (as they may be in some other version control systems), but rather as different paths through the same version control structure. Branching is the act of copying a central repository and making it different from the parent. Compared to a copy of a repository, which creates an exact copy and carries all history, a branch drops some of the history. While copies are intended to be individual “copies”, branches are meant to diverge or differ from each other and this is accomplished by limiting the history that is shared between branches.

GitHub is a website that allows developers to create projects and then share code with other users. These projects are written in different programming languages by various users. It has a social networking aspect to it (similar to Facebook) which allows users to discuss issues that are relevant to the project as well as submit new features. Overall, the site is used for version control of programs which makes it important for developers who wish to upload their programs and allow others to edit their programs and make changes.