27 tip penting untuk pengguna Git dan GitHub

Meskipun pengguna Git memiliki lusinan panduan memulai untuk dipilih, dan GitHub menawarkan sejumlah panduannya sendiri, masih tidak mudah untuk menemukan kumpulan tip berguna bagi pengembang yang ingin bekerja lebih cerdas dengan Git dan GitHub. Mari kita perbaiki itu.

Bagi Anda yang tidak terbiasa dengan Git atau GitHub, beberapa paragraf berikut akan memberi Anda latar belakang yang cukup untuk memahami tipnya. Kami akan membuat daftar sekitar selusin sumber daya berguna di akhir artikel ini.

Git adalah sistem kontrol versi terdistribusi, aslinya ditulis oleh Linus Torvalds pada tahun 2005 untuk dan dengan bantuan dari komunitas kernel Linux. Saya di sini bukan untuk menjual Anda di Git, jadi saya akan memberi Anda informasi tentang seberapa cepat dan kecil dan fleksibel dan populer itu, tetapi Anda harus tahu bahwa ketika Anda mengkloning repositori Git ("repo," singkatnya) , Anda mendapatkan seluruh riwayat versi di komputer Anda sendiri, bukan hanya cuplikan dari satu cabang pada satu waktu.

Git dimulai sebagai alat baris perintah, sesuai dengan asalnya di komunitas kernel Linux. Anda masih dapat menggunakan baris perintah Git, jika Anda mau, tetapi Anda tidak perlu melakukannya. Secara khusus, jika Anda menggunakan GitHub sebagai host, Anda dapat menggunakan klien GitHub Desktop gratis di Windows atau Mac. Di sisi lain, baris perintah Git akan berfungsi untuk semua host, dan sudah diinstal sebelumnya di sebagian besar sistem Mac dan Linux.

Hanya Anda yang dapat memutuskan apakah Anda merasa paling nyaman menggunakan baris perintah atau klien asli dengan antarmuka pengguna grafis. Jika Anda menyukai GUI, selain klien GitHub (Windows dan Mac), Anda mungkin ingin mempertimbangkan SourceTree (Windows dan Mac, gratis), TortoiseGit (hanya Windows, gratis), dan Gitbox (hanya Mac, $ 14,99). Atau Anda dapat menggunakan editor atau IDE yang mendukung Git secara internal (lihat tip No. 11).

Kiat Git / GitHub No. 1: Mengkloning hampir semua hal

Ada banyak proyek menarik yang tersedia dari GitHub dan repositori Git publik lainnya yang dapat Anda kloning secara bebas ke komputer Anda sendiri. Mengapa Anda ingin melakukan itu? Salah satu alasannya adalah untuk mempelajari sesuatu tentang gaya pengkodean, praktik, dan alat dalam bahasa yang diminati, termasuk gaya komentar log komit (lihat tip No. 4). Alasan kedua adalah mempelajari bagaimana proyek tertentu mencapai tujuannya. Alasan ketiga, jika lisensi mengizinkan Anda untuk melakukannya dan masuk akal untuk tujuan Anda, adalah untuk memasukkan proyek ke dalam usaha atau produk Anda sendiri. Ngomong-ngomong, periksa kembali lisensinya agar Anda tidak mengalami masalah kepatuhan di kemudian hari.

Definisi dari git clonehalaman manual:

Menggandakan repositori ke dalam direktori yang baru dibuat, membuat cabang pelacakan jarak jauh untuk setiap cabang di repositori yang digandakan (terlihat menggunakan git branch -r), dan membuat serta memeriksa cabang awal yang bercabang dari cabang repositori yang saat ini aktif digandakan.

Setelah penggandaan, dataran git fetchtanpa argumen akan memperbarui semua cabang pelacakan jarak jauh, dan git pullargumen tanpa tambahan akan menggabungkan cabang master jarak jauh ke dalam cabang master saat ini, jika ada.

Tip Git / GitHub No. 2: Tarik sesering mungkin

Salah satu cara termudah untuk mengacaukan diri Anda dengan Git (dan memang, dengan sistem kontrol versi apa pun) adalah dengan membiarkan file tidak sinkron. Jika git pullsering, Anda akan terus memperbarui salinan repo, dan Anda akan memiliki kesempatan untuk menggabungkan kode yang diubah dengan perubahan orang lain sementara penggabungan mudah dipahami dan diselesaikan — idealnya, jika sangat mudah sehingga bisa dilakukan secara otomatis. Konsekuensi dari tip ini adalah memperhatikan status proyek Anda. Banyak klien Git akan secara otomatis menunjukkan kepada Anda kapan Anda perlu memperbarui agar tetap terkini.

Kiat Git / GitHub No. 3: Berkomitmen sejak awal dan sering

