I've been working on upgrading the front end framework for my rails application for many months, this has involved upgrading from Webpack 4 to Webpack 5, from AngularJS to Angular, .js files slowly becoming .ts, etc... So on my frontend-upgrade branch, lots and lots of commits.. lots of commits I'd consider garbage, as they were trial/error, various approaches to get things working.

Meanwhile master has continued to have backend development, and extremely minimal front end changes (to angularJS), but the two branches have dramatically diverged and now every time I try to rebase master on the front end upgrade branch, it's an absolute nightmare of merge conflicts, so I am just wondering if there are any recommended strategies that I can adopt for something like this?

Is there a way to do a rebase but one that ignores files in the directories app/javascripts/**/* and app/javascript/**/* so that I can just eliminate all the billions of conficts?

CodePudding user response：

• From master, create a new branch frontend-upgrade-ready.
• Then merge (with squash) from frontend-upgrade to frontend-upgrade-ready.

This should give you a fresh branch with the latest code from master and all of the changes from the last version of frontend-upgrade. The squash should help eliminate the commit-by-commit change conflicts and concentrate on the final changes.

You can then sort out any (hopefully minor) merge conflicts, then merge the ready branch to master once you've determined everything's good to go.

CodePudding user response：

Rebase is a great tool, but it isn't the best choice for every situation. When you have many commits that you want to keep, and rebasing yields many conflicts at each commit, it's almost always better (for both sanity and minimizing errors) to just do a back-merge for this one-off. I'd recommend just merging the latest master into frontend-upgrade, resolving the conflicts just one time, and calling it a day.

That being said, you did mention that you have "lots of commits I'd consider garbage". Even if you're going to do the back-merge, you may want to consider a little cleanup first with an interactive rebase. If you keep the same merge-base, don't change the order of any commits, and all you do is squash and re-write some commit messages, you will not have any conflicts at all (yet). This would be a one-time pass where you may be able to significantly reduce the total number of garbage commits. Note you still could even drop some commits or re-order some, but realize that as soon as you do that you open up the possibility of conflicts during this pass, so you'll have to handle those decisions on a case by case basis.

When you're done cleaning up your branch, now you would do the back-merge of master. Note it's possible that if you end up squashing the majority of the commits, that now you may be able to stomach the conflicts in a rebase onto master much better than before, so it may be worth another try before resorting to the merge instead.

Side Note: I only recommend using a "back-merge" of master into frontend-upgrade to resolve conflicts if the merge of frontend-upgrade into master will not be a fast-forward merge. If there's even a chance that a fast-forward merge could be possible, then I would (after cleaning up your branch), create a new temporary branch equal to master, and then merge frontend-upgrade into the temp branch. Then merge that temp branch into master. The reason for this is to make sure the first-parent history is preserved properly.