Git – How to remove work from origin, but merge back in later from another branch?
I have the master branch that has a bunch of features in it that will not be released. I was asked to remove those features from master and create a new branch that that has them in it so we can merge back to master later.
The steps I took were:
- Create a new branch off of master called “NewFeatures”
- Go back to master, delete all offending code (months of commits, hundreds) by
- Commit deletes to master
The expectation was that I would keep working on “NewFeatures” and periodically merge master into “NewFeatures” so that when I merge back in, it is seamless.
Now, when I want to keep “NewFeatures” up to date with master, master wants to delete all the code in NewFeatures.
My question is, what would have been the proper way to accomplish with Git “deleting a bunch of features from master and placing them into another branch for later merging”?
Thanks for the responses. I’ve made a diagram that hopefully explains things. The biggest problem is that at the first merge from main to feature (the first xy on the second row), the main branch wants to erase everything that was y because I removed all y’s.
- y - x - y - (remove y's) - x - x - (release x)-x - x - xy - xy - xy - (release xy)
\ \ \ /
y - y - y - y - y - xy - y - y - xy - (done)
I ended up moving the branch to just after I deleted NewFeature from main (but I had copied out the removed files) and then copied the removed files back in. This way, main can merge into NewFeature without killing things, and NewFeature can merge back into main without problems. I lose some commit log tracking, but it seemed better than cherry-picking files for the next three days.
The below help seemed to be the correct way to do it, but this way seems to be good enough for me (and the discussion led me to the way I finally did it, so thanks guys).
2 Solutions collect form web for “Git – How to remove work from origin, but merge back in later from another branch?”
The question you are essentially asking is how to get commits from another branch and bring them into your new feature branch, without wiping out your changes. Assuming these commits aren’t touching the same files as the ones you made changes to, the solution has been provided already in another question.
This is the gist of the other person’s answer:
# wss-starting-point is the SHA1/branch immediately before the first commit to rebase git branch wss-to-rebase wss git rebase --onto v2.1 wss-starting-point wss-to-rebase git checkout v2.1 git merge wss-to-rebase
Use his original answer as a reference. I hope this helps!
I believe what you would have to do is create two branches from your existing
master branch. One would include just commits that should have gone in to
master and the other would include just commits that contain work for
I’ve made a quick diagram to show what I mean. Currently you have something like this (latest commit at the top):
* - Master work | * - New feature work | * - Master work | * - New feature work | * - Master work | * - New feature work | * - Common commit
You need to get to here:
* - Master work | | * - New feature work | | * | - Master work | | | * - New feature work | | * | - Master work | | | * - New feature work | / |/ * - Common commit
It’s important that no commits are duplicated across your two branches as this could cause a problem when you merge later.
You can use
git rebase to achieve this however if like you say you have hundreds of commits, you’re not in for a good time as you’ll have to review each commit individually.