Re:The Problem with Git Flow
by bob1029 on Wednesday June 24, 2020 @10:20AM
(#23628152)
This is precisely what we do. In our model:
> Each issue in GitHub is 1:1 with a PR that resolves it.
> All normal work is branched directly off latest master.
> Every branch is rebased against master prior to merging.
> Feature flags are heavily used to gate the activation of functionality which is not applicable, not ready, or otherwise in need of being configured per environment+client.
> Checkbuilds complete with success before we merge to master. Nothing is allowed to merge which could impact production without a feature flag or other gatekeeping mechanism in place. We have a labeling system to track which issue+client pair needs a feature flag configured in a certain way so this can be managed at deployment time.
> Hotfixes are managed by branching off the commit deployed to the client+environment of concern. We have a system (in house developed) that tracks all of the current client+environment+hash tuples so it is very easy to know where to stick the shovel every time.
> We effectively consider the commit hash to be the version of our software. Our releases are extremely granular due to the feature set we support for our customers, so commit hash is the best way to manage this. That said, it is not unusual for multiple client+environment pairs to share a common commit hash depending on our release timing (this is purely asynchronous and managed by our project group).
That's about it. There is only 1 permanent master branch. No work branch ever sits longer than ~2 weeks in our development model. We merge code ASAP so that we can iterate on the results.
For reference, we merge to master ~10-30 times per day. I have some plans in the pipeline for implementing a technique that would allow for pushing hundreds or thousands of commits per day if we ever got to that point.
> Each issue in GitHub is 1:1 with a PR that resolves it.
> All normal work is branched directly off latest master.
> Every branch is rebased against master prior to merging.
> Feature flags are heavily used to gate the activation of functionality which is not applicable, not ready, or otherwise in need of being configured per environment+client.
> Checkbuilds complete with success before we merge to master. Nothing is allowed to merge which could impact production without a feature flag or other gatekeeping mechanism in place. We have a labeling system to track which issue+client pair needs a feature flag configured in a certain way so this can be managed at deployment time.
> Hotfixes are managed by branching off the commit deployed to the client+environment of concern. We have a system (in house developed) that tracks all of the current client+environment+hash tuples so it is very easy to know where to stick the shovel every time.
> We effectively consider the commit hash to be the version of our software. Our releases are extremely granular due to the feature set we support for our customers, so commit hash is the best way to manage this. That said, it is not unusual for multiple client+environment pairs to share a common commit hash depending on our release timing (this is purely asynchronous and managed by our project group).
That's about it. There is only 1 permanent master branch. No work branch ever sits longer than ~2 weeks in our development model. We merge code ASAP so that we can iterate on the results.
For reference, we merge to master ~10-30 times per day. I have some plans in the pipeline for implementing a technique that would allow for pushing hundreds or thousands of commits per day if we ever got to that point.