Git - How to remove work from origin, but merge back in later from another branch?

Question

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:

1. Create a new branch off of master called "NewFeatures"
2. Go back to master, delete all offending code (months of commits, hundreds) by hand
3. 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"?

UPDATE 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)

UPDATE 2 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).

Thanks, Brian

Answer 1

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 new-feature.

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.