Alur Kerja Git untuk Pro: Panduan Git yang Baik

Git dapat mendukung proyek Anda tidak hanya dengan kontrol versi, tetapi juga dengan kolaborasi dan manajemen rilis. Memahami bagaimana pola alur kerja Git dapat membantu atau menghambat proyek akan memberi Anda pengetahuan untuk mengevaluasi dan menyesuaikan proses Git proyek Anda secara efektif.

Sepanjang panduan ini saya akan mengisolasi pola proses pengembangan perangkat lunak yang ditemukan dalam alur kerja Git yang umum. Pengetahuan tentang ini akan membantu Anda menemukan arah saat bergabung, membuat, atau mengembangkan tim pengembangan. Pro dan kontra untuk jenis proyek atau tim tertentu akan disorot dalam contoh alur kerja yang kami jelajahi, sehingga Anda dapat memilih apa yang mungkin bekerja dengan baik untuk skenario Anda.

Ini bukan pengantar untuk menggunakan Git. Ada panduan dan dokumentasi yang luar biasa untuk ini di luar sana. Anda akan mendapat manfaat dari panduan alur kerja Git ini jika Anda sudah memiliki pengalaman dalam tim pengembangan aplikasi dan telah menghadapi hambatan alur kerja, ledakan integrasi, atau git-tastrophes - pola ini dapat menjelaskan cara menghindari situasi tersebut di masa mendatang.

Kolaborasi

Dalam hal proses Git, kolaborasi sering kali tentang alur kerja yang bercabang. Berpikir ke depan tentang bagaimana Anda akan menjalin pohon komit akan membantu Anda meminimalkan bug integrasi dan mendukung strategi manajemen rilis Anda.

Cabang Integrasi

Gunakan cabang integrasi dengan tim pengembangan perangkat lunak yang bekerja untuk menyebarkan kumpulan kontribusi ke dalam produksi sebagai satu kesatuan. Ini bertentangan dengan tim yang fokus pada penerapan fitur secara individual. Seringkali tim mungkin ingin melakukan yang terakhir tetapi batasan praktis memaksakan proses yang mengelompokkan upaya mereka, dan tim akhirnya melakukan yang pertama, jadi pastikan untuk meninjau penggunaan Git Anda yang sebenarnya untuk melihat apakah Anda akan mendapat manfaat dari penggunaan jenis kolaborasi ini pola.

Pola alur kerja ini merupakan titik awal yang berguna ketika risiko integrasi beberapa cabang cukup tinggi untuk menjamin pengujian kontribusi gabungan secara keseluruhan.

Cabang integrasi biasanya terdiri dari fitur utama dan beberapa kontribusi yang lebih kecil untuk digunakan bersama-sama. Masukkan cabang integrasi melalui proses tim pengembangan Anda (T&J dan pengujian penerimaan, misalnya). Dorong komit minor ke dalamnya untuk membuatnya mendekati siap produksi, dan kemudian gunakan cabang lingkungan atau cabang rilis (dibahas di bawah) untuk mempersiapkannya untuk penerapan.

Ketahuilah bahwa kontribusi pada cabang integrasi perlu digabungkan ke tahap rilis berikutnya sebelum fitur utama lainnya dapat digabungkan ke dalam cabang integrasi - jika tidak, Anda menggabungkan fitur pada tahap penyelesaian yang berbeda. Ini akan menghambat kemampuan Anda untuk melepaskan apa yang sudah siap.

Cabang Topik

Tim akan ingin menggunakan cabang topik jika penting untuk menjaga pohon komit mereka dalam keadaan yang dapat dengan mudah dibaca atau fitur individual dikembalikan. Cabang topik menandakan bahwa komit dapat ditimpa (menggunakan dorongan paksa) untuk membersihkan strukturnya dan menyusut menjadi komit fitur.