Komit adalah pembaruan terperinci untuk proyek, yang mencakup satu atau beberapa perubahan pada satu atau lebih file. Anggap saja sebagai catatan unit pekerjaan yang diselesaikan, yang dapat diterapkan atau dihapus dari proyek sebagai keseluruhan yang logis. Lakukan setiap perubahan logis yang Anda selesaikan, bahkan sebelum mengujinya. Komit hanya berlaku untuk repositori lokal Anda. Lihat tips No. 4 dan 5 untuk konsekuensi wajar dari tip ini.

Definisi dari git commithalaman manual:

Menyimpan konten indeks saat ini di komit baru bersama dengan pesan log dari pengguna yang menjelaskan perubahan.

Tip Git / GitHub No. 4: Komentari komit Anda sebagaimana Anda ingin orang lain mengomentari komit mereka

Ada 10 jenis pembuat kode: Mereka yang mengomentari komitmen mereka, dan mereka yang tidak. (Lelucon lama. Petunjuk: Dasar apa yang saya gunakan?)

Saya dengan bebas mengakui menjadi patuh pada pesan log commit yang baik. Saya mengatur repositori saya untuk meminta pesan untuk setiap komit, dan saya diketahui sering mengirimkan pesan larut malam yang mengganggu ketika komit mendarat dengan log dengan urutan “xx”. Jika Anda adalah jenis pengembang yang berpikir (1) kode harus berbicara sendiri dan (2) komentar sebaris jauh lebih penting daripada log perubahan, coba kloning repositori yang belum pernah Anda lihat sebelumnya dan identifikasi komit terbaru yang mungkin menyebabkan masalah terbaru diposting tanpa membaca semua kode. Seperti yang Anda lihat, log komit yang akurat adalah dua kali lipat lebih bagus.

Kiat Git / GitHub No. 5: Dorong saat perubahan Anda diuji

Bug terburuk terkait Git yang pernah saya ketahui, terjadi ketika perusahaan outsourcing beralih dari Subversion tetapi tidak melatih pengembangnya tentang perbedaan antara kontrol sumber terdistribusi dan kontrol sumber terpusat. Sekitar sebulan kemudian, proyek tersebut mengembangkan bug aneh yang tampaknya tidak dapat dilacak oleh siapa pun. Pada rapat stand-up harian, pengembang yang bertanggung jawab atas area aplikasi yang berperilaku tidak semestinya akan memprotes, "Saya memperbaikinya dua minggu lalu!" atau menuduh pengembang lain tidak mau repot-repot menarik perubahan yang telah mereka periksa dengan cermat.

Akhirnya, seseorang mengidentifikasi masalah dan mengajari semua pengembang bagaimana dan kapan pushmelakukan komit: Singkatnya, setiap kali uji komit berhasil di build lokal. Kemudian perusahaan melakukan festival penggabungan selama dua hari sebelum dapat membangun dan menerapkan produk terintegrasi yang diperbarui.

Tip Git / GitHub No. 6: Bercabang dengan bebas

Salah satu keuntungan terbesar yang dimiliki Git dibandingkan beberapa sistem kontrol versi lainnya adalah bahwa penggabungan biasanya bekerja dengan baik, setidaknya sebagian karena Git secara otomatis memilih leluhur umum terbaik untuk digunakan untuk penggabungan. Sebagian besar pengembang perangkat lunak perlu lebih sering mulai membuat cabang di proyek mereka. Ini harus menjadi kejadian sehari-hari yang rutin, bukan subjek dari rapat strategi semua pihak yang menyedihkan. Kemungkinannya adalah, ketika proyek cabang selesai, diterima, dan siap untuk dipindahkan ke proyek utama, penggabungan tidak akan menimbulkan masalah yang tidak dapat diatasi.

Saya tahu itu membutuhkan beberapa penyesuaian, terutama jika Anda terjebak di perusahaan yang melakukan kontrol kode sumber dengan CVS. Tapi cobalah. Ini jauh lebih baik daripada meminta pelanggan secara tidak sengaja melihat kode eksperimental Anda yang belum selesai ketika proyek utama harus dipublikasikan karena bug yang merusak. (Artikel ini menjelaskan percabangan dasar dan penggabungan dengan baik.)

Tip Git / GitHub No. 7: Gabungkan dengan hati-hati

Meskipun menggabungkan dengan Git biasanya bekerja dengan baik, jika Anda melakukannya tanpa berpikir, terkadang Anda akan mengalami kesulitan. Langkah pertama adalah memastikan Anda tidak memiliki perubahan yang tidak terikat. Dari git mergehalaman manual:

