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: git push -u origin origin:master
  • Make git automatically remove trailing whitespace before committing
  • Can't git push to Azure anymore
  • git instaweb gives 403 Forbidden - No projects found
  • Is it safe to run your site within a Git repository on your production server?
  • Android Studio Error: Configuration with name 'default' not found
    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).


  • Git error: src refspec master does not match any
  • How can I make sure my commit has really happened?
  • How can I see what has changed in a file before committing to git?
  • Git change author name/email in a long ago commit in team repo
  • CVS and Git Deletion with Extreme Prejudice
  • Is there a way to fetch the names of refs from a remote in Git without fetching any objects associated with those refs?
  • 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.