0

I am responsible for a customer-facing service of my company, and by the end of march we'll rebrand our company with a "big bang", so all of our products are released on that particular day with new features and the new CI.

I would estimate the work that I have to do to 1-2 days, but to have enough time to confer to our designer I might start at the beginning of March. Deployments are scheduled right from the head of the master branch so I am wondering how to do the rebranding. If I do it on master, I have to deploy the service from a release-branch where I cherry-pick non-rebranding commits for half a month. That would mean that I have to disable logins to the deployment-pipeline for other developers and especially managers as it would be too easy to deploy the new CI by accident.

From that point of view it might look like a feature branch is the way to go, but isn't that ugly? Whats the proper way?

jonrsharpe
  • 99,167
  • 19
  • 183
  • 334
alsdkjasdlkja
  • 1,079
  • 1
  • 12
  • 27

1 Answers1

1

I don't see anything particularly wrong with having a feature branch for this. You make all your rebranding changes on your feature branch, and just keep rebasing it on master.

Hopefully, your repository has some sort of formal access control, of some kind. It's really not a good idea to allow anyone to merge their branches with master, any time they feel like it. It should be, at least a semi-formal process.

And if it's not, given the stated importance of this, then a semi-formal process should be put in place, at least temporarily. Make a policy so that, after date X, all merges to master stop. On that date, you make a final rebase on master, do whatever final testing, and due diligence, you need to do. Then, you merge to master, and this is what goes out the door.

Then, afterwards, it's back to business as usual.

Sam Varshavchik
  • 84,126
  • 5
  • 57
  • 106