GIT Branching

by Inggih . 5 min read

Preparation

Pada dasarnya setiap team diwajibkan memiliki keterampilan untuk menggunakan git (opens in a new tab) dengan tujuan dapat mendokumentasikan history perubahan dengan baik karena biasanya kita bekerja dalam kelompok kecil yang nantinya juga akan berinteraksi secara langsung / tidak dengan kode yang dituliskan.

Branching Strategy

Di awali dengan branching, setiap repository harusnya menggunakan metode berikut untuk dapat memisahkan setiap tujuan perubahan serta tujuan deployment.

Struktur umum di Erasys

├── master
│   ├── development
│   │   ├── feature/current-issue
│   │   ├── fix/current-issue
│   ├── staging
│   ├── uat
│   └── sit

:bangbang: Hal Haram pertama Pada proses inisiasi project dapat dilakukan dengan menggunakan branch master akan tetapi pada proses development tidak diperkenankan untuk menggunakan branch master, staging, uit, sit dan branch lain yang masih 1 level dengan branch-branch tersebut secara langsung, terkecuali sudah disetujui untuk di delivery ke client atau sudah di sepakati sebagai versi tertentu.

Development

Branch berikut sangat umum digunakan dalam fase apapun yang ada pada project erasys, karena branch berikut ditujukan sebagai suatu wadah dimana setiap perubahan atau perbaikan pada tahap pengerjaan awal oleh para developer.

Di dalamnya juga termasuk dengan branch Feature dan Fix yang digunakan untuk tujuan tertentu seperti:

1. feature/current-issue : Segala perubahan yang meliputi tentang pengerjaan suatu fitur pada project yang sedang dikerjakan, selagi feature tersebut belum terselesaikan biasanya branch berikut belum dapat dihapus dikarenakan fase development belum memiliki feedback dari client.

2. fix/current-issue : Menyimpan segala catatan terkait perubahan setelah fase development selesai dan dilakukannya UAT atau sekedar mendapatkan feedback dari staging internal

3. hotfix/current-issue : Menyimpan perubahan terkait dengan issue perbaikan yang tidak harus menunggu fase development selesai atau tanpa harus melewati proses UAT dan biasanya perbaikan dari existing code yang sudah berjalan.

Staging

Branch berikut biasanya digunakan untuk dilakukannya testing secara internal oleh BA (Business Analis) ataupun SA (System Analis) terkait flow dan user journey yang telah disetujui denga client sebelum hasilnya akan diteruskan ke tahap UAT.

UAT (User Acceptance Testing)

Sesuai nama yang ada pada branch berikut biasanya dilakukan sebuah deployment dengan tujuan untuk pengujian langsung dengan client yang ada dan biasanya dilakukan di server atau environtment yang dimiliki oleh client.

SIT (System Integration Testing)

Branch berikut terkadang sering dipakai karena biasanya data yang ada pada saat UAT berupa data dummy (data palsu) karena lebih mengutamakan pemeriksaan terhadap flow dan user journey terkait project yang sedang dikerjakan, yang juga di deploy ke di server maupun environtment client.

Hal yang berbeda dari proses sebelumnya pada tahap berikut seringkali dilakukan pengujian terkait integrasi antar system yang client punya maupun antar pihak ketiga yang digunakan oleh client untuk membantu proses yang ada pada fitur tertentu.

Commit Message Standard

Pada dasarnya commit message ditujukan untuk menandai apasaja perubahan yang sudah dilakukan pada suatu file yang telah kita kerjakan, dengan maksud untuk mendokumentasikan suatu perubahan tersebut dengan adanya catatan apa saja yang sudah dirubah, siapa yang merubahnya, dan kapan dirubah.

Oleh karena itu pada section berikut akan dijelaskan bagaimana sebaiknya kamu mendokumentasikan perubahan tersebut dengan mengikuti aturan-aturan berikut agar dapat dipahami oleh semua team yang juga sedang mengerjakan project yang sama ataupun yang akan masuk kedalam project tersebut.

Kapan sih harus commit?

