Github Basics: Collaborative Version Control

Photo by Delaney Archer on Unsplash

What is Github?

Github is an online code hosting platform that uses the version control functionality of Git. Version control is the practice of managing changes on a project over time. Git, a version control software, is a great resource to back up your work and organize experiments without changing the main codebase. A local version control system stores the changes solely on your computer, and a remote version control stores the changes on a distributed version control system(i.e., Github).

Git Commands

In a distributed system, all users will have access to the entire repository. Anyone will be able to pull the current repository state, work independently, and then push their changes to the server. The commands to execute a pull/push are git pull, git add, git commit, and git push. Contributors will probably use these four commands repetitively over a project’s life span. However, there are many other commands, and it may seem overwhelming. Therefore, I’ll summarize some of the commands into three categories: Retrieval, Administrative, and Forward.

It’s important to note the git commands are not in any particular order. I summarized them into three categories to reduce the complexities of each command’s objective. The complete list of all commands is located here, git’s documentation page.

Demo Project

To demonstrate an example of collaboratory work with Github, let’s say there are two contributors working on a project. The objective is to have a python file that will return a list of powers of 2 and a README.md to summarize their work. The team has decided for one person to write the README and the other to work on the python file.

Let’s start with the first step, Repository Creation; log in to Github and create a new repository.

For this blog, I will act as TWO entities and work off of TWO separate working directories; the first contributor will create the repo and work on the readme, then the second will pull the repo and work on the python file.

Contributor_1

Contributor_2

The first contributor has noticed the code prints the powers of 2 instead of printing a list of powers of 2. The first will need to edit off of the code-branch branch.

Contributor_1

It’s best practice to wait for the final merge after work is done in separate branches. To recap, CONTRIBUTOR_1 created the repo and worked on the readme off a readme-branch. CONTRIBUTOR_2 pulled the repo(both main and readme-branch) and worked on the python file off the code-branch. CONTRIBUTOR_1 created some edits on a secondary branch off of CONTRIBUTOR_2’s code-branch. To close, let’s let CONTRIBUTOR_2 merge to the main and push.

Contributor_2

Thank you for making it to the end! I hope this short demonstration has helped you work with git’s version control.

--

--

--

Hello! My name is Albert Um.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Git Outta Trouble

The magic of making Game Objects appear and disappear.

Using GraphQL in a microservice oriented architecture

SINGLETON AND FACTORY PATTERN

Why you’d want to use current concurrency over GrandCentralDispatch or OperationQueues.

Understanding Sass: CSS Made Awesome

Writing Asynchronous Non-Blocking Rest API using JAVA.

Kubernetes — 1 | Introduction, Features and Components

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Albert Um

Albert Um

Hello! My name is Albert Um.

More from Medium

Sorting Techniques: CHOOSE YOUR WEAPON!

AVL Tree Implementation

Introduction to Data Structure and Algorithms With Modern JavaScript.

CS373 Spring 2022: William Johnston