Bagaimana git biasanya digunakan? Sepasang perintah dasar untuk " menyinkronkan semua orang ." Git frustrasi sering muncul di antara mereka yang tidak pernah melampaui pemahaman dangkal ini. Namun, menguasai git pasti akan memberikan hasil. Berapa banyak waktu yang Anda habiskan menggunakan git? Saya akan menyarankan bahwa pada ikat pinggang Anda ada banyak alat yang Anda gunakan setengah sering dan menghabiskan dua kali lebih banyak waktu belajar.



Jika Anda ingin mempelajari lebih lanjut tentang git, saya sarankan mulai dengan bab 10 dari Pro Git (gratis!), Kemudian bab 2, 3, dan 7. Selebihnya adalah opsional. Dalam artikel ini, kita akan membahas cara menggunakan alat yang dijelaskan dalam buku ini untuk pekerjaan yang disiplin dan produktif di git.

Dasar-dasar: deskripsi komit yang baik

Anda mungkin pernah mendengar ini sebelumnya, tetapi bersabarlah. Secara umum, Anda tidak perlu menggunakan git commit -m " " . git commit -m " " Mulailah dengan mengkonfigurasi git untuk menggunakan editor favorit Anda: git config --global core.editor vim , kemudian jalankan git commit . Editor akan terbuka, dan Anda dapat menulis deskripsi komit di dalamnya. Baris pertama harus dibatasi hingga 50 karakter dan dilengkapi dengan kalimat: setelah menerapkan komit ini ... "akan memperbaiki rendering teks dalam bahasa CJK", "akan menambahkan dukungan untuk protokol v3", "akan memperbaiki pemrosesan CRTC", dll. Kemudian tambahkan satu baris kosong dan lanjutkan ke deskripsi panjang dari komit , yang harus dikodekan ke dalam 72 kolom dan termasuk rincian seperti pembenaran komit, pertukaran, pembatasan pendekatan, dll.

Kami menggunakan 72 karakter karena ini adalah lebar standar dari pesan email , dan email adalah alat penting untuk git. Batas 50 karakter digunakan karena baris pertama menjadi subjek email Anda, dan Anda dapat menambahkan banyak teks seperti “[PATCH linux-usb v2 0/13]” . Anda mungkin menemukan bahwa pembatasan format ini menjengkelkan dan memberatkan, tetapi perlu diingat bahwa orang lain membaca log dalam konteks yang berbeda dari Anda. Saya sering membaca log komit pada monitor vertikal, dan itu tidak akan memeras teks menjadi satu baris seperti tampilan 4K 16: 9 Anda.

Setiap komit harus merupakan perubahan otonom

Setiap komit hanya boleh berisi satu perubahan - hindari perubahan kecil yang tidak terkait dalam satu komit (dalam hal ini, saya bisa lebih sering mendengarkan tips saya sendiri). Selain itu, hindari memecah satu perubahan menjadi beberapa komit, kecuali jika idenya dipecah menjadi langkah-langkah terpisah, yang masing-masing mewakili perubahan lengkap. Jika ada beberapa perubahan di pohon kerja Anda dan Anda hanya perlu mengkomit beberapa di antaranya, coba git add -i atau git add -p . Selain itu, setiap komit harus dikompilasi, berhasil lulus semua tes, dan menghindari bug yang diketahui yang akan diperbaiki dalam komitmen di masa mendatang.

Sekarang Anda dapat menerima komit apa pun dan berharap kode akan berfungsi dengan benar. Ini akan berguna nanti, misalnya, selama inklusi komit selektif dalam cabang rilis. Pendekatan ini juga meningkatkan kegunaan git-bisect ¹ , karena jika Anda mengharapkan kode untuk mengkompilasi dan lulus tes untuk setiap komit berhasil, maka Anda dapat melewati skrip git-bisect yang secara terprogram memeriksa pohon untuk kesalahan dan akan menghindari kesalahan positif. Komitmen yang berdiri sendiri dan dideskripsikan dengan baik ini akan menyederhanakan persiapan deskripsi rilis menggunakan git-shortlog , seperti yang dilakukan Linux dengan rilis Linux .

Sulit untuk melakukannya dengan benar pertama kali

Kami datang ke salah satu fitur git yang paling penting, yang membedakannya dari pendahulunya: mengedit cerita. Semua sistem kontrol versi hadir dengan semacam "mesin waktu", tetapi sebelumnya kebanyakan hanya baca-saja. Namun, mesin waktu git berbeda: Anda dapat mengubah masa lalu. Bahkan, Anda bahkan didorong untuk melakukan ini! Tapi saya memperingatkan Anda: hanya mengubah masa lalu, yang belum memasuki cabang publik yang stabil.

Intinya adalah sebagai berikut. Menulis komit tanpa kesalahan, komit otonom dengan deskripsi yang baik sulit pada percobaan pertama. Mengedit sebuah cerita, sebaliknya, mudah, dan itu adalah bagian dari alur kerja yang efisien git. Lihat git-rebase dan gunakan dengan bebas. Anda dapat menggunakan rebase untuk menyusun ulang, menggabungkan, menghapus, mengedit, dan membagi komit. Sebagai contoh, saya biasanya membuat beberapa perubahan pada file, mengirimkan komit fixup ( git commit -m fixup ), dan kemudian menggunakan git rebase -i untuk menggabungkannya ke komit sebelumnya.

Berbagai tips

• Baca mana! Pilih halaman manual git acak dan baca sekarang. Juga, jika Anda belum membaca halaman man git tingkat atas (hanya man git ), lakukan ini.
  
• Di bagian bawah setiap mana untuk perintah git level tinggi biasanya daftar perintah git level rendah yang diandalkan oleh perintah level tinggi. Jika Anda ingin mempelajari lebih lanjut tentang cara kerja perintah git tingkat tinggi, coba baca halaman manual ini.
  
• Pelajari cara memilih komit yang tepat dengan pilihan rev .
  
• Cabang berguna, tetapi Anda harus belajar bekerja tanpa mereka, dan juga memiliki seperangkat alat yang bagus di ikat pinggang Anda. Gunakan perintah seperti git pull --rebase , git send-email -1 HEAD~2 dan git push origin HEAD~2:master .

Singkatnya, git bisect adalah alat yang melakukan pencarian biner antara dua komit dalam sejarah Anda, melihat komit di antara mereka satu per satu sehingga Anda dapat memeriksa kesalahan. Dengan cara ini, Anda dapat menghitung komit yang menyebabkan masalah. ↑