The Opensource Workflow…
By: Aakash Mallik
Tags: Starter, Git, Github, Coding, Open Source

Firstly, there are three lanes in this diagram, one for your local machine, one for your buddy’s machine and one that represents the Github repo. Github repo is the ultimate source of truth; which basically means, whatever your Github repo says is true for all clones of your code on any machine in the universe. If it says it has 10 commits and your machine says 15, then your machine is lying and it is your responsibility to keep the Github repo updated with the truth that you believe is correct.

Let's hear a story and by the end of it, you will know what pull is for. So, let’s say you plan to create some new project to make a name for yourself, so your lane starts with the first circle, which represents a commit. “Initial commit”, and you push that code into ‘origin’, hence the arrow towards the Github lane. You made some changes to the code, added, committed and pushed again, hence the second arrow. Everything till now is in sync. Github repo is still representing the truth. Now, your mum asked you to visit your grandma, so you asked your friend to help you finish the code. So, you make him a collaborator and he clone( hence the arrow towards his machine from Github lane ) the project and now his machine will be in sync with the Github repo. If he runs a git log he will see all the commits you had done so far. Now he starts adding code into your project, while you are away. He made two commits locally and pushed them to Github repo, so far so good. The forth commit was indeed from your buddy and hence the Github repo is still representing the truth. Now you get back home and start working on your code again unaware of the changes you buddy has made. You made some changes, added and committed. According to your local repo, you have made the 3rd commit, but according to your Github repo, your buddy did the 3rd commit. As soon as you try to push your code, you will be denied by Github as your version of the story does not match with the truth.

The error will look something like this…

So like I said, you are responsible for making sure Github repo represents the truth, so you pull from the Github repo. The pull command is basically fetched + merge. It pulled whatever there is in the Github repo to your local machine and merges it with your commit.

You can break it down like this:

git pull

This is equivalent to this ( long version for power users )

git fetch

git merge

Also note that by default git applies an option with the git pull command, ie:

git pull --merge //merge option added by default

This option even though applied by default should be kept in mind; you will see why, in the later section of the article.

If there are obvious ways to merge the changes, git will do an auto-merge for you. But if the changes are clashing ( like the same file has two types of code in the same place ) then it will leave it up to you to fix these conflicts. So you can quickly do a git status and find out the files that need a conflict fix. Once done, you can now do another add and then a commit saying ‘merge conflict resolved’, and finally push this code to the Github repo. This version of code will again represent the truth as we wanted it to be.