The other day there was a beautiful, albeit controversial article - Please, stop using GitFlow! (and a dozen more on the same topic after it).
Her main points were:
- GitFlow contradicts the thesis "branches should be short-lived."
This is important, because the less the branch lives, the less the chance of conflicts (not only git, but also logical) - GitFlow discourages rebases to save merge commits.
Yes, they can be saved with rebuys, but the Git Flow teams do not. - GitFlow denies the Contunious Delivery approach, believing that every Delivery act should be done by a release engineer, and in general you can see that it focuses only on a long release cycle.
- GitFlow is not friends with microservices on top of multi-repositories (however, there’s not much to be done here, it’s an idea that always ends badly)
But the problem with GitFlow is that it is not friends with mono-repositories either.
I myself stumbled upon this in the process of designing CI pipelines: GitFlow monstrously interferes when working on top of a single repository with several deliverables, for example, when the backend and frontend are separate in the same repository - because it allows you to commit to release branches, conflicts can occur with the reverse merge if more than one release branch exists at a time. Yes, even if it’s one, it’s all the same bad - in such conditions it is necessary to patch the release mechanisms of GitFlow in principle, so that at least somehow separate releases of entities work.
So what to do?
The author of the original article was helped by trunk-based development + feature flags - almost google green trunk, but not really. But this does not mean at all that you need this approach.
First, you need to understand the priorities.
What do your releases look like?
- ? , , , , ?
- ? , , WebSockets, . .
- ? LTS-, backport- ( , , 2016 ) ? canary beta-?
- Continuous Delivery?
?
- ( ) , ? design review merge/pull-request-, PR — 5 100 ?
- , ?
? , ?
, — . , flow , . Apache Kafka SQS — , , -, - , .
— . ( ) , , , , , , , .
, , — - . , JSON YAML, — , , .
, , , — , , — . , , . — , — .
flow
-, . , , ( ). , , , , , , , , v1 v2 .
, , . , , , CI, : .
— Continuous Delivery.
— , deliverables. - , , Google. — 10% - — -, .
. , :
CI-
deliverables:
- prestable/staging-
- alert- ( -)
- ( )
— flow, ,
, backport- — , . , (master/develop/trunk), , . git — cherry-picking. "" — , .
- ,
- , . JS — eslint-. Prettier ( ).
, 5-6 , — trunk-based development ( , ). — , , git - . Google , , , , . Facebook , , .
, Trunk-based — " ", , , . , CI/CD, :
feature flags — .
, .
. 2-3 , , ( , )
— merge queue, — , .
, , .
, - :
- github-flow
- CI,
- git-flow ( + )
- CD
- git-flow , CD, staging-,
- trunk-based
- trunk-based-
— . github-flow ( GitOps- — , ). , "". , , — .
, , , , .
Git — , , . , , .
If you feel that your Git hurts you - write to me, I will be happy to help.