CODEWITHSUNDEEP
git
marmeladze
marmeladze

Reputation: 6572

Changing master history

Is it possible to change master branch history as below?

branch-a commits [the rightmost is the last]
    a-b-c
master
    a-b-d-e-f-g

Modifying master to, 

a-b-c

while keeping changes on current master (maybe in another branch). Or in other words, I want that branch-a become master, and changes on master to be removed to another feature branch.

Background: In our server, we periodically pull and deploy master branch from our git server. Current version of master running is a bit outdated. The last commit pushed on 9th September. After that, we've merged some feature branches there and a few days ago specs changed. So, commits after that date (9th September) should be ignored for a while, and we need to merge another branch on top of the last deployed one. Cherry-picking didn't work, or I've done something wrong.

On branch master, I've cherry-picked like

git cherry-pick -x <last-commit-to-branch-a> # commit b

Now git log on master seems like that

a-c

And b is absent.

Upvotes: 1

Views: 971

Answers (1)

Romain Valeri
Romain Valeri

Reputation: 22047

Since you can't change history (added in comments to the question above), just revert what you don't want, then add what's missing.

git checkout master
git branch backup-master
git revert g f e d

At this point your history looks like this

branch-a commits [the rightmost is the last]
    a-b-c
backup-master
    a-b-d-e-f-g
master
    a-b-d-e-f-g-g'-f'-e'-d'

where each commit with a ' here contains the exact opposite changes its counterpart without the ' brought in the first place. Note that we reverted them in reverse order to avoid unnecessary conflicts.

Finally we need to bring back (not really bring it but copy it here) the missing commit c (here I called it C to differentiate between revert commits and the cherry-picked one)

git cherry-pick c

branch-a commits [the rightmost is the last]
    a-b-c
backup-master
    a-b-d-e-f-g
master
    a-b-d-e-f-g-g'-f'-e'-d'-C

History is clearly different between the two but the files tree should be the same between your branches, without rewriting history, just adding more history.

Sure some will say it "looks" a bit messy but a git history is not meant to look pretty to your neighbours, it's (hopefully) a trustworthy witness of past steps. And all this is a very explicit series of steps for anyone to inspect and understand at a later point.

Upvotes: 1

Related Questions