:bangbang: Bingung kapan harus commit? Sering kali kita dibingungkan kapan sih waktu commit yang baik apakah setelah kita semua telah selesai mengerjakan seluruh feature yang ada? atau kita dapat melakukan commit lebih sering dengan membagi konsentrasi pada feature-feature tertentu? Mari kita coba bahas dibawah yah...

Sebelum mengetahui kapan harus commit kamu juga harus tau dulu bagaimana cara git bekerja yang dapat kamu baca pada dokumentasi resmi Git (opens in a new tab).

Berikut merupakan beberapa opini yang dapat kamu ikuti untuk membantumu mengetahui kapan sih harus melakukan commit tersebut:

1. Saat suatu feature sudah diselesaikan

   Point berikut berfokus saat kamu telah selesai mengerjakan sebuah feature secara utuh, kamu dapat melakukan commit untuk menandai pengerjaan kamu secara keseluruhan, namun cara ini dapat dilakukan jika cakupan feature tersebut tidaklah terlalu besar, karena jika terlalu besar kamu perlu menuliskan banyak keterangan yang akan sulit dibaca.

   Jika kamu terpaksa menggunakan cara berikut kamu dapat memanfaatkan feature deskripsi pada pull / merge request yang adap pada repository suatu project yang ada, untuk selengkapnya kamu dapat mengikuti cara berikut, Link ke cara buat pull request.

2. Saat suatu tujuan pada feature sudah terpenuhi

   Point berikut bisanya lebih baik digunakan ketika kamu mengerjakan suatu feature denga cakupan atau dengan checklist yang banyak, kenapa demikian? karena dengan menandai setiap perubahan yang dianggap memiliki suatu maksud tertentu akan memudahkan rekan atau dirimu sendiri dalam membaca histroy perubahan dari file tersebut sehingga jika memiliki beberapa concern tertentu juga dapat tesampaikan dengan baik karena commit message mencakup hal yang kecil.

3. maximum diff changes untuk 1x commit dan dalam 1x Pull Request max 15 file

   Hal ini digunakan untuk mempermudah dalam melakukan proses review code dan memperjelas bagian perubahan code dari suatu feature yang memang mempunyai massive code changes. Jika memang perubahan yang kita lakukan mencapai lebih dari 15 file, maka akan sangat membantu jika bisa dibuat secara partial

Membuat commit message yang readable

:bangbang: Readable? iya yang bisa di baca orang Commit message yang baik menjadi sebuah indikasi yang bagus bagi seorang developer meskipun hal tersebut terlihat remeh namun ketika commit message tersebut membantu developer lainnya dalam memahami setiap perubahan yang kamu lakukan itu juga membuatmu dapat dimengerti oleh rekan yang lainnya.