Cabang topik sering dimiliki oleh kontributor individu tetapi juga dapat menjadi ruang khusus bagi tim untuk mengembangkan fitur. Kontributor lain mengetahui bahwa cabang jenis ini dapat membuat pohon komitnya ditulis ulang setiap saat, dan tidak boleh mencoba untuk menjaga agar cabang lokal mereka tetap sinkron dengannya.

Tanpa menggunakan cabang topik dalam alur kerja Git Anda, Anda dibatasi untuk tetap berpegang pada komitmen yang Anda dorong ke cabang jarak jauh. Memaksa mendorong pohon komit baru ke cabang jarak jauh dapat membuat marah kontributor lain yang mengandalkan integritas terpelihara dari cabang yang mereka sinkronkan.

Kemungkinannya adalah Anda sudah menggunakan pola alur kerja ini tanpa menyadarinya, tetapi ada baiknya memiliki seperangkat definisi bersama di antara tim untuk memperkuat praktik di baliknya. Misalnya, Anda mungkin menemukan konvensi awalan nama cabang dengan inisial pembuat cabang membantu memberi sinyal yang merupakan cabang topik. Bagaimanapun, terserah pada tim Anda untuk memutuskan konvensi internal.

JANGAN gunakan cabang topik pada repositori publik, Anda menyebabkan banyak konflik bagi siapa saja yang telah menyinkronkan cabang lokal mereka dengan cabang topik yang pohon komitnya telah ditulis ulang.

Garpu

Proyek sumber terbuka berkembang pesat menggunakan fitur yang berasal dari Github ini. Garpu memberdayakan pengelola repositori dengan gateway yang dipaksakan untuk mendorong langsung ke cabang repositori Asal, tetapi yang lebih penting memfasilitasi kolaborasi. Wah!

Anda mungkin menemukan diri Anda dalam skenario di mana membuat garpu dari repositori pribadi juga sesuai dengan kebutuhan Anda. Menyetel repositori Origin ke read-only untuk kontributor repositori fork dan menggulirkan dengan pull request memberi Anda manfaat yang sama seperti yang dialami komunitas open source. Tim dari organisasi yang berbeda dapat bekerja secara efektif menggunakan garpu yang dapat menjadi platform untuk komunikasi dan kepatuhan kebijakan proyek.

Pola alur kerja garpu memberi tim ruang mereka sendiri untuk bekerja dengan cara apa pun yang biasa mereka lakukan dengan satu titik integrasi antara dua repositori - permintaan tarik. Komunikasi yang berlebihan sangat penting dalam deskripsi permintaan tarik. Tim memiliki aliran komunikasi terpisah sebelum permintaan penarikan dikeluarkan, dan menyoroti keputusan yang telah dibuat akan mempercepat proses peninjauan.

Tentu saja salah satu manfaat dari alur kerja fork adalah Anda dapat mengarahkan komentar ke kontributor repositori asal, saat izin mengalir ke bawah. Dari sudut pandang repositori asal, Anda memiliki kontrol untuk menghapus garpu saat tidak lagi diperlukan.

Pastikan Anda menggunakan alat yang memfasilitasi permintaan forking dan pull untuk memanfaatkan pola ini. Alat-alat ini tidak terbatas pada Github: pilihan populer lainnya adalah Bitbucket dan GitlLab. Tetapi ada beberapa layanan hosting alur kerja Git lain yang akan memiliki fitur ini (atau serupa). Pilih layanan mana yang paling cocok untuk Anda.

JANGAN gunakan garpu repositori pribadi untuk setiap anggota tim. Banyaknya repositori bercabang dapat mempersulit banyak anggota untuk berkolaborasi pada cabang fitur yang sama, dan menjaga semua repositori ini tetap sinkron dapat menjadi rawan kesalahan karena banyaknya bagian yang bergerak. Proyek sumber terbuka memiliki anggota tim inti dengan akses push ke repositori asal yang mengurangi overhead ini.

Klon

