Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Strategi percabangan Gitflow
<a name="gitflow-branching-strategy"></a>

Gitflow adalah model percabangan yang melibatkan penggunaan beberapa cabang untuk memindahkan kode dari pengembangan ke produksi. Gitflow berfungsi dengan baik untuk tim yang memiliki siklus rilis terjadwal dan kebutuhan untuk mendefinisikan kumpulan fitur sebagai rilis. Pengembangan diselesaikan di cabang fitur individu yang digabungkan, dengan persetujuan, menjadi cabang pengembangan, yang digunakan untuk integrasi. Fitur-fitur di cabang ini dianggap siap untuk produksi. Ketika semua fitur yang direncanakan telah terakumulasi di cabang pengembangan, cabang rilis dibuat untuk penerapan ke lingkungan atas. Pemisahan ini meningkatkan kontrol atas perubahan mana yang bergerak ke lingkungan bernama mana pada jadwal yang ditentukan. Jika perlu, Anda dapat mempercepat proses ini menjadi model penerapan yang lebih cepat.

Untuk informasi selengkapnya tentang strategi percabangan Gitflow, lihat sumber daya berikut:
+ [Menerapkan strategi percabangan Gitflow untuk DevOps lingkungan multi-akun](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) (AWS Panduan Preskriptif)
+ Blog [Gitflow asli (posting blog](https://nvie.com/posts/a-successful-git-branching-model/) Vincent Driessen)
+ [Alur kerja Gitflow (Atlassian](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow))

**Topics**
+ [

# Gambaran visual dari strategi Gitflow
](visual-overview-of-the-gitflow-strategy.md)
+ [

# Cabang dalam strategi Gitflow
](branches-in-a-gitflow-strategy.md)
+ [

# Keuntungan dan kerugian dari strategi Gitflow
](advantages-and-disadvantages-of-the-gitflow-strategy.md)

# Gambaran visual dari strategi Gitflow
<a name="visual-overview-of-the-gitflow-strategy"></a>

Diagram berikut dapat digunakan seperti [kotak Punnett](https://en.wikipedia.org/wiki/Punnett_square) untuk memahami strategi percabangan Gitflow. Sejajarkan cabang pada sumbu vertikal dengan AWS lingkungan pada sumbu horizontal untuk menentukan tindakan apa yang harus dilakukan dalam setiap skenario. Angka yang dilingkari memandu Anda melalui urutan tindakan yang diwakili dalam diagram. Untuk informasi lebih lanjut tentang aktivitas yang terjadi di setiap lingkungan, lihat [DevOps lingkungan](understanding-the-devops-environments.md) dalam panduan ini.



![\[Kotak Punnett dari aktivitas Gitflow di setiap cabang dan lingkungan\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-diagram.png)


# Cabang dalam strategi Gitflow
<a name="branches-in-a-gitflow-strategy"></a>

Strategi percabangan Gitflow biasanya memiliki cabang berikut.



![\[Cabang dan lingkungan dalam strategi percabangan Gitflow.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png)


## cabang fitur
<a name="feature-branch"></a>

`Feature`cabang adalah cabang jangka pendek tempat Anda mengembangkan fitur. `feature`Cabang dibuat dengan bercabang dari `develop` cabang. Pengembang mengulangi, melakukan, dan menguji kode di `feature` cabang. Ketika fitur selesai, pengembang mempromosikan fitur tersebut. Hanya ada dua jalur ke depan dari cabang fitur:
+ Gabungkan ke dalam cabang `sandbox`
+ Buat permintaan gabungan ke cabang `develop`


|  |  | 
| --- |--- |
| Konvensi penamaan: | `feature/<story number>_<developer initials>_<descriptor>` | 
| Contoh konvensi penamaan: | `feature/123456_MS_Implement_Feature_A` | 

## cabang kotak pasir
<a name="sandbox-branch"></a>

`sandbox`Cabang adalah cabang jangka pendek non-standar untuk Gitflow. Namun, ini berguna untuk pengembangan CI/CD pipa. `sandbox`Cabang ini terutama digunakan untuk tujuan berikut:
+ Lakukan penyebaran penuh ke lingkungan kotak pasir dengan menggunakan CI/CD pipeline daripada penerapan manual.
+ Kembangkan dan uji pipa sebelum mengirimkan permintaan gabungan untuk pengujian penuh di lingkungan yang lebih rendah, seperti pengembangan atau pengujian.

`Sandbox`cabang bersifat sementara dan tidak dimaksudkan untuk berumur panjang. Mereka harus dihapus setelah pengujian spesifik selesai.


|  |  | 
| --- |--- |
| Konvensi penamaan: | `sandbox/<story number>_<developer initials>_<descriptor>` | 
| Contoh konvensi penamaan: | `sandbox/123456_MS_Test_Pipeline_Deploy` | 

## mengembangkan cabang
<a name="develop-branch"></a>

`develop`Cabang adalah cabang berumur panjang di mana fitur terintegrasi, dibangun, divalidasi, dan dikerahkan ke lingkungan pengembangan. Semua `feature` cabang digabung ke dalam `develop` cabang. Penggabungan ke dalam `develop` cabang diselesaikan melalui permintaan gabungan yang memerlukan build yang berhasil dan dua persetujuan pengembang. Untuk mencegah penghapusan, aktifkan perlindungan cabang di cabang. `develop`


|  |  | 
| --- |--- |
| Konvensi penamaan: | `develop` | 

## cabang rilis
<a name="release-branch"></a>

Di Gitflow, `release` cabang adalah cabang jangka pendek. Cabang-cabang ini istimewa karena Anda dapat menerapkannya ke beberapa lingkungan, merangkul metodologi build-once, deploy-many. `Release`cabang dapat menargetkan pengujian, pementasan, atau lingkungan produksi. Setelah tim pengembangan memutuskan untuk mempromosikan fitur ke lingkungan yang lebih tinggi, mereka membuat `release` cabang baru dan menggunakan penambahan nomor versi dari rilis sebelumnya. Di gerbang di setiap lingkungan, penerapan memerlukan persetujuan manual untuk melanjutkan. `Release`cabang harus membutuhkan permintaan penggabungan untuk diubah.

Setelah `release` cabang diterapkan ke produksi, cabang harus digabungkan kembali ke `main` cabang `develop` dan untuk memastikan bahwa perbaikan bug atau perbaikan terbaru digabungkan kembali ke upaya pengembangan masa depan.


|  |  | 
| --- |--- |
| Konvensi penamaan: | `release/v{major}.{minor}` | 
| Contoh konvensi penamaan: | `release/v1.0` | 

## cabang utama
<a name="main-branch"></a>

`main`Cabang adalah cabang berumur panjang yang selalu mewakili kode yang berjalan dalam produksi. Kode digabungkan ke `main` cabang secara otomatis dari cabang rilis setelah penerapan berhasil dari pipeline rilis. Untuk mencegah penghapusan, aktifkan perlindungan cabang di cabang. `main`


|  |  | 
| --- |--- |
| Konvensi penamaan: | `main` | 

## cabang bugfix
<a name="bugfix-branch"></a>

`bugfix`Cabang adalah cabang jangka pendek yang digunakan untuk memperbaiki masalah di cabang rilis yang belum dirilis ke produksi. `bugfix`Cabang hanya boleh digunakan untuk mempromosikan perbaikan di `release` cabang ke lingkungan pengujian, pementasan, atau produksi. `bugfix`Cabang selalu bercabang dari `release` cabang.

Setelah perbaikan bug diuji, itu dapat dipromosikan ke `release` cabang melalui permintaan gabungan. Kemudian Anda dapat mendorong `release` cabang ke depan dengan mengikuti proses rilis standar.


|  |  | 
| --- |--- |
| Konvensi penamaan: | `bugfix/<ticket>_<developer initials>_<descriptor>` | 
| Contoh konvensi penamaan: | `bugfix/123456_MS_Fix_Problem_A` | 

## cabang hotfix
<a name="hotfix-branch"></a>

`hotfix`Cabang adalah cabang jangka pendek yang digunakan untuk memperbaiki masalah dalam produksi. Ini hanya digunakan untuk mempromosikan perbaikan yang harus dipercepat untuk mencapai lingkungan produksi. `hotfix`Cabang selalu bercabang dari`main`.

Setelah hotfix diuji, Anda dapat mempromosikannya ke produksi melalui permintaan gabungan ke `release` cabang yang dibuat dari. `main` Untuk pengujian, Anda kemudian dapat mendorong `release` cabang ke depan dengan mengikuti proses rilis standar.


|  |  | 
| --- |--- |
| Konvensi penamaan: | `hotfix/<ticket>_<developer initials>_<descriptor>` | 
| Contoh konvensi penamaan: | `hotfix/123456_MS_Fix_Problem_A` | 

# Keuntungan dan kerugian dari strategi Gitflow
<a name="advantages-and-disadvantages-of-the-gitflow-strategy"></a>

Strategi percabangan Gitflow sangat cocok untuk tim yang lebih besar dan lebih terdistribusi yang memiliki persyaratan rilis dan kepatuhan yang ketat. Gitflow berkontribusi pada siklus rilis yang dapat diprediksi untuk organisasi, dan ini sering disukai oleh organisasi yang lebih besar. Gitflow juga cocok untuk tim yang membutuhkan pagar pembatas untuk menyelesaikan siklus pengembangan perangkat lunak mereka dengan benar. Ini karena ada banyak peluang untuk ulasan dan jaminan kualitas yang dibangun ke dalam strategi. Gitflow juga cocok untuk tim yang harus mempertahankan beberapa versi rilis produksi secara bersamaan. Beberapa kelemahan GItflow adalah bahwa itu lebih kompleks daripada model percabangan lainnya dan membutuhkan kepatuhan yang ketat terhadap pola untuk menyelesaikan dengan sukses. Gitflow tidak bekerja dengan baik untuk organisasi yang berjuang untuk pengiriman berkelanjutan karena sifat kaku mengelola cabang rilis. Cabang rilis Gitflow dapat menjadi cabang berumur panjang yang dapat mengakumulasi utang teknis jika tidak ditangani dengan benar tepat waktu.

## Keuntungan
<a name="advantages"></a>

Pengembangan berbasis GitFlow menawarkan beberapa keuntungan yang dapat meningkatkan proses pengembangan, merampingkan kolaborasi, dan meningkatkan kualitas perangkat lunak secara keseluruhan. Berikut ini adalah beberapa manfaat utama:
+ **Proses rilis yang dapat diprediksi** — Gitflow mengikuti proses rilis reguler dan dapat diprediksi. Ini sangat cocok untuk tim dengan pengembangan reguler dan irama rilis.
+ **Kolaborasi yang ditingkatkan** - Gitflow mendorong penggunaan `feature` dan `release` cabang. Kedua cabang ini membantu tim bekerja secara paralel dengan ketergantungan minimal satu sama lain.
+ **Sangat cocok untuk beberapa lingkungan** — Gitflow menggunakan `release` cabang, yang bisa menjadi cabang yang berumur lebih panjang. Cabang-cabang ini memungkinkan tim untuk menargetkan rilis individu dalam jangka waktu yang lebih lama.
+ **Beberapa versi dalam produksi** - Jika tim Anda mendukung beberapa versi perangkat lunak dalam produksi, `release` cabang Gitflow mendukung persyaratan ini.
+ **Ulasan kualitas kode bawaan** — Gitflow membutuhkan dan mendorong penggunaan ulasan kode dan persetujuan sebelum kode dipromosikan ke lingkungan lain. Proses ini menghilangkan gesekan antar pengembang dengan mengharuskan langkah ini untuk semua promosi kode.
+ **Manfaat organisasi** — Gitflow memiliki keunggulan di tingkat organisasi juga. Gitflow mendorong penggunaan siklus rilis standar, yang membantu organisasi memahami dan mengantisipasi jadwal rilis. Karena bisnis sekarang memahami kapan fitur baru dapat dikirimkan, ada pengurangan gesekan tentang jadwal karena ada tanggal pengiriman yang ditetapkan.

## Kekurangan
<a name="disadvantages"></a>

Pengembangan berbasis Gitflow memang memiliki beberapa kelemahan yang dapat berdampak pada proses pengembangan dan dinamika tim. Berikut ini adalah beberapa kelemahan penting:
+ **Kompleksitas** — Gitflow adalah pola kompleks untuk dipelajari tim baru, dan Anda harus mematuhi aturan Gitflow agar berhasil menggunakannya.
+ **Penerapan berkelanjutan** — Gitflow tidak sesuai dengan model di mana banyak penerapan dirilis ke produksi dengan cepat. Ini karena Gitflow memerlukan penggunaan beberapa cabang dan alur kerja yang ketat yang mengatur cabang. `release`
+ **Manajemen cabang** — Gitflow menggunakan banyak cabang, yang dapat menjadi beban untuk dipertahankan. Mungkin sulit untuk melacak berbagai cabang dan menggabungkan kode yang dirilis untuk menjaga cabang tetap sejajar satu sama lain.
+ **Utang teknis** — Karena rilis Gitflow biasanya lebih lambat daripada model percabangan lainnya, lebih banyak fitur dapat terakumulasi untuk rilis, yang dapat menyebabkan utang teknis menumpuk.

Tim harus mempertimbangkan dengan cermat kelemahan ini ketika memutuskan apakah pengembangan berbasis GitFlow adalah pendekatan yang tepat untuk proyek mereka.