Saturday 15 March 2014

Maven deployments and git branching hell -


I am working on a page app and at some point we decided to do a rebranding (new skins and features) And we decided to re-architect our CSS, which has changed our HTML and JS. We should have merged the new branch of Master Lee at the earliest, but now for some marketing issues it has to be postponed for six months. If we merge the owner of the previous skin then it will be broken, which means that we can not deploy any improvement to live ... We are constantly merged with the master to keep the new branch up to date. , But they can not continue for six months ...

One idea is to convert the version of the branch from 1.xx to 2.xx and start making branches of release and branch reasons To tag because The need to deploy private Bitas etc. Which leaves us with Master in Master in 1.xx and with a branch in 2.xx

Other solutions may be to close the old topic for new CSS architecture, so that the master can For a long time to be able to merge back ...

Is there any other way to solve such a problem? Can you see other problems with the first approach?

Since the Jenkins option is turned away, it is viable to have my comment One answer is changed.

Create a Jenkins job that tries to merge with the master's new branch at every branch in the master's branch. Merge failure does not push the actual merge result anywhere, if the job fails, it indicates that a person should manually merge. In this way, you only have to merge (during the next six months) when there is really some conflict.


No comments:

Post a Comment