Strategi outsourcing yang umum adalah memiliki “kursi” kontribusi pada proyek yang dapat diisi oleh banyak pengembang perangkat lunak. Terserah perusahaan outsourcing untuk mengelola saluran sumber daya mereka untuk memberikan jam kontrak, masalah yang mereka hadapi adalah bagaimana on-board, melatih dan memelihara kumpulan pengembang mereka untuk setiap proyek klien.

Menggunakan tiruan dari repositori proyek memberikan landasan pelatihan dan komunikasi yang terisolasi bagi tim outsourcing untuk mengelola kontribusi mereka, menegakkan kebijakan, dan memanfaatkan berbagi pengetahuan - semuanya dari pengawasan tim pengembangan klien. Setelah kontribusi dianggap memenuhi standar dan siap untuk repositori utama, itu dapat didorong ke salah satu cabang jarak jauh repositori asal dan terintegrasi seperti biasa.

Beberapa proyek memiliki harapan yang tinggi untuk mengikuti konvensi pengkodean mereka dan menetapkan standar alur kerja Git untuk berkontribusi pada repositori mereka. Bekerja di lingkungan ini bisa jadi menakutkan sampai Anda mempelajari seluk beluknya, jadi bekerjalah bersama sebagai tim untuk mengoptimalkan waktu kedua belah pihak.

JANGAN membuat salinan repositori klien yang dihosting tanpa izin mereka, Anda dapat melanggar perjanjian kontrak, verifikasi di muka bahwa praktik ini akan menguntungkan proyek dengan klien.

Manajemen Rilis

Langkah-langkah antara beralih dari kolaborasi ke rilis akan dimulai pada titik yang berbeda dalam proses pengembangan untuk setiap tim. Umumnya, Anda tidak ingin menggunakan lebih dari satu pola Git manajemen rilis. Anda ingin memiliki alur kerja sesederhana mungkin yang akan memungkinkan tim Anda untuk memberikan secara efektif.

Cabang Lingkungan

Proses pengembangan perangkat lunak Anda mungkin didukung oleh beberapa lingkungan untuk membantu dengan jaminan kualitas sebelum digunakan ke dalam produksi. Cabang lingkungan meniru tahapan proses ini: setiap tahap sesuai dengan cabang, dan kontribusi mengalir melalui ini dalam pipa.

Tim yang berjalan dengan proses ini sering kali memiliki lingkungan aplikasi yang disiapkan untuk setiap tahap dalam pipeline, misalnya “QA”, “Staging”, dan “Produksi”. Dalam kasus ini, infrastruktur tersedia untuk mendukung personel yang bertanggung jawab untuk menandatangani fitur atau kontribusi untuk bagian mereka tentang apa artinya siap produksi (misalnya pengujian eksplorasi, QA, pengujian penerimaan), sebelum memindahkannya ke orang berikutnya. panggung. Ini memberi mereka tempat mereka sendiri untuk menerapkan, menguji, dan mengevaluasi terhadap persyaratan mereka, dengan alur kerja Git untuk merekam perjalanannya melalui terowongan sign-off.

Memiliki cabang untuk setiap tahap proses tidak masalah untuk tim kecil yang dapat bekerja menuju rilis sebagai satu unit. Sayangnya, saluran pipa seperti ini dapat dengan mudah menghambat atau menumpuk dan meninggalkan celah. Ini menggabungkan proses Git Anda ke infrastruktur Anda yang dapat menyebabkan masalah saat fitur menuntut peningkatan dan kedua proses perlu ditingkatkan.

JANGAN gunakan pola ini tanpa mempertimbangkan manfaat jangka panjang dari pola lain terlebih dahulu.

Cabang Rilis

Sebuah tim yang mendorong kumpulan kontribusi ke aplikasi produksi mereka sebagai unit dalam sprint berturut-turut dapat menemukan cabang rilis yang cocok.

Kumpulan komit yang hampir "siap produksi" diberikan perbaikan bug kecil pada cabang rilis. Gunakan cabang integrasi untuk menggabungkan dan menguji fitur sebelum memindahkan pohon komitnya ke cabang rilis. Batasi tanggung jawab cabang rilis menjadi pemeriksaan terakhir sebelum penerapan ke aplikasi produksi.

