This article was written by a guest author.
For my students, one of the first services we add to their toolbelts is GitHub, a place where they can “publish code and collaborate.” Students also benefit from using the GitKraken Client, which has proven to be a fantastic way of enabling students to engage in a workflow and familiarize themselves with the vocabulary of version control with Git.
At some point, however, students confound GitHub vs Git, often thinking they are tightly related, or even the same thing. They are, in fact, two very different things: Git is a program for managing source code, while GitHub is a web application that hosts a copy of your repository on a server.
If you use GitHub, or desktop tools like the GitKraken Client, then you have also been using Git – maybe without even realizing it. Indeed, Git and GitHub are so intertwined, many folks think of them as the same thing. In this article, we’ll explore what Git is, how to collaborate with just Git (without GitHub!), and the great conveniences that collaborating with Git and GitHub provides.
Whether you’re just getting started with Git and GitHub, or have used these tools for years, the GitKraken Client can help you streamline your workflow and collaboration with better visualization and risk management.
Git is Just a Program
I’m old enough to remember a time when Git was new, and there was no GitHub. Imagine a world without the Octocat!
Git is just a program that runs on your development machine. Unlike desktop applications, Git is a command-line only program. To initialize a directory of source code as a repository, you run
git init. Git creates a hidden subdirectory named
.git, within which it stores its configuration and all the history of your commits.
You stage commits by running
git add, commit code changes with
git commit, and, if you are like most developers, you use just a handful of Git commands for the majority of the work you do. As a solo developer, all you really need is Git itself; it is just a program, installed on your development machine, that you run via the command line, to track changes to your source code.
Collaborating with Just Git
In addition to enabling you to create commits and track changes to your source code, Git itself includes features that enable you to collaborate with others. By design, Git is a distributed version control system – no centralized server is necessary, and each developer on a team has an independent, complete copy of a repository. This enables you and your teammates to progress independently.
But then, how might one team member share their new code changes with another team member?
Git provides a feature, git-format-patch, that enables you to generate a patchset, consisting of individual patches. Each “patch” is a text file containing the changes within a single commit – very similar to what you see in a diff.
A patchset is a collection of these patch files. Git also provides a command that enables you to create and send emails with the patchset. Lastly, Git enables you to take a team member’s patchset and apply those commits to your copy of the repository.
Indeed, an email-based workflow with Git involves team members sending their changes to each other via email for code review, and, once approved, applying those patches to a repository.
Sound archaic? Many project teams, including the Git team itself, use this email-based workflow, and there are many benefits to working with patchsets. One drawback to this scenario – where each team member has a copy of the repo in an email-based collaborative workflow – is that each team member is responsible for grabbing approved patchsets and applying them to their copy of the Git repository.
The GitKraken Client offers a secure, deep integration with GitHub, allowing you to quickly generate SSH keys for safe data encryption, so you can confidently push, pull, and fork from your remotes.
Staying in Sync with a Server
To alleviate the burden of each team member manually applying approved patches to their local repositories, many teams designate an extra responsibility to one or two people, applying the approved patches to a “special” repository hosted on a server. This special repository is “remote,” meaning it is a copy of the repository residing on a server rather than your local development machine, and we often call it the origin or sometimes upstream.
By enabling each team member to access the remote repository on the server via SSH, one could manually log in, grab the latest changes that were applied to the origin, and apply those changes to their local repository. However, Git provides commands to do this for you.
When we add a remote via
git add remote, Git adds information about the remote repository to its .git/config file. By default, Git names this remote repository “origin.” Once the remote is configured, you can quickly apply patches to the remote repository with
git push; and download and apply patches to their local repository with
In this scenario, a common email-based Git workflow would involve:
- Team members emailing patchsets to a common email list
- Team members reviewing, revising, re-sending and, ultimately, approving patchsets
- One team member taking the responsibility of applying the patches to their local repository, pushing those changes to origin, and notifying that the patchset has been merged
- Remaining team members pulling those changes from the origin, applying those changes to their local repositories
Despite its merits, some developers might find this workflow a bit labor-intensive. It does have its place, but it requires 1) setting up a server and 2) a disciplined approach to generating patches and sharing those changes. This, perhaps, is part of what drove Chris Wanstrath, PJ Hyatt, and Tom Preston-Werner to create GitHub.
GitHub is a Server (and More)
While it is indeed many things, GitHub is, at its core, providing you and your team with a server. Instead of spinning up and managing your own server to provide shared access to a repository, you can create an account on GitHub and use its user interface to create and manage a remote “origin” repository.
We use Git, the software on our development machines, to track our changes just as before, and we push and pull our changes to the remote origin on a server, but now that server is provided by GitHub. In addition, GitHub provides an alternative to the patchset-based email workflow: pull requests.
Much has been written about using GitHub to collaborate and about workflows, like Git flow, using Git and GitHub together. Even with the numerous, powerful features that GitHub provides developers, its essential service is providing teams with a server upon which to share and manage their remote origin repository.
Git vs GitHub? No – Git and GitHub!
Just as GitHub makes working with Git on a server easier, GitKraken makes working with Git (and GitHub!) easier too. At its core, a tool like the GitKraken Client, now with a GUI and CLI, provides you with a graphical user interface that runs Git on your behalf. For my students, starting with this Git client has been a game-changer, as it enables students to engage in committing, branching, pushing, and pulling quickly without the need to memorize Git commands and options first.
Remember, despite its numerous features, Git is just a program we use to manage our source code. Similarly, despite GitHub’s numerous features, it is “just” a server (sorry Octocat!) for hosting shared access to a remote origin repository, for team collaboration.
The GitHub integration offered by the GitKraken Client provides a better experience for creating and merging GitHub pull requests, managing GitHub issues, cloning and forking remotes, and more.