Suatu hari ada artikel yang indah dan kontroversial - Tolong, berhenti menggunakan GitFlow! (dan selusin lagi tentang topik yang sama setelah itu).
Poin utamanya adalah:
- GitFlow bertentangan dengan tesis "cabang harus berumur pendek."
Ini penting, karena semakin sedikit cabang yang hidup, semakin sedikit kemungkinan konflik (tidak hanya git, tetapi juga logis) - GitFlow tidak menyarankan rebases untuk menyimpan komit gabungan.
Ya, mereka bisa diselamatkan dengan membangun kembali, tetapi tim Git Flow tidak. - GitFlow menyangkal pendekatan Pengiriman Kontinyu, percaya bahwa setiap tindakan Pengiriman harus dilakukan oleh seorang insinyur rilis, dan secara umum Anda dapat melihat bahwa itu berfokus hanya pada siklus rilis yang panjang.
- GitFlow bukan teman dengan layanan mikro di atas multi-repositori (namun, tidak banyak yang bisa dilakukan di sini, itu adalah ide yang selalu berakhir buruk)
Tetapi masalah dengan GitFlow adalah bahwa ia juga tidak berteman dengan repositori tunggal.
Saya sendiri menemukan ini dalam proses mendesain pipa CI: GitFlow sangat mengganggu ketika bekerja di atas satu repositori dengan beberapa hasil kerja, misalnya, ketika backend dan frontend terpisah dalam repositori yang sama - karena memungkinkan Anda untuk berkomitmen untuk melepaskan cabang, konflik dapat terjadi dengan penggabungan terbalik jika lebih dari satu cabang rilis ada pada suatu waktu. Ya, bahkan jika itu salah, itu semua sama buruknya - dalam kondisi seperti itu perlu untuk menambal mekanisme rilis GitFlow pada prinsipnya, sehingga setidaknya entah bagaimana rilis terpisah entitas bekerja.
Jadi apa yang harus dilakukan?
Penulis artikel asli dibantu oleh pengembangan + flag fitur berbasis trunk - hampir google green trunk, tetapi tidak juga. Tetapi ini tidak berarti sama sekali bahwa Anda memerlukan pendekatan ini.
Pertama, Anda perlu memahami prioritas.
Seperti apa rilis Anda?
- ? , , , , ?
- ? , , 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 — , , . , , .
Jika Anda merasa bahwa Git Anda menyakiti Anda - menulis kepada saya, saya akan dengan senang hati membantu.