“Why GitHub?” is a Great Question

Photo by Oscar Nord on Unsplash

Who is using GitHub?

You don’t have to be a Silicon Valley developer or a seasoned coder for GitHub to be the right platform for your project. Check out some government entities all over the world who are using GitHub here! Below is a sneak peek of some U.S. cities that have acquired a GitHub handle.


Why Should a Non-Coder Use GitHub?

I never intended to get into GitHub or become a coding whiz. Actually I never refer to myself as a coding whiz, but I have gotten quite proficient in R (read more about R) and am slowly moving into the GitHub realm. Here are a few reasons I jumped on the GitHub train:

  1. I can record and save my complicated, multistep quantitative calculations of my raw data as easy as saving a poem in a word document without having to format as an equation every time.

Photo by Roman Mager on Unsplash

  1. I can save multiple versions of the document I am working on at different points in time (e.g. last week’s copy, yesterday’s copy, this morning’s copy, this evening’s copy) and retrieve any of them whenever I want to. There is no fear of accidentally deleting any of those versions as well or accidentally throwing them out in the trash. Oops!

Photo by Steve Johnson on Unsplash

  1. I can easily share and work on data (CSV or Excel files) with collaborators. If I accidentally overwrite a team member’s work that was actually better than my revision, I can go back revert my changes very easily. No need to stress! Let’s just revert!

Photo by Ayo Ogunseinde on Unsplash

  1. GitHub serves as a cloud version of my computer files. Say I forget my personal laptop, but have access to the internet. I can sign into GitHub and download my WeddingPictures.jpg, BestNovellaEver.docx, Codingforlyfe.Rmd, and SomeDocumentwithImportantText.txt all from a web browser.

Photo by Samuel Zeller on Unsplash

  1. Finally, I can create and customize my own website without having to know HTML or CSS. So:

Photo by Kevin Grieve on Unsplash


Key Terminology

This is a developing glossary of common git terms.

Terms Description
repository A project, collection of files and folders, and tracking of each change that has occurred and been submitted to this project by all collaborators
commit Creating an identifier for a set of changes you have made to the project (e.g. create a new folder, or change the value in a spreadsheet) so it can be called upon and viewed later.
pull Merge the most recent remote version with your local version if the repository.
push Merge your local changes to the remote version of the repository.
merge Combine changes in more than one version of a repository (either git does this automatically or you may have to do this manually if there are merge conflicts).
HEAD Current snapshot
master Is the main branch of a project. At OHI we don’t worry too much about branches. We have a draft branch for our ohi-global and then a master one… For ohiprep we just have a single one since it’s not as worrisome if each collaborator makes direct changes to a single master/main version.
remote The remote repository on GitHub that every other non-draft version can pull and push from.
branch Multiple branches can exist for a repository. A different version of the main project that can be used if there are many collaborators that want to try editing without affecting the main version of the project.
forking Makes an entirely new copy of the project. Different from branches, because can’t just be merged. If want to submit suggestions to project need to submit a “pull request”
pull request A user-friendly interface for collaborators to discuss changes, make comments to the project before merging different people’s suggestions.

The Basic Workflow



1. Pull:

To take the copy of a project in the remote computer and pull it into your personal computer.


Now Katie and Phil both have a version of this dataset that was located in Remote.


2. Commit:

Katie decides she wants to make some of her own changes. She realizes that the tonnes value for New Caledonia’s Trochus shells in 2000 is actually supposed to be 86 tonnes not 96 tonnes!


After she saves that, the updated file only exists on Katie’s laptop. How does she make sure her collaborator Phil gets the updated changes? She must commit. This essentially places the new tonnes.csv file onto a platter ready to be served (terrible analogy?).


3. Pull Again:

Before Katie updates the remote computer with her changes to the New Caledonia’s tonnes data, she must pull once more in case Phil was working at the same time and has made updates to the remote!


4. Push:

Now Katie can finally push her New Caledonia changes to the Remote version.



Thanks all for reading,

Iwen