Github: What you need to know going into a Software Development job
Github’s praises have been sung throughout the industry by developers far and wide. Entry level developers are either thrown to the wolves or just expected to know how to navigate this technology. Given the prevalence of Git, I thought it’d be fitting to give an overview of the inner workings.
Github is used for version control, but what does that mean? When you are working on a team with multiple developers, version control comes into play so that everyone’s work does not overlap and all of the code is saved.
I’ll use the example of a company website. The code for the website will likely be hosted on the company’s servers, but the most up to date code will also be on Github, serving as the master branch of its own repository. All of the developers that work on the website will have that code downloaded to run locally on their individual machines.
Before you start making changes, a branch needs to be created to store the changes. The easiest explanation of what a branch is is to remember back to school when teachers used projectors. Notes were written with a marker on a clear sheet so the writing would be projected through the light and lens. A branch is basically placing a second clear sheet on top so that the original copy can be preserved.
Branches can be created on Github itself, in the terminal, or in the code editor. Selecting the dropdown in a repo (shown below) can allow you to view all of the branches that have been created with the same master. If you do decide to create a branch through Github, you will need to ‘git pull’ that branch onto your computer before using the ‘git branch branchname’ command to switch to the designated branch. Another fun tip is that a branch does not need to be off of the master and can use another branch as its base.
When the coding is done and everything is working correctly, you will want to push that up to Github. The command ‘git status’ will show all of the files that have been altered. The command ‘git add .’ will package all of the files that have been changed. There are chances that because you are running a website locally, some configuration files needed to be changed in order to run correctly. Those should not be uploaded to Github so you should individually add each file through ‘git add filepath’. A ‘git commit -m “message”’ should detail what the overall change was for, whether it be a bug fix or an added feature. The final command is ‘git push’ which will sent the entire package to Github.
From there, you will create a pull request, or a “PR” for short. A pull request is a form that details the changes that are on the branch and gives a side by side comparison of your code and what appears in the master. Depending on the internal policies of the company, a number of your coworkers will review the code to make sure that nothing will break the master branch before it gets merged in.
A good tip is that when coworkers are looking over your intended changes, the commit history will be visible. Because of this, a cleanly tracked history of your code is desirable with each commit implementing a separate portion. Going back to the website example, a commit history of “Implemented site shopping cart”, “Added shopping cart persistent history on page refresh”, and “Fixed shopping cart price bug after testing” allows others to see a clean progression of what you have worked on. A single commit of, “Implemented shopping cart”, is acceptable, but remains quite vague in your overall approach.
It is quite cumbersome to push unfinished code while keeping in mind that your work will be scrutinized by peers. Cleaning up your history is something that only needs to done at the very end before writing up a pull request. Inside the terminal, the ‘git log’ command will show the history of commits that this branch has made. Identify which commit messages are not needed and how many commits ago it was made. If my previous commit was not needed, I can use the command ‘git reset HEAD~1". This will delete the previous commit made on this branch and add the files committed back into my changed files tree where I can ‘git add filepath’, git commit -m ‘message’, with ‘git push -f’.
Version control comes into play after a new branch has been merged into the master. Any other developer that tries to push up code after your code has been merged into the master branch will get a merge conflict. This means that the master branch on Github is different from the master branch on their local computer and allowing the push would mean your changes get deleted when merged. They will need to rebase which means having to ‘git pull’ to update the changes to their local master branch, ‘git stash’ to store their current changes, ‘git fetch’ to update the branch with the latest changes, and ‘git stash apply’ to add back the changes that they had previous.
