Skip to main content

Github - How to obtain latest changes from upstream?

Published on
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 :-) 
Labels:

Comments

Post a Comment

Popular posts from this blog

WebRTC - What the heck?

Published on
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
2 comments
Read more

Git - How to drop a commit in history?

Published on
Back after a while with another git magic. We already have seen how to get rid of the top most commit in this article ->  Git magic - Make commits disappear First of all, it's one of the not so recommended way of doing it and more than that, it can only get rid of sequential commits from latest. I recently happened to get into a scenario where I had to drop a commit in the history by keeping the latest ones. As part of that exploration, presenting you this article. /**  *  @disclaimer  * Please read this post fully before executing any command. My scenario might not be same as yours. */ To my greatest surprise, I didn't know a git rebase could do this. Please continue to read to know how. The steps are simple, Count until the commit line you need to drop using git log Do an interactive rebase and you're done.  Let me explain step by step. 1. Look at the commit log & count commits This is the first step. First let's list the commits using the following command,  
Post a Comment
Read more

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

Published on
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
Post a Comment
Read more