Artikel ini merupakan kelanjutan dari artikel Gitty Workflow, di mana kita membahas dasar-dasar Git dan alur kerja Push/Pull yang sederhana.
Artikel ini akan fokus pada alur kerja git yang lebih baik yang melibatkan cabang pementasan/pengembangan perantara; juga mengeksplorasi beberapa konsep baru seperti Konflik, Rebasing, & Penggabungan.
Anda mungkin bertanya-tanya, Mengapa ada orang yang bersusah payah memelihara cabang perantara ketika seseorang dapat langsung memasukkan fitur baru atau pembaruan ke cabang utama?
Hampir semua proyek pengembangan perangkat lunak siap produksi memerlukan pengembangan multi-level, pengujian, dan siklus QA. Dengan demikian, kemungkinan kesalahan atau bug pada basis kode utama Anda juga meningkat. Oleh karena itu, mungkin bukan ide yang baik untuk langsung memasukkan fitur Anda ke cabang utama hingga diuji secara menyeluruh. Untuk mencegah hal ini, kita sering menggunakan salinan cabang utama, biasanya disebut sebagai cabang pementasan atau pengembangan.
Tujuan dari cabang “staging” adalah untuk berfungsi sebagai cabang akar untuk semua cabang fitur. Dan setelah sebuah fitur selesai, fitur tersebut digabungkan ke dalam cabang “staging”, diuji secara menyeluruh menggunakan lingkungan staging sebelum dimasukkan ke cabang “utama”.
Konflik
Saat mempraktikkan alur kerja ini, Anda mungkin sering menemui sesuatu yang disebut konflik penggabungan saat mencoba menggabungkan dua cabang.
Dan kode Anda mungkin berubah menjadi kekacauan ini.
Mari kita lihat apa itu konflik penggabungan, kapan biasanya terjadi, dan bagaimana cara mengatasinya.
Konflik muncul ketika dua cabang terpisah melakukan pengeditan pada baris yang sama dalam sebuah file.
Mari kita pahami ini dengan menggunakan sebuah contoh. Katakanlah dua pengembang sedang mengerjakan file yang sama sample.html .
Dev-A & Dev-B masing-masing membuat cabang f1 dan f2 dari develop.
Dev-A menambahkan kode pada baris 10, mengkomitnya, dan menggabungkan kodenya kembali ke cabang develop.
Sementara itu, Dev-B menambahkan kode yang sedikit berbeda pada posisi baris 10 yang sama.
Sekarang, ketika Dev-B menyinkronkan develop masing-masing menggunakan git pull dan mencoba menggabungkan versi kodenya yang berada di cabangf2 menjadi develop; hal ini menimbulkan konflik penggabungan karena cabang f2 masih memiliki versi sample.html yang sudah ketinggalan zaman, yaitu versi sebelum cabang f1 digabungkan.
Jadi, ketika f2 mencoba membuat perubahan tepat di tempat f1 melakukan perubahannya, Git memunculkan konflik penggabungan, memungkinkan Dev-B memilih versi kode mana yang final.
Namun, kita dapat menghindari konflik penggabungan tersebut pada saat permintaan penarikan menggunakan perintah Rebasing atau Merge sebelum mendorong komitmen Anda ke jarak jauh.
Baik git rebase & git merge memecahkan masalah mendasar yang sama: menyinkronkan perubahan dari satu cabang ke cabang lainnya. Mari kita lihatgit rebase & git merge lebih dalam.
git bergabung
git merge adalah opsi termudah dan teraman untuk memasukkan perubahan orang lain ke dalam perubahan Anda.
Katakanlah Anda sedang mengerjakan API bangunan di cabang bernama api-dev yang Anda fork dari main. Sementara itu, salah satu anggota tim Anda menggabungkan perubahan terkait UI di main.
Untuk mengintegrasikan API Anda sepenuhnya, Anda ingin membawa perubahan UI yang baru saja digabungkan di main di dalam cabang fitur Anda api-dev.
Anda dapat gunakan
git merge <source_branch> <target_branch> OR
git checkout <target_branch> git merge <source_branch>
dalam hal ini, target_branch adalah api-devdan source_branch adalah main
Apa yang git mergeis akan lakukan adalah menyingkat semua perubahan menjadi satu komit dan menuliskannya di atas log komit.
git rebase
Di sisi lain, rebase akan menulis ulang seluruh riwayat komit dengan memasukkan komit yang hilang dan mengurutkan log komit berdasarkan urutan waktu komit.
Bonus
git ambil
git fetch digunakan untuk menyinkronkan perubahan dari repo jarak jauh ke repo lokal Anda. Misalnya, rekan satu tim Anda mendorong cabang fitur baru, dan Anda ingin menguji cabang tersebut. Untuk memeriksa cabang, Anda harus menyinkronkannya. Dan di situlah git fetch berguna.
Catatan: git fetch hanya menyinkronkan komitmen repo jarak jauh, tidak benar-benar membawa perubahan tersebut dari jarak jauh ke lokal. Untuk itu, Anda harus menggabungkan repo jarak jauh dengan repo lokal menggunakan git merge origin/<branch_name> <branch_name> atau menggunakan git pull
git tarik
git pull adalah perintah singkat untuk git fetch dan git merge . Jadi, setiap kali repo jarak jauh Anda lebih unggul dari repo lokal, Anda ingin melakukan perubahan tersebut. Anda dapat menggunakan git pull .
Oleh karena itu, bukannya
git checkout main git fetch git merge origin/main
Anda bisa melakukannya
git checkout main git pull
Dan cabang repo lokal Anda akan konsisten dengan cabang repo jarak jauh.
Catatan:Anda mungkin juga mengalami konflik saat melakukan git pull.