Cabang rilis berbeda dari cabang lingkungan karena mereka memiliki umur yang pendek. Cabang rilis dibuat hanya saat dibutuhkan dan dihancurkan setelah pohon komitnya diterapkan ke dalam produksi.

Cobalah untuk mencegah penggabungan cabang rilis ke peta jalan pengembangan perangkat lunak Anda. Membatasi diri Anda untuk mengikuti rencana yang telah ditentukan akan menunda penerapan rilis hingga semua fitur yang direncanakan siap produksi. Tidak menetapkan nomor versi ke peta jalan sebelum membuat cabang rilis dapat mengurangi jenis penundaan ini, dengan mengizinkan fitur yang siap produksi untuk dimasukkan ke cabang rilis dan disebarkan.

Gunakan konvensi penamaan nomor versi untuk nama cabang rilis untuk memperjelas versi repositori yang telah digunakan ke dalam produksi.

Terapkan cabang master dan bukan cabang rilis. Untuk mendorong pembuatan perbaikan kecil pada cabang rilis sebelum bergabung dengan cabang master, gunakan pengait Git pada cabang master untuk memicu setelah penggabungan terjadi untuk secara otomatis menerapkan pohon komit yang diperbarui ke dalam produksi.

Mengizinkan hanya satu cabang rilis yang ada pada saat tertentu memastikan Anda akan menghindari overhead menjaga beberapa cabang rilis sinkron satu sama lain.

JANGAN gunakan cabang rilis dengan banyak tim yang bekerja di repositori yang sama. Meskipun cabang rilis berumur pendek, jika pemeriksaan akhir memakan waktu terlalu lama maka itu akan menahan tim lain untuk melepaskannya. Dukungan tim pada cabang rilis tim lain kemungkinan akan menimbulkan bug dan menyebabkan penundaan bagi kedua tim. Lihat pola rilis berstempel waktu di bawah ini, yang berfungsi lebih baik untuk jumlah dan grup kontributor yang lebih besar.

Rilis dengan stempel waktu

Aplikasi dengan batasan infrastruktur biasanya menjadwalkan penerapannya selama periode lalu lintas rendah. Jika proyek Anda dihadapkan dengan antrean reguler fitur yang siap digunakan, maka Anda dapat mengambil manfaat dari penggunaan rilis berstempel waktu .

Rilis stempel waktu bergantung pada proses penerapan untuk secara otomatis menambahkan tag stempel waktu ke komit terakhir di cabang master yang diterapkan ke produksi. Cabang topik digunakan untuk menempatkan fitur melalui proses pengembangan sebelum digabungkan ke dalam cabang master untuk menunggu penerapan.

Tag stempel waktu harus menyertakan stempel waktu aktual dan label untuk menunjukkan bahwa itu mewakili penerapan, misalnya: deployed-201402121345 .

Menyertakan meta-data penerapan, dalam bentuk tag stempel waktu di dalam pohon komit dari cabang master, akan membantu Anda dalam men-debug regresi yang dirilis ke dalam aplikasi produksi. Orang yang ditugasi memburu penyebab masalah tidak mungkin tahu banyak tentang setiap lini yang disebarkan ke dalam aplikasi produksi. Menjalankan perintah git diff pada dua tag terakhir dapat dengan cepat memberikan gambaran tentang komit apa yang terakhir digunakan dan siapa pembuat komit yang dapat membantu menyelesaikan masalah.

Cabang-cabang yang diberi cap waktu lebih banyak daripada yang terlihat di permukaan. Mekanisme sederhana untuk merekam penerapan fitur antrian memerlukan sejumlah proses bagus yang mengejutkan untuk menjalankannya. Prosesnya adalah salah satu yang dapat menskalakan dan bekerja dengan baik dengan tim kecil kontributor juga.

