1

At work we develop on top of a feature branch model where all integrations end up in the master branch eventually. We branch from master and merge to master. This results in a very complex history graph and we are looking at ways to simplify our development workflow.

One way of doing so it to rebase instead of merge. However, we have an internal GitLab instance installed where overwrite permissions are disabled (and they are not going to be enabled for our project only). As such rebase is out of the question.

I honestly don't see any way around this. But I'm no Git expert and I might be missing something.

Any suggestions?

rfgamaral
  • 16,546
  • 57
  • 163
  • 275

1 Answers1

2

EDIT - my first answer was by no means the best way, although it would work. I've left it below in case it interests anyone. A better answer is the following:

You can use git cherry-pick with a range of commits to apply the featurebranch commits one at a time to master. Any commit range spec will do, but in your case the easiest is probably (with master checked out):

git cherry-pick featurebranch ^master

which means 'cherry-pick everything on featurebranch that isn't on master'.

Old, poor solution

You could use git format-patch and git am.

While on branch featurebranch, running git format-patch master will generate a patch file for each commit on featurebranch that's not on master. You can then switch to master and apply the patches with git am.

(In the more straightforward case where featurebranch hasn't been shared with anyone, then rather than rebasing master against featurebranch, you can instead rebase featurebranch against master, which will make featurebranch a copy of master with extra commits on top, and then rebase master against featurebranch, which will make git fast-forward master.)

Tarrenam
  • 382
  • 2
  • 11