What are Git and GitHub?

Git and GitHub are critical tools in the software development lifecycle. Despite their similarity in name, they are very different tools. Git is Source Control software that runs just like any other application on your computer. GitHub is a web application and service that supplements Git projects with tools helpful for software development. The rest of this post will further define these two essential tools and expand on their differences.

Before understanding what Git and GitHub are, you first need an introduction to Source Control.

Source Control

Source Control is similar to tracking changes in a Word document. As you make changes Word will show you what’s changed and occasionally saves a version that you can revert back to later. Source Control does the same thing with files that are part of a programming project. Any file can be tracked. Images, videos, Word documents, but most importantly, text files. Source code files are just text files that can be interpreted by programming languages. That’s what makes source code files unique. They are executed and result in some behavior. When your source code executes that desired behavior, you can lock a version of that file in history using Source Control. Once that version is locked into history, you can always go back to it. This is very helpful if a later version of your source code breaks your expected behavior.

Since Source Control can work with any file, you could maintain the history of any project you’re working on. If you’re writing a story and wanted to try a different approach, you could save your work and try something new. If you don’t like it, just revert back to your original version.

As opposed to tracked changes in a Word document which work with one file, most Source Control systems work at the directory or folder level. Actions like adding, removing, or renaming a file are all tracked. Changes to sub-directories are also tracked. So, Source Control is more like tracking changes of all the Word documents contained within a folder.

Git

Git is Source Control software. It runs just like any other program on your computer. There are some tools that allow you to work with Git through a graphical user interface, but you can also use the command line.

A Git repository, often shortened to repo, is just a directory of files with changes tracked by Git. Any directory can be a repo but most of the time, a single directory represents a single project. For example, all the files required to build an iOS app would be in a single directory, referred to as a repo, and managed by Git. A corresponding Android app might have its own Git repo.

Just like tracked changes in a Word document, Git will track all the changes you make to each file. Since it tracks the entire directory it also keeps a history of when files are added, moved, renamed, or deleted.

Another difference between tracked changes in a Word doc and Git is that Word saves changes as you work. In Git, you must commit changes to history. It’s a best practice to frequently commit working, stable code. When committing code, you can provide a helpful message explaining what the changes do.

Below are two of the primary features of Git you may have heard of.

Branching

In Git, a branch is a series of commits. When you start tracking a directory with Git, you’ll have a single branch. You can think of tracked changes in a Word doc, with a version history as a single branch. If you wanted to experiment with an entirely new format for a Word document, you might create a copy of the document. That way you can try out a new format, and if you don’t like it, just delete the copy. Git branching allows you to do the same thing. You can create a branch to try a new color scheme for all the buttons in your app. If you don’t like it, switch back to the other branch and your buttons will be just as you left them. You can have as many branches as you’d like to work on bugs, features, or proof of concepts. Git efficiently keeps track of the differences in these branches and makes it easy to evaluate the history of your application.

Many organizations leverage branching as part of their software development workflow. Usually one branch is the gold copy of the code. It’s the branch that an application is built from to be shipped to customers. That main branch will usually have special write permissions to ensure the code doesn’t become corrupt. For example, an individual developer can’t just change the button color without another developer approving those changes.

Merging

Assuming there is a single branch that’s shipped to customers, you need some way to get code from other branches into the main branch. To do that, you use the Git merge feature. When commits from a branch are merged into the main branch, the merged branch’s commits become a part of the main branch’s history. Just as if the commits were made directly to the main branch.

Git’s merge tool is sophisticated and helps you identify changes and conflicts. Before merging, you can easily identify the differences between two branches to make sure you want to merge those code changes. If there aren’t any conflicts between the branches you’re merging, Git can do the merge automatically. If there are conflicts, Git makes it easy to resolve the conflict by asking you what changes you want to keep for each conflict. This can happen if two developers make changes to the same file and are attempting to merge those changes into the main branch.

In the situation where you wanted to try out a new format for your Word doc, a merge would be like copying all your changes to the original. If you like all your changes, it’s easy, just copy them all into the original Word doc. If you only want some of the changes, you’d have to copy them in piece by piece. This would be similar to Git’s auto-merge capability. If a colleague of yours made changes to the Word doc, you would need to get together and make sure both of your changes make it into the document. This is how Git’s merge conflict resolution works.

Git is Distributed

Before getting into GitHub, it’s important to understand Git’s distributed nature. When you want to share your project and Git repository, you can push it up to a server often referred to generically as the remote repository. Git needs a name for this repository and it’s usually named origin. Once you’ve pushed it up, other developers can copy it to their computer and work on the project. This is called cloning. A cloned project will have access to all the same files, commits, and branches.

Many other Source Control systems are centralized. The code is stored on a single server and developers must check-out code to make changes. While they have the code checked-out, no other developers can make changes. If you’ve ever used Sharepoint, it has similar check-in and check-out functionality. As teams and projects grew in size, this became a constraint. Centralized Source Control was a significant constraint on open source projects. Developers all over the world needed a way to collaborate and independently make code changes. Git provided a decentralized solution causing it to grow in popularity along with the open source world.

GitHub

GitHub is a web app that supplements Git repos. When you have a repo you want to share you can push it to GitHub which will act as your remote server. A GitHub repo is just a Git repo hosted by GitHub. You can even create a new repo on GitHub then clone it to your machine. On your machine, it’s just a Git repo.

GiHub allows you to do a lot of useful things with your repo. Most significant are the collaboration tools. A GitHub repository can be public or private and you can determine what permissions other developers have. Likewise, you can contribute to other repos. GitHub can send you notifications about your repo and facilitate discussions. The feature list for GitHub is long, but there are two major collaboration tools.

Issues

Issues can be created as part of any GitHub repo. You can use issues to track bugs, document requirements for a new feature, or have a discussion on new ideas for your application. Issues can be tagged to identify their type, assigned to developers, and added to GitHub Projects. Since Issues are kept close to the code, it makes organizing, planning, and executing development work easy. When you create an Issue, all you’re required to give is a title. Optionally you can provide a description and attach images, videos, or documents. With this flexibility, you can leverage Issues in anyway to support your development workflow.

Pull Requests

Pull Requests enhance the Git merge feature. When you make commits to a branch on your computer, they only exist on your computer. When you’re ready to share your work, you can push your branch up to your GitHub repo. Usually, applications are built from the code in the main branch of your GitHub repo. To prevent corruption, that branch is protected from developers writing or pushing to it. So, to get your code into the main branch, you open a Pull Request using GitHub. As part of a Pull Request, GitHub shows all the differences between your code and the main branch and initiates a code review. One or more developers will review your code by leaving comments using GitHub. Once the code is deemed acceptable for the main branch, it’s approved. At that point, GitHub gives you the option to merge your Pull Request. Merging a Pull Request is just like merging two branches together on your computer. After the code is merged, you can switch to the main branch on your computer and pull down the latest changes from GitHub. Then, you can create another branch and repeat the process. This is a very common development workflow.

Conclusion

Git and GitHub are powerful tools that greatly aide in the development workflow. They have many more features than those called out in this post. Hopefully with the information in this post, you can start to make use of these tools and learn more about all their capabilities. Or next time you hear them come up in conversation, you can join in on the fun!