Menu
I have a feature branch test. I made my changes and committed my changes to that branch. Meanwhile my master tip was changed (Assume it had more commits from other developers).
Before pushing my changes to my remote branch, I did a git rebase and then pushed my changes and created a Pull Request.
For my pull request, there were a few comments which I need to fix them.
After fixing, I saw that my master branch was updated. (Assume some more commits from other developers).
At any point, the reason to merge master onto test branch is that : there might be scenarios where the changes in master needs to be integrated and test the application with this feature branch
In this situation, I have 2 questions.
How can I merge/rebase the new changes of master onto my test branch without having a merge commit in my test branch? This way I will have both my previous commits which are a part of Pull Request and the new commit which is a Pull Request comment fixes.
How can I merge/rebase master onto test and add the new commit to my existing previous commit so that I always will have a single commit in my PR?
279
The Golden Rule of Rebasing The golden rule of git rebase is to never use it on public branches. For example, think about what would happen if you rebased main onto your feature branch: The rebase moves all of the commits in main onto the tip of feature . The problem is that this only happened in your repository.
It is best practice to always rebase your local commits when you pull before pushing them. As nobody knows your commits yet, nobody will be confused when they are rebased but the additional commit of a merge would be unnecessarily confusing.
Rebasing can be dangerous! Rewriting history of shared branches is prone to team work breakage. This can be mitigated by doing the rebase/squash on a copy of the feature branch, but rebase carries the implication that competence and carefulness must be employed.
First of all, determine if you actually need the new changes from master to be integrated into your feature branch. It may be that you can ignore the new changes from master. If they don't conflict with your changes in test, then this is the easiest thing to do, and the maintainer will be able to merge your PR anyway.
You can easily see if this is the case by checking the GitHub PR page. If you get an "unable to automatically merge" message, you'll have to use one of the following solutions.
The standard way to include upstream changes without merging is to just rebase again:
git checkout test
git rebase master
Since this rewrites history, you will need to force-push:
git push --force-with-lease
Your PR will be updated with all of your commits, and will now include the new commits on master in its history.
Obligatory warning: Since a rebase rewrites history, this can be dangerous / disruptive for anyone else working on this branch. Be sure you clearly communicate what you have done with anyone you are collaborating with.
If you don't want to rebase, your other options are:
master into test, but you've stated you don't want to do this.git cherry-pick any new commits on master. This has the downside of duplicating those commits on your branch.master into test: git merge --squash master. This is similar in effect to cherry-pick, but creates only one commit.
170
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
