Alur Kerja & Penggunaan Git Tingkat Lanjut

Baru-baru ini kami melihat dasar-dasar untuk mulai menggunakan Git untuk kontrol sumber di proyek Anda. Meskipun itu adalah titik awal yang bagus, ada banyak perintah lain dan alur kerja Git yang akan membantu Anda memahami penggunaan Git dalam pekerjaan pengkodean harian Anda.

Alur Kerja Git

Ketika saya mulai menggunakan Git, saya pikir saya tahu cara menggunakannya dengan benar. Pendekatan ideal saya adalah membuat semua perubahan di satu tempat tanpa cabang dan kemudian mengkomitnya ke repositori dan terus bekerja.

Meskipun lebih baik daripada tidak menggunakan kontrol versi, saya perlu beberapa saat untuk menyadari bahwa saya tidak menggunakan sebagian besar kekuatan yang disediakan Git. Agar Git berfungsi untuk saya, saya perlu memiliki strategi untuk bercabang dan menggabungkan perubahan saya.

Kemudian git-flow keluar dan saya mengadopsinya sebagai strategi saya. Saya masih ingat merasa seperti sedang mengintip di balik tirai ke tempat para pengembang luar biasa berada. Saya sekarang memiliki wawasan tentang bagaimana mereka bekerja dan bisa mulai menjadi salah satu dari mereka.

Tetapi git-flow tidak cocok untuk setiap skenario, jadi sementara kita akan melihatnya, kita juga akan melihat beberapa metode lain untuk menjaga agar proyek Git Anda tetap teratur termasuk bagaimana saya mengelola proyek saya sebagai pengembang tunggal.

aliran git

Melihat git-flow sekarang, saya mengakui bahwa lanskap perangkat lunak telah banyak berubah dalam 10 tahun dan git-flow mungkin bukan pilihan terbaik untuk tim Anda. Ketika git-flow ditulis, jarang sekali men-deploy aplikasi berkali-kali dalam sehari. Sebagai gantinya, Anda mungkin melakukan nomor versi utama dan merilisnya setiap beberapa bulan atau minggu jika Anda berada di tim yang sangat gesit.

Mari kita lihat apa itu git-flow.

Jika Anda ingin melihat penjelasan mendalam lengkap dengan grafik dan perintah Git untuk Git Flow, Anda harus membaca posting ini.

Dalam git-flow, dua cabang memiliki masa hidup yang tak terbatas. Pertama, main yang harus mencerminkan kode yang siap di-deploy ke lingkungan live/produksi Anda.

Kedua, kami memiliki cabang pengembangan kami. Cabang ini harus memiliki perubahan terbaru yang siap untuk rilis berikutnya dari perangkat lunak kami. Ketika perubahan dalam pengembangan siap untuk diterapkan ke aplikasi langsung kami, kami menggabungkannya ke cabang utama dan menandainya dengan nomor versi yang sesuai dengan nomor rilis.

Di luar dua cabang utama, ada tiga jenis cabang pendukung.

1. Fitur

Cabang fitur hanya dapat dibuat dari cabang pengembangan. Itu harus digabung kembali ke cabang pengembangan. Penamaan dapat berupa apa saja yang menggambarkan fitur yang sedang Anda kerjakan.

Ketika pekerjaan siap untuk rilis berikutnya, itu akan digabungkan kembali ke cabang pengembangan tempat menunggu waktu rilis.

2. Lepaskan

Cabang rilis dibuat dari cabang develop dan harus digabung kembali menjadi develop dan main. Anda memberi nama cabang rilis dengan konvensi release-x. Dalam praktiknya itu biasanya berarti Anda akan memberi nama cabang dengan nomor rilis yang Anda rencanakan untuk digunakan seperti ini: release-2.2

Anda menggunakan cabang rilis sebagai cara untuk melakukan persiapan akhir untuk merilis perangkat lunak Anda. Ini mungkin termasuk menabrak nomor versi file, memastikan terjemahan Anda selesai, atau pemeriksaan kode akhir.

3. Perbaikan terbaru

Cabang hotfix dibuat dari cabang utama dan digunakan untuk memuat perubahan yang perlu segera ditangani dalam aplikasi langsung. Ini mungkin bug yang harus diperbaiki atau masalah keamanan yang perlu ditangani.

Setelah masalah diperbaiki dan disebarkan ke cabang utama Anda, Anda akan menandai kode Anda dengan nomor versi yang tepat.

Alasan terbesar mengapa tim tidak menggunakan git-flow sekarang adalah cara kami merilis perangkat lunak telah berubah. Alih-alih rilis yang lebih besar lebih jarang, Anda dapat merilis perubahan ke aplikasi beberapa kali dalam sehari. Saya tahu bahwa saya mendorong pekerjaan ke situs klien saya beberapa kali seminggu segera setelah itu siap. Kami tidak melakukan nomor versi situs, kami hanya terus meningkatkannya.