Sebelum menerapkan perubahan luar, Anda harus mendapatkan pekerjaan Anda sendiri dalam kondisi yang baik dan berkomitmen secara lokal, sehingga tidak akan terhenti jika ada konflik. Lihat juga git-stash.

Lihat juga tip No. 8.

Bahkan jika semuanya pergi ke selatan selama a git merge, Anda tidak disemprot:

Jika Anda mencoba menggabungkan yang mengakibatkan konflik kompleks dan ingin memulai kembali, Anda dapat memulihkan dengan git merge —abort.

Perintah tindak lanjut ke git mergebiasanya git mergetool, dengan asumsi Anda suka menggunakan GUI untuk menggabungkan. Jika Anda lebih memilih metode lama-sekolah, Anda dapat mengedit file dalam konflik dengan editor pemrograman favorit Anda, sepenuhnya menghapus <<<<<<<, =======dan >>>>>>>garis-garis, menyimpan file direvisi, dan git addsetiap file Anda tetap.

Tips Git / GitHub No. 8: Simpan sebelum berpindah cabang

Alur kerja pengembang perangkat lunak jarang linier. Pengguna memiliki keberanian untuk melaporkan bug, manajer memiliki keberanian untuk memprioritaskan tiket selain yang Anda pilih untuk dikerjakan, dan Anda sendiri mungkin berubah pikiran tentang apa yang ingin Anda lakukan.

Itu dia, dengan tiga file berkomitmen untuk rilis, dan file keempat dalam keadaan berubah tetapi tidak berfungsi. ( git statusPerintah akan memberi tahu Anda semua ini jika Anda tidak ingat di mana Anda berada.) Tiba-tiba Anda perlu memperbaiki bug dalam versi produksi. Anda perlu beralih cabang segera, tetapi Anda tidak bisa. Direktori kerja Anda kotor dan Anda memiliki dua jam kerja yang tidak ingin hilang.

Masuk git stash. Voilà! Sekarang Anda memiliki semua perubahan yang disimpan di cabang WIP (sedang dalam proses), dan Anda dapat beralih ke cabang produksi dari direktori bersih Anda. Setelah selesai dengan itu, kembalilah ke tempat Anda sebelumnya git stash apply.

Kiat Git / GitHub No. 9: Gunakan inti untuk berbagi potongan dan pasta

GitHub "gists" —potongan kode bersama — bukanlah fitur Git, tetapi menggunakan Git. Semua inti adalah repositori Git, dan GitHub Gist memudahkan untuk membagikannya. Anda dapat mencari Intisari publik menurut topik, bahasa pemrograman, status bercabang, dan status berbintang. Anda juga dapat membuat inti rahasia dan membagikannya melalui URL.

Tips Git / GitHub No. 10: Jelajahi GitHub

Banyak proyek open source yang menarik memiliki repositori di GitHub. Jelajahi GitHub menyediakan antarmuka penjelajahan untuk menemukan beberapa di antaranya, tetapi sebagian besar lebih mudah untuk mengetik beberapa huruf nama proyek di kotak pencarian untuk menemukan reponya. Misalnya, ketik jqatau backatau anguntuk menemukan tiga kerangka kerja JavaScript sumber terbuka utama.

Tip Git / GitHub No. 11: Berkontribusi pada proyek open source

Selama Anda menjelajahi proyek sumber terbuka, mengapa tidak berkontribusi di dalamnya? Ini tidak sesulit yang Anda kira, dan Anda akan belajar banyak. Misalnya, Anda dapat mengkloning proyek jquery / jquery (jQuery Core), dan menelusuri README.MD. Di dekat bagian atas Anda akan melihat:

Dalam semangat pengembangan perangkat lunak open source, jQuery selalu mendorong kontribusi kode komunitas. Untuk membantu Anda memulai dan sebelum Anda mulai menulis kode, pastikan untuk membaca pedoman kontribusi penting ini secara menyeluruh ...

Itu diikuti oleh tiga tautan. Yang pertama dari ketiganya akan membantu Anda memulai dengan cukup cepat. Tidak semua proyek open source menjabarkan rencana dengan begitu jelas, tetapi mereka semua mencoba.

Pahami perbedaan antara menjadi kontributor dan pelaku. Seorang kontributor telah menandatangani perjanjian yang diperlukan dan memberikan kontribusi tersedia untuk proyek. Seorang pelaku committer diberdayakan untuk benar-benar mengkomit kontribusi yang ditawarkan ke repositori proyek. Karena akan ada penundaan ketika seorang pelaku melakukan tes kontribusi Anda dan Anda tidak ingin mengikat cabang master Anda, Anda harus membuat perubahan Anda di cabang lain (lihat tip No. 6) sebelum mengirimkan permintaan penarikan (lihat tip Tidak 16).