Revert Git branch back to master to re-merge topic branches

Question

The Setup

We use the master branch for our live environment. That is, everything that's on master is fit to be deployed to the live environment.

Similarly, we use a staging branch that our staging environment runs on.

Any changes are developed on topic branches. These will be merged into staging for QA and once they are cleared for deployment, the topic branch is merged into master and discarded.

Master and the topic branches live on Github, staging only exists locally and in a repository to build the staging environment from.

The Problem

Sometimes the topic branches mount up. They've been merged into staging but for whatever reasons (time constraints on customer side, external dependencies, etc) they are not cleared to go live. Usually this isn't a problem and they just remain in staging for a while longer.

But now I have several branches that are probably not going to go live for several months and they are starting to cause merge conflicts when new topic branches arrive in staging.

So what I'd like to do is cleaning the slate: Essentially revert the staging branch back to the latest commit on master, then re-apply all topic branches that are likely to get done in the near future. After that I want to be able to push the reverted staging branch to the remote repo our staging environment uses for deployment without having to do extra clean-up in said repository.

How do I do this? Thank you very much.

Answer 1

Not sure if you're asking for procedural advice or the git commands to do this. If I got you right, this might help:

revert the staging branch back to the latest commit on master

$ git checkout staging
$ git reset --hard master

re-apply all topic branches that are likely to get done in the near future

$ git checkout topic1
$ git rebase -i staging
$ git checkout topic2
$ git rebase -i staging
...

Note: Rebasing is an often-discussed issue, since it "changes the past". It is advisable to get all developers in sync (ie make sure their commits do not refer to any that you are going to eliminate a posteriori) and maybe back up your repository.

rebase -i starts the interactive mode. You will then be able to apply the topic1 changes to the staging head as if you had started there. There's good documentation here and here .