We are working on a major revision to our website. All of the work on the revised site is being done in a git branch (call it 2.0), which branched off from master some time ago. Along the way, some changes, both minor and significant, have been made to master, and we'd like to merge those change in to 2.0.
However, doing it as one large merge seems unwieldy--while some of the changes will merge nicely, some of them involve code that no longer exists on 2.0, and will essentially require reimplementing new features on 2.0. As long as there are bunch of unresolved conflicts after the merge, fixing those features might be quite difficult. We have considered using cherry-pick to bring only those changes from master that will merge nicely, while manually re-implementing the major changes, but I'm that will cause trouble if we ever want to merge all of the changes in 2.0 back to master.
Ideally, I could do piecewise merges from master to 2.0--merge a group of minor commits up to a particular commit, then merge a single major commit and manually re-implement a particular new feature, then another series, in such a way that at the end, master is fully merged into 2.0. Is this a good approach for this situation? If so, how do I merge partway into master, rather than all the way up to the most recent master commit? Or is there some other, better approach I should be taking?