Basic GitHub Tutorial

From EOVSA Wiki
Jump to navigation Jump to search


GitHub is a web-based Git repository hosting service. It offers all of the distributed version control and source code management (SCM) 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 (from wikipedia [1])

We use GitHub to manage and develop software collaboratively. Currently we have two such software packages on GitHub: eovsa (for EOVSA operation and calibration) and suncasa (for processing and visualizing radio imaging spectroscopic data). Tons of detailed tutorials can be found on and elsewhere. In the following, some very basic instructions are provided (to busy/lazy people like you!) to demonstrate the minimal use of GitHub.

Understand the GitHub Workflow

A nice and precise description is available here.

Setup GitHub

Register a GitHub account

Too straightforward! Just follow the instructions here.

Setup SSH for remote access

We need to set up remote access to your online GitHub repository. There are multiple methods of doing this, but I am used to the SSH method. Detailed instructions are available here. But here are my steps of doing this. First, check if you already have SSH keys.

ls -al ~/.ssh

By default, the filenames of the public keys are one of the following:,,, If you don't have an existing public and private key pair, or don't wish to use any that are available to connect to GitHub, then generate a new SSH key.

ssh-keygen -t rsa -b 4096 -C ""

You'll be prompted for a few questions. Just press enter to advance. Before adding the new SSH key to the ssh-agent, check if your ssh-agent is running:

eval "$(ssh-agent -s)"

If it says something like "Agent pid 59566", you are good. Now add the SSH key:

ssh-add ~/.ssh/id_rsa

Now that you have a SSH key on your machine, you can proceed and add it to GitHub following these instructions.

Minimal use of GitHub

Start your own repository from scratch

Suppose you have a new brilliant idea and want to convert it to working codes. You decided to make up a repository to put your codes in. First, go to and create a new repository there called "myprecious". Then open a terminal window on your computer, create a directory named "myprecious", and add some descriptions in a file called ""

mkdir myprecious
cd myprecious
echo "# myprecious" >>

First, we need to initialize it to be a git repository

git init

You are so excited and pull an all-nighter putting your codes together (remember to save them!). Now you have a lot of stuff in your directory "myprecious". You can now add them into the git repository and commit the changes:

git add .
git commit -m "a message describing your commit"

You are proud of yourself and decide to push all the codes to to let everyone see. But before that, define your remote repository on GitHub:

git remote add origin

Check your remote destinations:

git remote -v

You'll see something like this:

origin (fetch)
origin (push)

Now you can push your codes to Github and complete your edits:

git push origin master

Develop codes collaboratively

Now suppose you would like to collaborate with others to develop some brilliant software package. Detailed instructions can be found from this link. But here are just some basic steps. Let us use our suncasa package as an example. First, go to the original owner's package page and click "Fork" in the upper-right corner of the page. Now you have the same repository under your own GitHub account. Say the url to your forked repository is Now clone a copy of the GitHub repository to your machine:

git clone

After that, you will have a folder named "suncasa" under your current directory. Everything in this folder are exactly the same as the online repository. The remote destination should have already been set. You will have something like this after running

git remote -v
origin (fetch)
origin (push)

Note you are now working under the forked repo, or your own copy of the original repository. You can make any changes you like (because this is your own repo!). After all the edits, you can add, commit, and push all the changes you made to your own forked repo (same as those in the previous section). This repo is now totally independent with the original one (it has been "forked" away, indeed). But in the mean time, the original owner may make additional changes since you cloned it, and sometimes you would like to keep up with those changes. To sync those changes to your own forked repo, we can firstly add the original owners GitHub repo (or "upstream" repo) as a remote destination:

git remote add upstream

Now your "git remote -v" output would be like this:

origin (fetch)
origin (push)
upstream (fetch)
upstream (push)

The first two lines are your own forked Github repo, and the 3rd and 4th lines are the original owner's repo. To do the sync, you run the following commands:

git fetch upstream
git checkout master
git merge upstream/master

The first command "fetch"es all info from the upstream repo (from the original owner). The second command makes sure you are working under your own local forked repo. The third command compares the local commits with the remote repo and merges all the changes.

Once you've done all the improvements and get very proud of yourself, certainly you want to let the original owner know and ask him/her to update the codes (because now your repo is better than his/hers!). To do this, you can submit a pull request via GitHub. The original owner will receive an email notifying that a pull-request has been issued. (S)he will review the changes, have a discussion with the proposer, make any additional commits if necessary, and finally accept the pull request. After that, everything are updated. The original and forked repos merge together and another round of development may start.

what to do with conflicts?

In github's pull request page, you can click the "Resolve Conflict" button, which brings you to a page with markups to indicate the conflicts. Edit the file as appropriate to resolve the conflicts. Then you will be brought back to the pull request page, commit the changes, and merge pull request.