Apa pro dan kontra dari git-flow vs github-flow? [Tutup]


125

Kami baru-baru ini mulai menggunakan GitLab.

Saat ini menggunakan alur kerja "terpusat".

Kami sedang mempertimbangkan untuk pindah ke aliran github tetapi saya ingin memastikan.

Apa pro dan kontra dari git-flow vs github-flow ?

Jawaban:


133

Seperti yang dibahas di GitMinutes episode 17, oleh Nicholas Zakas dalam artikelnya tentang " Alur kerja GitHub di dalam perusahaan ":

Git-flow adalah proses untuk mengelola perubahan di Git yang dibuat oleh Vincent Driessen dan disertai dengan beberapa ekstensi Git untuk mengelola aliran tersebut.
Ide umum di belakang git-aliran adalah memiliki beberapa cabang yang terpisah yang selalu ada, masing-masing untuk tujuan yang berbeda: master, develop, feature, release, dan hotfix.
Proses pengembangan fitur atau bug mengalir dari satu cabang ke cabang lain sebelum akhirnya dirilis.

Beberapa responden menyatakan bahwa mereka menggunakan git-flowsecara umum.
Beberapa memulai git-flowdan menjauh darinya.

Alasan utama untuk pindah adalah karena git-flowprosesnya sulit untuk ditangani dalam model penerapan yang berkelanjutan (atau hampir berkelanjutan).
Secara umum, hal ini git-flowbekerja dengan baik untuk produk dalam model rilis yang lebih tradisional, di mana rilis dilakukan setiap beberapa minggu sekali, tetapi proses ini rusak secara signifikan saat Anda merilisnya sekali sehari atau lebih .

Pendeknya:

Mulailah dengan model yang sesederhana mungkin (seperti aliran GitHub yang cenderung), dan lanjutkan ke model yang lebih kompleks jika perlu.


Anda dapat melihat ilustrasi menarik dari alur kerja sederhana , berdasarkan GitHub-Flow di:
" Model percabangan git sederhana ", dengan elemen utamanya adalah:

  1. master harus selalu dapat diterapkan.
  2. semua perubahan yang dilakukan melalui cabang fitur (pull-request + merge)
  3. dasar untuk menghindari / menyelesaikan konflik; bergabung menjadimaster

https://a248.e.akamai.net/camo.github.com/9783623eba280ba5ace8b9e63842be52af2f0546/687474703a2f2f7374617469632e62656e65742e61692f736b697463682f666c6f772d32933313671392


Untuk alur kerja aktual yang lebih lengkap dan kuat, lihat alur kerja git (satu kata) .


88

Tidak ada alur kerja poin perak di mana setiap orang harus mengikuti, karena semua model kurang optimal. Karena itu, Anda dapat memilih model yang sesuai untuk perangkat lunak Anda berdasarkan poin di bawah ini;

Beberapa versi dalam produksi - gunakan Git-flow

Jika kode Anda memiliki beberapa versi dalam produksi (misalnya, produk perangkat lunak umum seperti Sistem Operasi, Paket Office, Aplikasi kustom, dll), Anda dapat menggunakan git-flow. Alasan utamanya adalah Anda harus terus mendukung versi sebelumnya dalam produksi sambil mengembangkan versi berikutnya.

Versi tunggal dalam perangkat lunak sederhana produksi - gunakan Github-flow

Jika kode Anda hanya memiliki satu versi dalam produksi setiap saat (yaitu situs web, layanan web, dll), Anda dapat menggunakan github-flow. Alasan utamanya adalah Anda tidak perlu hal-hal rumit untuk pengembang. Setelah pengembang menyelesaikan fitur atau menyelesaikan perbaikan bug, fitur tersebut segera dipromosikan ke versi produksi.

Versi Tunggal dalam produksi tetapi perangkat lunak yang sangat kompleks - gunakan Gitlab-flow

Perangkat lunak besar seperti Facebook dan Gmail, Anda mungkin perlu memperkenalkan cabang penerapan antara cabang dan cabang master tempat alat CI / CD> dapat berjalan, sebelum masuk ke produksi. Ide adalah untuk memperkenalkan lebih banyak perlindungan pada versi produksi sejak digunakan oleh jutaan orang.


7
Hanya menambahkan "Gitdmz-flow" / "Git DMZ Flow" ke daftar: gist.github.com/djspiewak/9f2f91085607a4859a66
Robert Fey

1
Perusahaan yang direferensikan menggunakan sistem berbasis trunk. paulhammant.com/2014/01/08/...
PatrickWalker

1
Aliran Git DMZ lebih mirip dengan Gitflow dan cabang DMZ seperti mengembangkan cabang. Karenanya saya merasa tidak ada yang istimewa tentang itu.
Gayan Pathirage

2
Dari pemahaman saya, Git-Flow tidak berfungsi dengan baik dengan versi multi-produksi. Strategi perbaikan terbaru mengasumsikan Anda hanya memiliki satu versi produksi, dan Anda melakukan perbaikan terbaru pada cabang rilis yang sesuai (dan kemudian menggabungkannya kembali untuk mengembangkan cabang). Tampaknya tidak melayani bagaimana Anda dapat memperbaiki satu bug yang ada di beberapa cabang produksi.
Adrian Shum

