I have a merged and closed pull request. After that I deleted that branch. And all the commits of that branch now shows in the history of merged branch. Now There is an option to restore the branch in Git, but what I really want is to squash some commits of that PR so that it will not be shown in the commit history of branch where it is merged. Say initially PR has 5 commits and successfully merged and closed. Is there any way to squash some commits from the merged and closed PR?
-
https://stackoverflow.com/a/47048569/2303202 – max630 Nov 11 '17 at 17:13
-
My problem is that I can't change commit history directly on the branch where it is merged as that is a protected branch. Is there any way that from the closed pull request or restored branch the history can be re written? – Akshay Nov 11 '17 at 17:34
-
No, if a commit is a history of some branch it does not matter any more how did it came there. IT is nto possible to remove it. – max630 Nov 12 '17 at 19:24
2 Answers
You would use git rebase -i <hash of first commit before merge>
, you can then choose to squash the relevant commits. Beware that this is re-writing the actual commit history, so in case you share the repository with others then you will have different commits after doing this and this is potentially dangerous territory.

- 1,069
- 7
- 17
The only way would be to change the history in the master
branch (let's say your feature/branch
was merged on master
) :
$ git checkout master
$ git reset --hard <commit-before-merge>
$ git push -f origin master
Now you can rewrite your history :
$ git checkout feature/branch
# Hypothesis: 5 commits to squash together
$ git rebase -i HEAD~5
# Rewrite your history: reword, squash, etc...
At this point, maybe you should rebase feature/branch upon master
$ git rebase master
Once you're satisfied with your branch history, you can push to upstream :
$ git push -f origin feature/branch
Then create a new pull request on github and merge it
IMPORTANT NOTES
Everyone tracking branch master
will have to issue a git pull --rebase
to resync their history with upstream, which was rewritten:
$ git checkout master
$ git pull --rebase origin master
This will prevent any conflicts and/or merge commit taking upstream history for granted (accepting theirs
), issuing a fast-forward.
The same goes for branches still depending on master
, which will need to be rebased accordingly :
$ git checkout feature/branch-still-depending-from-master
$ git rebase master
Hope this helps ;)

- 367
- 2
- 9