3 ms·
What sort of repository and deployment structure are you using right now in which it works fine? I think that will influence the outcome a lot. I just was work
by contractor8 7y ago
What sort of repository and deployment structure are you using right now in which it works fine? I think that will influence the outcome a lot.
I just was working with a client that used something like git-flow, where develop was deployed to staging in order to test, master was always production, and the codebase is largely a monorepo. Then there were a couple other legacy repos, which also are using git-flow. It... "works", but it also is a needless source of pain. You need to PR to develop, then PR develop into master, and I'd inevitably get bitten with merge conflicts in the process. All that for what gain? I saw no upside to it. Maybe if you have steady release cycles, but git-flow never seemed to fit the whole disposable branches, master is good to deploy dozens of times per day sort of workflow I've gotten used to.
- tootie 7y agoJust pull develop into your feature branch daily. Merging develop to master is a one-lane highway so merges are only required if you did a production patch.
- gwright 7y agoContinuous deployment triggered by a merge into develop is basically a degenerate case of gitflow where there is an automated release associated with every merge into develop. So if you are doing full gitflow or if you are doing this degenerate case of gitflow you still shouldn't be getting merge conflicts when releasing develop (merging develop into master). This should basically be a fast-forward with perhaps a merge commit for record keeping. The only way to get conflicts in this case is if there is some other process that is changing master independent of the "releases" from develop. In gitflow those other changes are managed through the hotfix branching rules, which ensures that you resolve the conflict when you close the hotfix and back merge it into develop.