Aliran git standar tidak dimaksudkan untuk mengakomodasi ini.

Aliran Github

Opsi kedua yang banyak digunakan orang adalah Github Flow.

Satu aturan besar Github Flow adalah bahwa kode apa pun yang ada di cabang utama dapat digunakan kapan saja karena sudah siap produksi.

Semua cabang dibuat dari cabang utama dengan nama deskriptif untuk apa pun yang Anda lakukan.

Setelah perubahan Anda siap, Anda membuat permintaan tarik.

Permintaan tarik memberi tahu orang lain yang mengerjakan kode yang sama bahwa pekerjaan yang Anda lakukan siap untuk ditinjau sebelum perubahan tersebut digabungkan ke dalam kode utama.

Setelah Anda mengirimkan pull request, tim yang bekerja sama dengan Anda dapat meninjau perubahan dan memberikan umpan balik. Jika permintaan tarik dianggap siap untuk digabungkan, maka permintaan tersebut akan digabungkan ke dalam cabang utama untuk proyek Anda.

Satu kelemahan aliran Github untuk pengembang tunggal atau tim yang sangat kecil adalah bahwa administrasi permintaan tarik dapat membuat overhead tambahan dalam mengelola proyek. Inilah sebabnya saya tidak menggunakannya dalam pekerjaan saya.

Bagaimana Saya Menggunakan Alur Kerja Git dengan Proyek Klien

Dalam pekerjaan klien saya, saya biasanya satu-satunya yang menulis kode setiap hari untuk sebuah proyek. Klien saya mungkin memperbarui plugin WordPress atau mengubah beberapa CSS, tetapi mereka tidak melakukan pekerjaan pengkodean utama. Itu berarti jika saya menggunakan aliran Github, saya akan meninjau permintaan tarik saya yang hanya membuat sakit kepala manajemen tambahan. Mari kita lihat sistem yang saya gunakan, yang memiliki kemiripan dengan aliran git dan aliran Github.

Saya memiliki dua cabang utama yang disebut utama dan pementasan. Cabang utama melacak dengan kode apa pun yang sedang berjalan di lokasi produksi. Cabang pementasan melacak dengan apa pun yang sedang diuji di situs pementasan yang kami gunakan untuk menguji perubahan sebelum kami mendorongnya ke situs langsung.

Setiap cabang dibuat dari cabang utama. Fitur baru diberi nama seperti ini: feature/32-new-feature. Dalam konteks ini, nomor 32 sesuai dengan nomor tiket dalam sistem manajemen proyek kami dan kata-kata setelahnya adalah deskripsi singkat tentang apa yang sedang dikerjakan. Perbaikan bug diberi nama yang sama, bug/20-bug-name.

Setiap cabang yang dibuat akan digabung ke dalam cabang pementasan kami terlebih dahulu, dan kemudian setelah disetujui oleh klien atau diuji sendiri akan digabungkan ke dalam cabang master. Alur kerja itu mungkin terlihat seperti ini.

# gabungkan fitur ke dalam cabang pementasan

git merge fitur/32-fitur baru

# menyebarkan dan menguji fitur

git checkout utama

git merge fitur/32-fitur baru

# menyebarkan fitur ke situs langsung

Dalam proyek saya, saya memiliki pengaturan penyebaran berkelanjutan yang berarti setiap kali saya mendorong kode ke main, itu akan didorong ke situs langsung secara otomatis. Proses yang sama diatur untuk cabang pementasan.

Jika saya bekerja dengan tim yang dapat memeriksa kode saya dalam alur kerja permintaan tarik, maka saya akan menggunakan sistem ini karena bekerja dengan baik dalam tim. Untuk pengembang yang sebagian besar bekerja sendiri, hanya overhead manajemen yang akan memperlambat alur kerja Anda.

Perintah Git Tingkat Lanjut yang Saya Gunakan

Sekarang setelah kita memiliki beberapa gagasan tentang bagaimana kita dapat menggunakan Git dalam alur kerja praktis, mari kita lihat perintah lanjutan yang diperlukan untuk mewujudkannya. Saya menggunakan masing-masing perintah ini setidaknya beberapa kali seminggu saat saya bekerja dengan kode pelanggan saya.

Bahkan jika Anda akan menggunakan aplikasi GUI, (saya menyebutkan beberapa yang bagus di posting terakhir saya di Git), tetap penting untuk memiliki pemahaman tentang apa yang terjadi di latar belakang. Sering kali saya harus bekerja melalui terminal untuk memperbaiki masalah yang dibuat oleh aplikasi Git GUI.

Menambahkan Perubahan berdasarkan Baris

Satu perintah yang membuat penggunaan Git melalui klik Terminal untuk saya adalah git add -p. Sampai saya mempelajari perintah ini, saya menggunakan aplikasi GUI karena saya akan membuat perubahan pada kode saya tetapi ingin memecah baris tertentu menjadi beberapa komit sehingga saya dapat menjelaskan mengapa saya membuat perubahan. Untuk melakukan ini, saya menggunakan GUI untuk memilih baris, tetapi git add -p memandu Anda melalui antarmuka interaktif untuk menambahkan perubahan dalam potongan.

