Billy Fung

Github and Version Control

do you git it?

Billy Fung / 2016-01-18


Git and Github usage

One of the most useful skills to have is the ability to work and collaborate with other people on a project. Git, and Github is usually the tool of choice for most programmers these days, although in the past I have actually used other versioning and control options, like SVN. What Git allows you to do is be able to work independently on a project, say for example, creating a feature for the application, and then when you are done, you can submit that feature to be added to the master source code. Also, many people use Github to show repositories of their projects, and code, so that for anybody looking, they can see how a person’s coding style looks like.

Useful commands

I’ve been using Github as a place to put my code for some time now, but it wasn’t until recently that I used it as a place to collaborate with somebody on a project. The usage and commands of Git become quite different once you’re actually using it as a tool to manage different snapshots of code. For example, my entire website is actually handled by Github, and the process of writing this blog and then putting it onto Github is:

    middleman article "Github collaboration"
    middleman deploy

What has happened is that locally I have created a new blog file, and then when I am done writing middleman deploy pushes that local code onto the Github servers and into my repo, and tada, the website gets updated. And for code, my process is similar: 1. make write code 2. add to Git repo 3. commit code 4. push code to Github servers

Branching and Pull requests

But for collaboration, the true strength of Git shines through. The general idea is that you have a master branch of code, where everything is perfect and runs properly, and then everybody else can create various other branches. The idea is to keep changes to the master branch small and manageable, so that if things do break, you can revert.

To start off from the master branch, you run

    git checkout -b "adding-maps-feature"

which will make a new branch called adding-maps-feature and then place you within that branch. Then here you can add whatever code you want to implement that new feature. Once you are done, you run

    git add <whatever files you changed/added for the feature>
    git commit -m 'adding maps'
    git push --set-upstream origin adding-maps-feature

Those commands will add the changes to the branch with a commit message, and then git push will push the changes to Github. Once you are all done this, you can open a pull request with that branch on Github. A pull request will allow your collaborators to review the changes in the code you submitted, and then if they deem that everything is ok, that branch can be merged into the master branch. The pull request also allows for collaborators to make comments and suggestions on the changes.

Once the merge is complete, you are free to delete that branch and then work on a different one. But one thing to remember is to change back to the master branch within your local system with:

    git checkout master
    git pull

This will pull all the changes from the master branch on Github back to your local system so you can now work on a new branch/feature.

Multiple branches

It is very common for multiple branches, and multiple pull requests to exist at one time in a project. So to manage a constantly changing codebase, it is good to pull and merge local branches before pushing. To do this within the current branch, run:

    git checkout master
    git pull
    git checkout - 
    git merge master

The git checkout - command returns you to your previous branch, and now it will contain the most recent master code. Then when your branch is merged into master, there won’t be any conflicts.

Those would be the most used commands in my project, although there are other commands that are useful for when conflicts exist, but that is a bit more advanced.