Agar pola alur kerja Git ini benar-benar efektif, diperlukan cabang master untuk selalu dapat digunakan. Itu bisa berarti hal yang berbeda untuk tim Anda, tetapi pada dasarnya semua komitmen harus melalui proses pengembangan proyek Anda sebelum berakhir di cabang master.

Komit baru yang mendarat di cabang master akan terjadi beberapa kali sehari. Ini adalah masalah untuk cabang topik yang telah melalui proses pengembangan dan belum disinkronkan dengan cabang master selama ini. Sayangnya skenario seperti itu dapat menyebabkan regresi ke cabang master ketika konflik gabungan ditangani secara tidak benar.

Jika konflik penggabungan muncul antara cabang topik dan cabang master, maka risiko munculnya bug baru harus didiskusikan dengan tim Anda sebelum memperbarui cabang master jarak jauh. Jika ada keraguan bahwa regresi dapat terjadi maka cabang topik dapat dimasukkan kembali melalui proses jaminan kualitas dengan konflik penggabungan diselesaikan.

Untuk mengurangi bug integrasi, pengembang yang mengerjakan bagian terkait dari repositori dapat berkolaborasi pada saat terbaik untuk menggabungkan dan menyinkronkan cabang topik mereka dengan cabang master. Cabang integrasi bekerja dengan baik untuk menyelesaikan konflik dari cabang topik terkait juga - ini harus melalui proses pengujian sebelum digabungkan ke dalam antrian di cabang utama yang menunggu penyebaran.

Proyek pengembangan perangkat lunak dengan banyak kontributor harus berurusan dengan kolaborasi dan proses manajemen rilis dengan pendekatan praktis dan efisien. Meta-data tambahan pada pohon komit yang kami peroleh dari penggunaan rilis berstempel waktu adalah petunjuk ke masa depan tim yang bersiap untuk menanggapi masalah produksi.

Cabang Versi

Jika Anda memiliki repositori yang tidak hanya dijalankan dalam produksi tetapi digunakan oleh orang lain untuk aplikasi yang dihostingnya sendiri, maka menggunakan cabang versi dapat memberi tim Anda platform untuk mendukung pengguna yang tidak, atau tidak dapat, tetap berada di ujung tombak pengembangan aplikasi Anda .

Repositori yang menggunakan cabang versi akan memiliki satu cabang per versi minor aplikasi. Versi mayor, minor, dan patch dijelaskan dalam dokumentasi Versi Semantik. Cabang versi biasanya mengikuti konvensi penamaan untuk memasukkan kata "stabil" dan menghapus nomor tambalan dari versi aplikasi: misalnya 2-3-stable untuk membuat tujuan dan keandalannya jelas bagi pengguna akhir.

Tag Git dapat diterapkan ke nomor versi patch aplikasi, tetapi cabang versi tidak terlalu halus. Cabang versi akan selalu menunjuk ke komit paling stabil untuk versi minor yang didukung.

Saat patch keamanan atau kebutuhan untuk mendukung fungsionalitas backport muncul, kumpulkan komit yang diperlukan untuk bekerja untuk versi aplikasi lama yang Anda dukung, dan dorong mereka ke cabang versi Anda masing-masing.

JANGAN gunakan cabang versi kecuali Anda mendukung lebih dari satu versi repositori Anda.

Ringkasan

Saat tim Anda berubah ukuran, atau proyek Anda mengembangkan prosesnya melalui evaluasi berkelanjutan, jangan tinggalkan evaluasi proses Git Anda juga. Gunakan pola dalam tutorial ini sebagai titik awal untuk membantu mengarahkan Anda ke jalur kebenaran alur kerja Git.

Pola dalam panduan ini dapat membantu membekali Anda dengan beberapa pandangan ke depan dalam mengadaptasi sistem kontrol versi terdistribusi agar berfungsi untuk Anda. Jika Anda ingin membaca tentang alur kerja Git, pastikan untuk memeriksa Gitflow, Github Flow, dan yang terpenting dokumentasi git-scm yang menakjubkan!