1

I created feature branch from main develop branch called my-feature there is also another feature branch created by another developer another-feature.

We both are doing changes in different files

Another developer already create PR but, not merged yet to develop. But, I need his changes to my branch so, I did git merge another-feature to my my-feature branch and create Pull request.

But, main problem is now, I can see changes of another-feature branch to my Pull request of my-feature. So, how can I rebase that? I don't want to show changes from another branch.

I checked another post but, some of them are less understandable to me.

Any help would greatly appreciated.

Edit:

git log Display like following. (Target branch is develop)

commit: f0fdfddsdsde
Author: Me (As my last commit before creating PR)
Date: blah blah

commit message....


commit: a4dsdsdssdds
Author: Another developer (whose changes I merged)
Date: blah blah

commit message....

rest of another commits ....

git log ––all ––decorate ––oneline ––graph

f0acaed (HEAD -> feature/my-feature, origin/my-feature) commit message..
a4f4dab (origin/another-feature, feature/another-feature) commit message..
* db30503 (origin/HEAD, origin/develop, develop) merge pull request from another branch

blah blah blah
ketan
  • 19,129
  • 42
  • 60
  • 98
  • May you share a simplified commit tree? – evolutionxbox Dec 17 '20 at 11:33
  • is develop branch your PR target branch? If yes, seems no way to not see the changes unless `another-feature` is merged to `develop` – deerawan Dec 17 '20 at 11:33
  • @ketan cheers. May you use `git log –all –decorate –oneline –graph` instead? The output from that may be more useful. – evolutionxbox Dec 17 '20 at 11:46
  • @ketan fab. So it looks like you're only dealing with three commits. Is that the case? – evolutionxbox Dec 17 '20 at 11:54
  • Yes, actually two mine last commit (only one) and merged from `another-branch` – ketan Dec 17 '20 at 11:56
  • 1
    As useful background here, it's worth keeping in mind that git **never** thinks of a commit as "belonging to" any particular branch. So when you ask for a comparison between "my-feature" and "develop", it's just looking at the **commits** that are reachable from the tip of "my-feature" and not from the tip of "develop". Regardless of how you merge or rebase, the commits from "another-feature" are going to show up in that comparison until they're merged into develop. – IMSoP Dec 17 '20 at 12:04

1 Answers1

2

The changes will be visible on your PR unless the another-feature is merged.
If you just want to not see those changes in your PR while reviewing, just change the base branch during the review (if the version control system you're using, allows that).

Another solution (that I prefer) is to rebase your branch with another-feature instead of merging them.
In this case you'll have less headache when the another feature is merged, and also while reviewing you'll be able to just review the commits that you've pushed (most of the systems allow you to select the set of commits while reviewing).

Update: (for the second approach mentioned above)
In order to jump to the original state of my-feature, you'l need to use reflog.
Here's how to do that.

  1. Make sure there is no pending changes by typing git status
  2. Type git reflog and you'll see something like this: enter image description here There you can see the history of the head references. Just find the commit that was before the merge (in the picture it's the one with HEAD@{1} with commit hash e919ec6).
  3. Now just checkout to that commit with the command: git checkout HASH_HERE (e.g. git checkout e919ec6)
  4. Now just create a branch from that commit (for convenience) checkout -b my-feature.ORIGINAL

Now the my-feature.ORIGINAL contains your branch state before merging and you're on that branch.
In order to do rebase instead of merge, follow these steps:

  1. Do a backup of your branch (again just for convenience) git branch my-feature.BKP
  2. Rebase the branch with the another-feature git rebase another-feature
  3. Rename your old bad branch (for convenience) git rename my-feature my-feature.BAD
  4. Change your current branch name from my-feature.ORIGINAL to my-feature (to match the remote branch name) git rename my-feature.ORIGINAL my-feature
  5. Now you can force push your branch to your remote branch and the PR will be updated.
Just Shadow
  • 10,860
  • 6
  • 57
  • 75
  • As, I already merged and created PR. How, can I do this? Another solution (that I prefer) is to rebase your branch with another-feature instead of merging them. – ketan Dec 17 '20 at 11:39
  • If you have a backup of your original branch of `my-feature` then checkout to that branch and use this command `git rebase another-feature` instead of `git merge`. P.S. If you don't have a backup, let me know and I'll provide more details on how to find that. – Just Shadow Dec 17 '20 at 11:41
  • Backup you mean I have create new PR and remove close old one? Meanwhile I edited my question to display `git log` – ketan Dec 17 '20 at 11:47
  • I meant the copy of the original branch `my-feature` (with something like `git branch my-feature.BKP`) before merging it with the other feature. But from the question I guess you haven't backed up it :) – Just Shadow Dec 17 '20 at 11:50
  • No not yet took backup. But, it very small change I can do again – ketan Dec 17 '20 at 11:54
  • @ketan Okay, I'll update the answer to include that part as well... – Just Shadow Dec 17 '20 at 11:59
  • @IMSoP that's exactly what I'm going to do :) – Just Shadow Dec 17 '20 at 11:59
  • @JustShadow Yeah, sorry, misread your comment. Carry on. :) – IMSoP Dec 17 '20 at 11:59
  • 1
    @ketan, I've updated the answer, please check. – Just Shadow Dec 17 '20 at 12:10