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:

  • git delete a commit from pull request
  • How can I test a pull request before merging it?
  • How to replace corrupt Git objects with new ones created from my files, which are fine
  • Show the original branch for a commit
  • Where can I find a reference for all the syntax that's supported with git commit hashes?
  • git: How do I add a custom merge strategy?
    1. Create a new branch off of master called “NewFeatures”
    2. Go back to master, delete all offending code (months of commits, hundreds) by
    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”?

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


  • Problem with git hook for updating site
  • git on Windows: fatal: protocol error: bad line character: @-
  • When multiple clients push to same remote repository, how does git deal with concurrency issues?
  • How to deal with IntelliJ IDEA project files under Git source control constantly changing?
  • How do I move a local git repo from parent folder to subfolder?
  • GIT author authentication
  • 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 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.

    Git Baby is a git and github fan, let's start git clone.