About two years ago, I cannot really tell what the difference is between Git and Github. When I did the coursework, the lecturer told us to use Github to do the homework. In my mind at that time Github is good for manage homework. I don’t really understand the point of Github. In the past half a year, I almost use Git every day. Now I have a much more clear picture of the difference between Git and Github. In this blog, I will cover these two topics along with the understanding from my daily job.

Github

Idea behind github

Github is a cloud based platform built around to manage codebase. The following image shows how Github works.

From the image, we can assume the remote github is the github website. Github holds our projects code in some physical machine cluster somewhere. The github website shows the code in its machine cluster. We can assume local as you own machine and your colleagues’ machines. The idea behind this is distributed system. Every local machine(slave node) is able to communicate with remote github cluster(master node). Users can fetch code from remote node to local and push code from local to remote node.

Set up ssh key for github

The other thing I would like to cover in this section is setting up ssh key for our github since I was confused about what the point of ssh key we previously. In our github, we can have multiple ssh keys. But each ssh key can only link to one machine. The linked ssh key serves as a finger print of that specific machine. With ssh key set up in one machine, users can access github via ssh url to manipulate codebase without type username and password every time we operate over the codebase.

Here is the guide how to set up ssh key under our github accounts.

Git

Git is a version control command line tool to manage projects codebase history. Every time we run git init under a codebase folder, a .git folder will be generated inside the codebase folder recording all metadata and checkpoints of the codebase.

How to do version control

The above image shows the basic idea of git version control. Every project will have a master branch. When we try to add new feature in the codebase, we normally run git checkout -b new-feature to create a new branch called new-feature and add new feature over this branch. Before checking out new branch, we need to make sure our master branch is up to date by running git pull to drag newest version of code(others may merge new code into master). After we finish the feature, we will create a pull request for others or code owner to review. Once approved, new feature will get merged in. During the procedure of adding new feature, we continuously use git add and git commit to save code changes. Before we create pull request, we need to run git push -u origin new-feature to push our branch to remote github.

One thing we need to keep in mind, before we merge our feature in, we have to guarantee the unmodified part of code should be consistent with current codebase. That means if some features are merged in to master when we work on our own branch, we can use git merge master to sync unchanged code into our branch from master. We can also treat this command is used to relocate our branch start position after current version of code(as the image shows). We can also use git rebase master achieving same purpose. Rebase inserts others commit history in our branch. I don’t really like using git rebase since it will make my own branch massive with commit history. Sometimes, when we merge master into our branch, same part are both modified in master branch and our own branch. If this situation happens, we have to resolve conflicts determining which modification we are going to keep in our own branch(using master code or keeping our own changes).

Summary

The above content is the basic part of understanding how to work with github and git. We can also add some shorthand aligns in our bash profile or zsh file to make git command easily called.