|
At work, we use master as you describe, and follow gitflow for feature and bugfix branches. For release-to-customer products, we have a release branch, eg: release/1.2.3, and as part of our CI build, that number is automatically picked up and used in the product itself as the version number. For our cloud/SaaS/single-instance stuff, we have a 'staging' and 'production' branch, and typically have 3 environments (dev, staging/test, and production) all of which are continuously deployed. We typically just do fast-forward merges to bring staging and production up-to-date with master. In both cases, when a developer is working on a new feature or fix, we want them to base off master.. which is the latest fully-integrated build, though it hasn't passed QA. If they worked off a production/release branch, we'd continuously have to deal with conflicts as by definition they're basing their changes on out-of-date code. A 'develop' branch could work for some of our small stuff, where typically production/release isn't far off from master, but for our main stuff we do a 2-3 month release cycle, so master usually has quite a lot of changes that aren't in release. |