Yes, it will. This includes merge commits, by the way, so if a different branch than the target branch of the pull request is merged in to the branch, then the merge commit and both of its parent chains of commits (from both branches) will become part of the PR.
You can simply remove that commit using option "d" or Removing a line that has your commit. In the latest git version there is no more option d. You need just remove lines with commits from rebase to delete them.
When you select the Squash and merge option on a pull request on GitHub.com, the pull request's commits are squashed into a single commit. Instead of seeing all of a contributor's individual commits from a topic branch, the commits are combined into one commit and merged into the default branch.
Here's a good workaround. Use the Edit
button when viewing the PR in GitHub to change the base branch to something other than master
. Then switch it back to master
and it will now correctly show only the changes from the most recent commits.
It looks like the Pull Request doesn't keep track of changes to the target branch (I contacted GitHub support, and received a response on 18 Nov 2014 stating this is by design).
However, you can get it to show you the updated changes by doing the following:
http://githuburl/org/repo/compare/targetbranch...currentbranch
Replace githuburl
, org
, repo
, targetbranch
, and currentbranch
as needed.
Or as hexsprite pointed out in his answer, you can also force it to update by clicking Edit on the PR and temporarily changing the base to a different branch and back again. This produces the warning:
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline, and old review comments may become outdated.
And will leave two log entries in the PR:
To sum up, GitHub does not rebase the commit history automatically in pull requests. The simplest solutions are:
Suppose that you want to merge into master
from feature-01
:
git fetch origin
git checkout feature-01
git rebase origin/master
git push --force
If you are working on a fork then you might need to replace origin
above with upstream
. See How do I update a GitHub forked repository? to learn more about tracking remote branches of the original repository.
Suppose that you want to merge intro master
from feature-01
:
git checkout feature-01
git checkout -b feature-01-rebased
git push -u origin feature-01-rebased
Now open a pull request for feature-01-rebased
and close the one for feature-01
.
For anyone else coming across this and confused by GitHub Pull Request behavior, the root cause is that a PR is a diff of the source branch tip against the common ancestor of the source branch and the target branch. It will therefore show all changes on the source branch up to the common ancestor and will not take into account any changes that may have occurred on the target branch.
More information available here: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/
Common ancestor based diffs seem dangerous. I wish GitHub had an option to make a more standard 3-way merge-based PR.
You need to add the following to your ~/.gitconfig
file:
[rebase]
autosquash = true
This will automatically achieve the same as what this answer shows.
I got this from here.
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