Common Questions

Can You Use Git Without GitHub?

Can you use Git without GitHub?

The short answer is yes, you can. Git is a tool for revision control. GitHub is an online service that allows you to store, manage, and share Git repositories in the cloud. You can use Git with online services other than GitHub, with an in-house server, or on your local computer without any server at all.

First, let’s look at what Git is. Then, let’s see what GitHub and other Git-hosting services have to offer.

What Is Git?

Git is a revision control tool. It’s most often associated with software development, but you can use it to track changes in any file. For example, Git has gained a lot of traction as a tool for managing system configuration and software deployment via infrastructure-as-code best practices.Whether you decide to share your code with a team via a server or use it to manage your code locally, your Git repository looks the same. So, that’s why you can use Git without GitHub: Git works as a standalone tool or with a server.

Because of its distributed nature, Git is different from most other version-control systems. All computers that share a set of files (a repository, in Git terminology) have a complete set of files and changes. So, whether you decide to share your code with a team via a server or use it to manage your code locally, your repository looks the same.

So, that’s why you can use Git without GitHub: Git works as a standalone tool or with a server.

Let’s talk about Git’s version-control features.

What Is Revision Control?

The purpose of revision control is to track changes to files, make it easy to see those changes, and provide an easy way for you to shift from one revision to another.

Let’s look at a typical workflow using Git terminology. These examples will use Git on a Unix system, but the concepts apply to any system that supports Git.

Create a Git Repository

To track a file, you need to put it in a repository:

$ mkdir git_test
$ cd git_test
$ git init
Initialized empty Git repository in /Users/egoebelbecker/git_test/.git/

The git init command creates a repository in the current directory.

$ touch test.txt
$ git add test.txt
$ git commit -m "Initial commit" .
[master (root-commit) 7e33531] Initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test.txt

Touch created an empty file.

Git add test.txt added the file to the repository.

But the change wasn’t applied to the repository until git commit. This is an important concept; Git doesn’t track changes until you commit them. This initial commit has a revision ID of 7e33531.

Commit a Change to Git

Now, change the file.

$ echo foo > test.txt
$ cat test.txt
foo
$ git commit -m "Added foo" test.txt
[master a6beff0] Added foo
 1 file changed, 1 insertion(+)

After adding some text to the file, commit added the change to the repository. The new revision ID is a6beff0.

Compare Files With Git

Now, you can compare the two commits with their IDs:

$ git diff 7e33531 a6beff0
diff --git a/test.txt b/test.txt
index e69de29..257cc56 100644
--- a/test.txt
+++ b/test.txt
@@ -0,0 +1 @@
+foo

The output shows the file being added and then modified. Don’t worry; you don’t have to learn to read the diff—many tools can read it for you (but you can learn it if you want to).

Finally, move to a previous revision with checkout:

$ git checkout 7e33531
Note: switching to '7e33531'.
You are in 'detached HEAD' state. You can look around, make experimental
changes, and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
  git switch -c 
Or undo this operation with:
  git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 7e33531 Initial commit
$ cat test.txt
$ 

Passing the previous revision ID to git checkout changes the current working directory to that state.

Git’s default behavior, when you move back like this, is to warn you that you are in a “detached head” state. It also gives you instructions on how to turn the warning off. The warning means that you and your repository are no longer in sync. This isn’t a problem if you’re aware of it.

The HEAD that Git warns you about is a pointer to the last commit in your current branch. The warning also hints that you might want to work in a new branch instead of a detached head.

A branch is a set of changes. When you create a repository, it has one branch, the master or “trunk.” You can start a new branch at any point in an existing one. Branches can be merged.

Branching allows you to work on multiple versions of your code at a time without conflicts. For example, one branch can be for bug fixes to the release in current production, while another is for working on new features. You (or your team) can work in separate branches without causing conflicts. Later, the branches can be merged, and if there are any conflicts, you can sort them out then.

How and why to use branches is a deep and sometimes controversial topic.

This overview of Git is only the tip of the iceberg. Git has many other features for managing source code, such as tagging and pull requests.

Distributed Version Control

A Git server provides remote storage for a Git repository. You push and pull changes to your repo. For an individual developer, a Git server acts as a backup, and an online service like GitHub is an off-site backup.

For a team, a Git server is a coordination point for code changes. One developer may work on bugs on a “production” branch and push their changes when it’s time to release a fix. Another might work on new features on a “development” branch.

GitHub repository
A GitHub repository. Image by Markus Winkler from Pixabay.

When a set of features is ready for release, the developer working on the features creates a pull request that lists the changes required to merge to production. The team reviews the changes, and they are merged (or not).

That’s an oversimplified example, but it demonstrates how distributed revision control provides teams with tools for managing code.

GitHub is an online Git service. It provides all of the features of a Git server, as well as many others. And GitHub isn’t the only service. Two of its main competitors are Bitbucket and GitLab; both offer online Git servers and their own set of value-added features.

Git Without Github? It’s up to You

Git is the most widely used revision-control tool for many reasons. It’s a powerful tool that works on all major operating systems that look the same to developers whether they’re working alone or with a team via a Git server.

GitHub is a popular online service that’s become synonymous with open source and Git. Many public and private projects host their code there to use Git and GitHub’s collaboration tools.

But while you can’t use GitHub without Git, you certainly can use Git without GitHub.

This post was written by Eric Goebelbecker. Eric has worked in the financial markets in New York City for 25 years, developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective!).