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
Post a Comment