4 ms·
I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so m
by mmgutz 11y ago
I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so my team knows they're dealing with release code.
- Touche 11y agoWhy not just use tags?
- simias 11y agoYou might want to cherry pick some commits from the dev branch into a stable branch from time to time (security fixes, things like that).
- Touche 11y agoSure, you can do that with tags. Branch off from your tag, cherry-pick your commits, push and if tests pass create a new tag.
- ryanbrunner 11y agoWe use a master / development branch strategy. For us, the main problem with having one branch and tagging releases is that it's relatively common for work to continue on the development branch while the release branch is still being tested. For us, there's a 2 day period where we're testing out the upcoming release. Developers will be fixing bugs on this release branch, and also commiting new code for the subsequent release. If we had one branch with tags, developers would need to keep all their new code on feature branches until a release is completed, and the likelihood of accidentally releasing an untested feature gets a lot higher (one advantage of having two branches is that you can treat your production branch with a lot more care)
- magicmu 11y agoI do something very similar; use master for dev builds that can be shared (since it's the default branch) and something like 'deploy' or 'deployprod' (which on second thought is a bit redundant) for release. Then, using a CI tool, you can have master go to a staging environment and deployprod go to production.
- pc86 11y agoWhat would be an example where master differs from production?
- jes5199 11y agoall code is release code