Github: Merge `master` branch into `feature` branch after submiting pull request-CodePudding

I am not sure if it's even feasible. I have tried few things like rebasing/merge but whatever i have tried always comes into the PR diff.

Here is what i have and waht i want,

I have a master (default) branch, then i created a feature branch to make changes and raised a PR against it.

Now more changes have been merged into Master and I need to consume those changes to fix the review comments (mainly some utilities usage and libs). So, essentially i tried rebasing/merge both separately to see how it goes and I always end up with additional commits as changes in my PR diff and not just my changes.

Is there any way to achieve this in github? other than just creating a new feature branch and creating new PR and abandoning old one.

EDIT:

Here is what i have tried,

1. Using Rebase
> git checkout master
> git checkout -b feature
> // make changes & commit on feature
> git push origin feature
> git checkout master
> // made some changes & commit on master
> git push origin master

// now rebase
> git checkout feature
> git rebase master
> git push origin feature // fails as it complains HEAD being different from remote feature branch due to earlier rebase
> git pull --rebase
> git push origin feature


This set-up is adding master changes in the PR as diff and commit-id is changed in feature branch as well (expected due to rebase).

whereas same set of steps except for rebase, if i do merge then, it doesn't show in PR diff.

Finally after going over few more posts, here is what works and doesn't result master changes to pop-up in PR (w/ rebase option)

> git checkout master
> git checkout feature
> //make change & commit
> git push origin feature
> git checkout master
// make change & commit
> git push origin master
> git checkout feature
> git rebase origin/master // you can do just master to rebase against local
> git push -f origin feature // this is important otherwise you will see error and it will ask to do `git pull --rebase origin feature` which will cause master changes to appear in the diff. I feel like github has issues...and it's should do diff based on content rather than commits. but any ways

CodePudding user response：

The reason this happened is because you rebased your new (correct) version of your feature branch on top of the old (out of date) version of it. This rewrote not only your commit, but also the new commits you had from master which weren't yet on your old copy of your feature branch.

The solution, which you've already discovered from the comments and your updated question, can be summarized as:

When you use a rebase workflow, you need to force push your personal feature branches afterwards.

(Side note: you should rarely, if ever, force push shared branches such as master.)

The series of commands you used which enabled you to skip the force push:

git pull --rebase
git push origin feature

meant that you rebased (replayed) all of your commits (which included new commits on master too) onto the old version of your branch, and then pushed that out.

Note that in general, I rarely ever pull in favor of explicit fetching. So to update your feature branch with the latest master, you can do this as often as you like (but perhaps at least once per day):

git fetch
git rebase origin/master feature

# If you want to update a PR, or even just backup your commits in case your machine dies
git push --force-with-lease

Note the rebase command above will work even if you don't currently have feature checked out. If you do already have it checked out, you can leave off the last argument of the branch name.

CodePudding user response：

Isn't this just rebasing on (remote) develop? You can totally do that while having a PR open. To do so, checkout your feature branch

git checkout branch

then fetch the new changes in remote code

git fetch upstream

and implement them

git rebase upstream/master

git rebase upstream/develop

depending on where the changes in the remote repo where merged.

BTW, many people prefer merge the remote changes in their own master or develop, and then rebase their feature on their own local develop. This is because many devs prefer to have a local clean copy to keep things organized.

Let me know if I'm missing something.