5
@GayanPhirage Sebenarnya tidak. 1. Tag GitFlow "klasik" di master. Cabang perbaikan terbaru hanya bagi Anda untuk melakukan perbaikan terhadap versi produksi terbaru (dari master). 2. "cabang rilis" berarti sesuatu yang lain di Gitflow, yang sebenarnya merupakan cabang pratinjau pra-rilis (bercabang dari cabang pengembangan, dan bertujuan untuk menggabungkan ke master ketika benar-benar dirilis). 3. Yang Anda maksud adalah sesuatu yang disebut "cabang dukungan" di GitFlow (Itulah salah satu alasan saya tidak menyukai GitFlow: terminologi yang tidak konvensional). Namun aliran ini masih eksperimental (jadi Anda tidak melihatnya di sebagian besar Intro Gitflow)
Adrian Shum

38

Saya telah menggunakan model git-flow selama lebih dari setahun dan tidak apa-apa.

Tetapi itu sangat tergantung pada bagaimana aplikasi Anda akan dikembangkan dan digunakan.

Ini berfungsi dengan baik ketika Anda memiliki aplikasi yang memiliki aliran pengembangan / penerapan yang lambat.

Tapi misalnya seperti GitHub kami memiliki aplikasi yang memiliki aliran pengembangan / penerapan yang cepat, kami menerapkan setiap hari, dan terkadang beberapa kali sehari, dalam hal ini, git-flow cenderung memperlambat semuanya menurut saya, dan saya menggunakan GitHub mengalir.

Hal lain yang perlu dipertimbangkan adalah, git-flow bukan standar git, jadi Anda mungkin saja, dan ketika saya mengatakan mungkin, maksud saya, Anda akan menemukan pengembang yang tidak mengetahuinya, dan kemudian ada kurva pembelajaran, selengkapnya kesempatan untuk mengacaukan segalanya. Seperti yang disebutkan di atas, seseorang mengembangkan satu set skrip untuk membuat penggunaan git-flow lebih mudah, jadi Anda tidak perlu mengingat semua perintah, ini akan membantu Anda dengan perintah, tetapi mengingat aliran sebenarnya adalah tugas Anda. , Saya telah menjumpai lebih dari sekali ketika pengembang tidak tahu apakah itu hotfix atau fitur, atau bahkan yang terburuk ketika mereka tidak dapat mengingat aliran dan mengatur semuanya.

Setidaknya ada satu GUI yang mendukung git-flow untuk Mac dan Windows SourceTree .

Hari-hari ini, saya lebih condong ke aliran GitHub, karena kesederhanaannya dan mudah dikelola. Selain itu, karena "terapkan lebih awal lebih sering" ...

Semoga ini membantu


+1. Saya setuju denganmu.
VonC

2
Aliran GitHub ada dalam Git-Flow. Pikirkan jika Anda memerlukan integrasi berkelanjutan dan penerapan berkelanjutan, Anda dapat menjalankannya sebanyak mungkin dengan mengembangkan cabang. Setiap fitur bercabang dari cabang pengembangan. Anda mungkin tidak memerlukan cabang master atau cabang rilis kecuali Anda memiliki model penerapan yang kompleks. (misalnya versi 1.1 Anda ada di beberapa klien, 1.2 Anda ada di klien lain dan saat ini Anda mengembangkan 1.3 untuk klien baru Anda) Ketiga klien tersebut akan meminta perbaikan bug dan perubahan pada versi mereka masing-masing.
Gayan Pathirage

Halo Diego dan terima kasih atas jawaban Anda. Bagaimana dengan pemeliharaan beberapa versi? Apakah Anda melakukannya dengan mudah dengan Git Flow? Saya pernah mendengarnya sulit karena Anda membutuhkan cabang pendukung! Apakah Anda yakin model ini cocok untuk melakukannya?
Luis Gouveia

1
Hai Luis, saya rasa Anda dapat membuat model berfungsi, tetapi sekali lagi saya merasa Anda dapat mencapai hal yang sama dengan alur kerja git standar.
Diego Antunes

1
@LuisGouveia sebenarnya, karena pertanyaan Anda dan balasan saya di atas, saya menemukan sebuah proyek yang git-flow akan bekerja dengan sempurna, dan saya memiliki kepemilikan atas proyek tersebut. Idenya adalah untuk digunakan git flow release...dalam kombinasi dengan tindakan github untuk menyebarkan aplikasi. Dalam tanggapan asli saya, saya menyebutkan bahwa kami merilis beberapa kali dalam sehari, ini menyebabkan masalah saat menggunakan git-flow. Alasan saya pikir git-flow akan bekerja dengan baik dalam proyek ini adalah karena kami memiliki siklus rilis yang telah ditentukan sebelumnya, yang merupakan salah satu nilai jual utama untuk menggunakan git-flow.
Diego Antunes
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.