Saya menggunakan ini berkali-kali setiap hari.

Lacak Cabang Git Jarak Jauh

Jika Anda menarik ke bawah repositori yang ada dan memiliki cabang seperti main dan staging yang perlu Anda lacak tetapi sudah ada, Anda perlu memberi tahu versi lokal cabang Anda untuk melacak versi cabang jarak jauh tersebut.

Ada beberapa cara untuk melakukan ini.

# Atur hulu saat mendorong ke jarak jauh

git push -u asal pementasan

# Atur hulu

# mengasumsikan Anda berada di cabang yang ingin Anda lacak saat ini dengan remote

git branch -u Asal/pementasan

git branch --set-upstream-to=origin/staging

# Jika Anda tidak berada di cabang yang ingin Anda lacak, maka tentukan cabang di akhir

git branch --set-upstream-to=asal/pementasan pementasan

Simpan Perubahan tanpa Melakukannya

Terkadang Anda akan berada di tengah beberapa pekerjaan yang belum siap untuk dilakukan, tetapi Anda perlu menyimpan statusnya. Di situlah git stash berguna. Perintah ini menyimpan perubahan untuk Anda dengan menghapus perubahan. Anda bisa mendapatkannya kembali dengan menggunakan git stash pop. Ada beberapa perintah lagi untuk membuat simpanan berguna, tetapi itu adalah dua yang saya gunakan secara teratur.

Tarik Komitmen Git Tertentu

Terkadang Anda perlu menarik komit tertentu ke dalam pekerjaan Anda saat ini. Dengan HEAD yang bersih (Anda belum membuat perubahan apa pun), Anda dapat menarik komit tertentu dengan git cherry-pick . Anda dapat menemukan dokumentasi lengkap di git cherry-pick di sini.

Untuk setiap komit, Git membangun urutan huruf dan angka yang panjang yang disebut Objek Git, dan biasanya disebut sebagai SHA. Karena setiap komit mendapatkan satu, Anda dapat mereferensikan komit dengan nilai SHA-nya. Baca lebih lanjut tentang Objek Git.

Buang Perubahan yang Tidak Anda Butuhkan

Pada titik tertentu dalam proyek apa pun, kami akan membuat perubahan dan kemudian menyadari bahwa itu tidak berfungsi dan kami hanya perlu menghapusnya dan memulai dari awal. Alih-alih hanya mencoba membatalkan sampai kita kembali ke tempat yang kita inginkan, kita dapat menggunakan perintah Git berikut untuk menghapus perubahan apa pun yang belum dilacak.

git reset --hard

Perintah di atas akan mengatur ulang kode Anda kembali ke komit terbaru di cabang yang sedang Anda kerjakan. Kami juga dapat menggunakan <#commitSHA> dengan perintah ini untuk mengatur ulang ke komit tertentu jika kami ingin kembali ke keadaan sebelum komit terbaru. Mungkin Anda akan menggunakan ini untuk mengatur ulang ke checkout cabang awal karena seluruh nilai pekerjaan cabang bukanlah sesuatu yang ingin Anda simpan, tetapi Anda telah melacak beberapa pekerjaan.

Untuk melangkah lebih jauh, kita dapat membuang file atau direktori yang belum dilacak di git dengan perintah git clean.

git clean -fd: flag f dan d memberi tahu git untuk membuang file dan direktori yang tidak terlacak.

Hapus Cabang

Setiap satu atau dua minggu saya melihat hasil dari perintah git status dan menemukan bahwa saya memiliki terlalu banyak cabang untuk cukup memahami apa yang terjadi di repositori saya. Itu berarti saya dapat menghapus cabang apa pun yang sesuai dengan tiket yang telah diselesaikan dengan perintah berikut.

# menghapus versi lokal

git branch -d $branchname

#menghapus cabang di remote saya

git Push $remotename --delete $branchname

Gunakan Kontrol Versi

Meskipun Anda mungkin bukan ahli dalam semua perintah Git yang akan Anda gunakan, satu hal penting untuk diingat adalah Anda harus menggunakan version control . Bahkan jika Anda satu-satunya orang yang mengerjakan proyek, menggunakan Git dan alur kerja Git akan membantu Anda menjaga proyek tetap teratur. Anda tidak perlu menekan CTRL + Z sampai Anda mengatur ulang pekerjaan Anda setelah menulis kode yang tidak berhasil.

Anda akan dapat mempercayai sistem Anda dan terus menghasilkan pekerjaan untuk proyek Anda.

Coba Hosting WordPress Terkelola Sepenuhnya

Butuh hosting yang dioptimalkan untuk WordPress? Lihat paket hosting WordPress yang dikelola sepenuhnya oleh Nexcess hari ini.