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

Git - Removing a file from a commit

Once again, another git magic that might be of help to some of you. This research came up when I accidentally added a couple of unwanted files and wanted to remove them from a commit. We all know that to update an existing commit, we shall follow this git magic to amend commits . However, how do we drop changes to a particular file in a commit? While that is easy, it is also tricky. This blog post covers scenarios and respective commands that help you understand what should be done. /**  *  @disclaimer  * Please read this post fully before executing any command. My scenario might not be the same as yours. */ There are two scenarios to be handled here, Remove a newly added file Remove changes to an existing file Let's look at them separately, Remove a newly added file This is the scenario where an unwanted file added to the commit. This file might be some config.json that got generated while doing a research on a new testing tool or a bundling tool. Such scenarios are easier. 1. Re

Git worktree - guide to flexible folder structure

As always, let's start with a story why I have written this one down. I have been using git for almost 5 years now and in one of my work places I had to work on the same project but different features in parallel.  Switching between branches back and forth was a costly operation given that I didn't discover commit amend until recently. Even though I'd have discovered commit amend, I'd still have did this. Still did what? I can sense that question deep from your throats. So, whenever I am in a situation to work on multiple features or a feature and a bug fix, I'd have two clones of my repo each with different branches, Whenever a feature is merged or the fixes are merged, I'll delete the clone in my machine and branch in my origin (Gitlab / Github etc.,) Recently when I started writing these git articles, my manager suggested me to learn about Git Worktree and it'll be useful. And when I got free and good understanding of git commit, rebase and stuff, I decid

Confluence: 5 quick things that you need

As part of my work experiments, this week I would like to write down the things that one needs to know in confluence that can up-skill their documentation works. I will cover the following 5 things, How to Anchor link a title? How to Anchor link to a section? How to create a dashing dashboard? Panel - Confluence Macro Layouts - Confluence Tools Content by Label - Confluence Macro 1. How to Anchor link a title? This is the most required thing. Most useful when one has to refer to a section internally on the same confluence page. Let's consider you have a page with three different sections and titles as shown below, In this, if you want to add an internal anchor from a text in paragraph 3 to a title in paragraph 1, you can add it as follows, Choose the word that needs Anchor Click on the link icon from the Toolbar above In the link box, enter #Page Title 1 Click Insert That is it. Your anchor from the selected text to Page Title 1 is ready. This can be tested out in the preview itsel