Quote:
Originally Posted by RustyBrooks
What goofy said, but also, don't do this.
Branch off main for your development branch, then merge dev branch back into main to release. Rinse and repeat.
Or, just keep a permanent dev branch and merge it into main and release from there.
I know this isn't helpful but personally I've embraced the "release early and often" philosophy and I've encouraged employers to also. We push to our main branch regularly. It's continuously deployed to our staging environment. At any point we can deploy main to production, in practice we do it about once a week. (At my last job, you deployed a fix or feature as soon as it was done, so I might deploy 3 times a day)
Why is this so bad? We actually use to follow the branching model you proposed, but around a year ago, a bunch of people who make a lot more money than me decided to switch it to 'stair case' branch model.
We would like to release faster, but there are other bottlenecks that slow down the progress (test verification is the big one, deployment to all our online prod environment is also not very fast, plus we need to roll out our releases slowly to limit risk - update a few customers on day 1, let is soak, update a few more, let it soak, update North America, let is soak, update rest of world - this way we can abort or fix the update if there is an issue before too many customers are impacted).
P.S. No one addressed the actual question I asked
All these branch model requires merges between two branches. I am looking for a way to automate this process so branch A can be merged into branch B every time I run this automation. If there is a merge conflict, we would need dev manual review, but most cases, I expect to be able to merge without conflict.
I think I can do this with a powershell script (perform the merge). Once I have that working, I can figure out how to automatically run the powershell script on demand. I am thinking I can attach the script to a git 'commit' hook, and have it trigger every time a change is pushed.