Contoh berikut adalah salah salatu contoh yang kita adaptasi dari sebuah project besar yang melibatkan banyak developer dengan berbagai latar blakang yang berbeda, dan negara yang bebeda pula.

    Example:
 
    [#issue feat/fix][entrypoint/endpoint]: Commit description
    |_______________||___________________| |__________________|

Dapat dilihat dari contoh yang ada di atas, commit message yang baik dapat menerangkan issue apa yang sedang dikerjakan, apakah itu bagian dari sbuah feature baru ataukah sebuah perubahan yang dilakukan karena adanya feedback baik itu dari client ataupun internal team, juga terdapat entrypoint atau endpoint apa yang sedang dirubah untuk dapat memudahkan mencari maksud dari sebuah commit, serta tambahan deskripsi dari apa saja yang telah kita kerjakan.

Note internal, bukan untuk dimasukin: untuk commit biasanya sih gitu, pas PR baru diperjelas

Contoh lainnya yang juga dapat dicoba:

    Example:
 
    [ID_YOUTRACK_TICKET]: Feature - Description

// TODO: ini bisa di kasih satu line lagi terkait line berikutnya yang bisa di manfaatkan sebagai keterangan tambahan seperti todo, concern tertentu, atau referensi

Push behaviours

:bangbang: Sering push tanpa pull dulu? Sebaiknya kamu baca ini deh. Tak banyak dari kita yang sering mengerjakan suatu pekerjaan secara single fighter sehingga terkadang kita tanpa ragu mengunggah setiap perubahan kita tanpa memperhatikan perubahan lain karena sudah pasti hanya kita saja yang ada di dalam project tersebut.

Namun, bagaimana jika kamu bekerja secara team? apakah kamu akan melakukannya dengan hal yang sama? oh tentu, sebagian dari kita seringkali berfikir bahwa apa yang kita ubah tidak akan mempengaruhi pekerjaan orang lain karena setiap pekerjaan tersebut sudah dibagi sesuai tasknya masing-masing, tapi apakah kita sadar kalau kita bekerja dengan sebuah codebase yang sama dengan yang dikerjakan rekan kita? sudah sadar? oke mari kita mulai.

Pada dasarnya push adalah salah satu proses terpenting untuk mengunggah perubahan kita ke dalam repository yang ada untuk dapat didokumentasikan atau di test. Namun, ada baiknya sebelum melakukan itu kita juga dapat melihat apa saja perubahan terbaru pada branch induk kita agar branch local kita tetap uptodate dengan branch induk agar mengetahui apakah perubahan lain mengganggu kode yang kita tulis atau bahkan sebaliknya.

Tips - Tips

Mungkin sebagian sudah tahu bagaimana cara mensinkronisasi branch local dengan branch induk seperti branch development dengan menggunakan command seperti berikut:

git pull origin branch-name

Cara ini memanglah cara yang umum digunakan, namun penggunaan nya dapat menimbulkan history yang buruk karena pada command terseubut setiap perubahan terbaru yang ada akan digabungkan dengan perubahan yang ada pada repository local kita yang juga membuat sebuah commit baru yang memiliki nama seperti merge 8798798 from 87987 shingga nantinya menimbulkan history yang seperti berikut:

// ini nantinya gambar history dari git pull

Untuk dapat mengatasi hal tersebut kamu dapat menggunakan git pull --rebase agar semua perubahan terbaru tidak di merge telebih dahulu di local, atau juga bisa menggunakan git fetch specific-branch lalu jika ada conflict kamu dapat merubahnya terlebih dahulu sebelum melakukan merge pada local repositorymu. hasil dari historynya akan terlihat seperti berikut:

// Ini nantinya gambar history dari git pull --rebase dan git fetch

TODO: Penjelasan tentang yang fast track yang ga bisa di dapat dari git pull.

Dealing with conflict

:bangbang: Ada conflict di kodemu pas ngepull kode terbaru? Tenang, jangan panik Conflict adalah hal yang bisa terjadi ketika kita bekerja dengan beberapa orang dalam satu project, hal tersebut biasanya terjadi ketika kita bekerja di baris yang sama pada suatu file di project tersebut.

Sebelum kamu memutuskan untuk memilih salah satu atau membiarkan keduanya tetap di terapkan pada file tersebut ada baiknya kamu dapat memperhatikan hal berikut terlebih dahulu:

1. Diskusikan dengan orang yang terkait Jika kamu dapat berkomunikasi dengan rekan yang sedang mengerjakan hal tersebut ada baiknya kamu dapat menanyakan sebuah concern mengapa kode tersebut dibuat dan apakah kode yang sedang kamu buat bisa diletakkan berdampingan dengan kodenya? atau bahkan kamu harus memilih salah satu saja?

2. Jika orangnya sudah tak bersama team lagi Hal berikut sering kali ditemukan ketika kita mengerjakan sebuah project yang sudah lama tidak di maintanance lagi oleh si developer, jika hal ini terjadi, kamu dapat memastikan terlebih dahulu kode yang berasal dari developer lain tidak mengganggu sebuah flow yang ada atau juga bisa pastikan apakah hal tersebut sudah tidak digunakan lagi sehingga kamu dapat menggantinya dengan kodemu sendiri.

3. Hal lainnya lagi, tapi nanti yah....

Tools yang mempermudah hidupmu

TODO: nulisin list tools yang bisa buat membantu temen2 lainnya.