Skip to main content

Github - How to obtain latest changes from upstream?

So, this one another thing that can mess up our repo if you don't do it the right way. 

Let's go over it step by step,
  1. Pulling latest changes of upstream to your local repo
  2. Merging (or) Rebasing

1. Pulling latest changes of upstream to your local repo.

So, what's the big deal? We could do git pull to get latest changes from origin to local. That's what I had been thinking until I actively started working with Github and the forked repositories. Git pull won't work here because pull could pull changes only from origin and not upstream.

Now, what is origin? what is upstream?

Origin - It's the repository of yours that you cloned from someone else's
Upstream - It's the repository from which you created your fork

Here are the steps,
  1. Set upstream URL.
    git remote add upstream {URL_OF_UPSTREAM}
    Please perform this only for the first time. After that it is set to your configuration just like username and email
  2. Now do, git fetch upstream.

2. Merging (or) Rebasing

Merging and rebasing does the same thing. Obtaining the latest changes from the parent repository. The only difference is that merge pulls all the commits as such and creates a new commit for merging and rebase creates new commits for the existing commits and puts them before your branch's HEAD. 

If you wish to read in depth about these -> Atlassian Bitbucket - Merging vs Rebasing

How to merge?

  1. Do a git merge origin/master
  2. When you have conflicts, please solve them
  3. Stage the solved files for commit
  4. Now, when you do git commit, it will open vim editor or your default text editor for commit messages with a default commit message for merge
  5. Once you save & push it, you are done
When this is done and you open your commit history (git log), there will be a separate commit that indicates the merge. 

How to rebase?

  1. Do a git merge upstream/master
  2. When you have conflicts, please solve them
  3. Stage the solved files and then type git rebase --continue
  4. Keep repeating step 2 & 3 as long as you don't see a success message
  5. Once you see a success message, push the changes. 
When you look at the history (git log), now the commits will be behind your HEAD instead of having a separate merge commit. One tip I would give here is that, whenever you rebase your feature (or) bug fix branch with upstream/master, definitely rebase your origin/master also with upstream/master. That way your master will always be in sync with upstream and you could create branches from it with latest changes always.

Being all that said, although rebase looks very neat, it has one big disadvantage. We cannot know who solved which conflict and that means, in a large team of developers, we cannot know the reason why some code exists the way it exists. 

Happy committing, merging / rebasing :-) 

Comments

Popular posts from this blog

WebRTC - What the heck?

Over the past few weeks, I happened to work on stuff that enabled me to understand what WebRTC is and how useful it is.  The full form? Web R eal- T ime C ommunication The history It's first release was by 2011. If you want to know more, well, please read the wikipedia . WebRTC  has been a boon to web developers who want to build streaming applications or video calling applications. As you move downward, you'll just may be understand how WebRTC works but nothing technicals.  The story Let's begin with a short story. Long long ago, so long ago, nobody knew how long ago, there lived two shop keeper farmers John & Finch. It was that old point in time when barter system was a thing and money wasn't invented.  These shopkeepers lived in different cities across a river and the cities were connected by a rock solid bridge. Like how the golden gate connects the San Francisco city and the Marin County. Finch is a very private person and takes hard time to trust people. John

TDD - How to go about it? - A quick start example

So, it's only recently I've been doing TDD. I have written unit tests before but those were all tests after writing the actual code. Confusing statement right? /**  * @disclaimer  * I'm just preaching what I practice and some parts of it could be wrong.  * Please feel free to leave comments if am wrong  * And I would be happy to stand corrected */ What is TDD? TDD, expanded as Test Driven Development could have this statement as one of the definitions. "TDD is nothing but the art of writing down the business use case one by one and write code based on it paralelly" It would feel like why do I need to write test for that? We could do the same with pen & paper and write codes. But then, you again circle back to write tests for the same. So why not do it this way?  Therefore, let's start with an example, Write a method that accepts two positive numbers as input and returns their sum Let's try and do a mock TDD for the above problem.  Case 1 - Function add

Git magic - Make commits disappear

So fellas, it's been a while since I wrote and I hope this article is of help to whoever reads this.  Let's start with bit of an introduction. Until my previous employment, there wasn't much guideline on how we write Github's commit message. One single feature could have n number of commits and it doesn't bother the repository.  Now, am part of  @webex 's  webex-js-sdk  team where committing guidelines are very strict and having a bit more deep knowledge of git commands has become essential. This made me explore git commands on regular basis. So I thought why keep them to myself while I can share them. It was my first ever PR and my changes were approved except for a few minor changes. I honestly didn't know how to make changes to existing commit and now, I had two choices.  Create a new branch from master and re-do the work manually Do some git magic and make the current branch work well.  If it were old times, I'd have gone with option 1. It's very