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,

Pulling latest changes of upstream to your local repo
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,

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
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?

Do a git merge origin/master
When you have conflicts, please solve them
Stage the solved files for commit
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
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?

Do a git merge upstream/master
When you have conflicts, please solve them
Stage the solved files and then type git rebase --continue
Keep repeating step 2 & 3 as long as you don't see a success message
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

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...

npm-link | What NPM won't tell you!

Hello readers. So back with another easy yet unexplored feature of npm/yarn packages. We as frontend developers / SDK developers, have to deal with more than one repositories where we actually code contribute. Most SDK developers would know this already or they use the not-so-well documented 'npm link' command . /** * @disclaimer * Please read this post fully before executing any command. My scenario might not be the same as yours. * This article below uses a repo from my current workplace as an example which is open-source and does not violate the Cisco Confidentiality Policies */ To make this article easier to understand, some representations, Host - Package that needs another local package as part of its node modules. Let's assume the path to this package is ~/Documents/Repos/demo-app Adhoc - Local package that is added into another package as a dependency. Let's assume the path to this package is ~/Documents/Repos/semver-monorepo What is...

Building AI Apps - The basics you need to know

So you want to build an AI assistant? Maybe for customer support, maybe to search through documents, or maybe just to automate some boring stuff at work. You keep hearing words like "prompting", "RAG", "fine-tuning" thrown around in meetings. But what do they actually mean and which one do you need? Let me walk you through building a customer support AI assistant and show you how each of these concepts fits in. /** * @disclaimer * This is an educational post based on my learnings. * I'll share actual experiments in future posts. * Your use case might be different, so take what applies to you. */ What even is an LLM? Before we jump into the techniques, let's start with the basics. What is an LLM? Think of a Large Language Model (LLM) as someone who has read most of the internet but has zero memory of your conversation once it ends. Models like GPT-4, Claude, or Llama have been trained on massive amounts of text data. They know a lot...

Experiments at work

Search This Blog