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).
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.
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.
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.
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.
Thank you for making it to the end! I hope this short demonstration has helped you work with git’s version control.