27 petua penting untuk pengguna Git dan GitHub

Walaupun pengguna Git mempunyai puluhan panduan permulaan untuk dipilih, dan GitHub menawarkan beberapa panduan sendiri, masih mudah untuk mencari koleksi petua berguna untuk pembangun yang ingin bekerja lebih pintar dengan Git dan GitHub. Mari betulkan.

Bagi anda yang tidak biasa dengan Git atau GitHub, beberapa perenggan seterusnya akan memberi anda latar belakang yang cukup untuk memahami petua. Kami akan menyenaraikan sekitar selusin sumber berguna di akhir artikel ini.

Git adalah sistem kawalan versi terdistribusi, yang awalnya ditulis oleh Linus Torvalds pada tahun 2005 untuk dan dengan bantuan dari komuniti kernel Linux. Saya tidak di sini untuk menjual anda di Git, jadi saya akan memberi anda maklumat tentang seberapa cepat dan kecil dan fleksibel dan popular, tetapi anda harus tahu bahawa apabila anda mengklon repositori Git ("repo", pendek) , anda mendapat keseluruhan sejarah versi di komputer anda sendiri, bukan hanya gambar dari satu cawangan dalam satu masa.

Git bermula sebagai alat baris perintah, sesuai dengan asalnya dalam komuniti kernel Linux. Anda masih boleh menggunakan baris perintah Git, jika anda mahu, tetapi anda tidak perlu. Khususnya, jika anda menggunakan GitHub sebagai hos anda, anda boleh menggunakan klien Desktop GitHub percuma pada Windows atau Mac. Sebaliknya, baris perintah Git akan berfungsi untuk mana-mana hos, dan ia dipasang terlebih dahulu pada kebanyakan sistem Mac dan Linux.

Hanya anda yang boleh menentukan sama ada anda paling selesa menggunakan baris perintah atau pelanggan asli dengan antara muka pengguna grafik. Sekiranya anda menyukai GUI, selain klien GitHub (Windows dan Mac), anda mungkin ingin mempertimbangkan SourceTree (Windows dan Mac, percuma), TortoiseGit (hanya Windows, percuma), dan Gitbox (Mac sahaja, $ 14,99). Atau anda boleh menggunakan editor atau IDE yang menyokong Git secara dalaman (lihat tip No. 11).

Petua Git / GitHub No. 1: Klon hampir semua perkara

Terdapat banyak projek menarik yang tersedia dari GitHub dan repositori Git awam lain yang boleh anda klon secara bebas ke komputer anda sendiri. Mengapa anda mahu berbuat demikian? Salah satu sebabnya adalah mempelajari sesuatu tentang gaya pengekodan, praktik, dan alat dalam bahasa yang menarik, termasuk gaya komen log (lihat tip No. 4). Sebab kedua adalah untuk belajar bagaimana projek tertentu mencapai matlamatnya. Sebab ketiga, sekiranya pelesenan membenarkan anda melakukannya dan masuk akal untuk tujuan anda, adalah memasukkan projek ke dalam usaha atau produk anda sendiri. Oleh itu, periksa semula lesen, supaya anda tidak menghadapi masalah pematuhan di kemudian hari.

Definisi git clonedari halaman manual:

Klon repositori ke direktori yang baru dibuat, membuat cabang pelacakan jarak jauh untuk setiap cabang di repositori kloning (terlihat menggunakan git branch -r), dan membuat dan memeriksa cabang awal yang bercabang dari cabang repositori kloning yang aktif sekarang.

Selepas klon, dataran git fetchtanpa argumen akan mengemas kini semua cabang pengesanan jarak jauh, dan git pulltanpa argumen akan menggabungkan cawangan induk jauh ke cabang induk semasa, jika ada.

Petua Git / GitHub No. 2: Tarik kerap

Salah satu kaedah termudah untuk membuat kekacauan bagi diri anda dengan Git (dan memang, dengan sistem kawalan versi mana pun) adalah membiarkan fail tidak segerak. Sekiranya anda git pullkerap, anda akan sentiasa memperbarui salinan repo anda, dan anda berpeluang menggabungkan kod yang anda ubah dengan perubahan orang lain sementara penggabungan itu mudah difahami dan dicapai — idealnya, apabila ia sangat mudah sehingga dapat dilakukan secara automatik. Hasil petua ini adalah untuk melihat status projek anda. Banyak pelanggan Git akan menunjukkan kepada anda secara automatik apabila anda perlu mengemas kini untuk terus mengetahui.

Petua Git / GitHub No. 3: Berkomitmen lebih awal dan kerap

Komit adalah kemas kini terperinci untuk projek, yang merangkumi satu atau lebih perubahan pada satu atau lebih fail. Anggaplah ia sebagai catatan unit kerja yang disiapkan, yang dapat digunakan atau dikeluarkan dari projek sebagai keseluruhan logik. Lakukan setiap perubahan logik yang anda selesaikan, bahkan sebelum mengujinya. Komitmen hanya berlaku untuk repositori tempatan anda. Lihat petua No. 4 dan 5 untuk kesan berpunca dari petua ini.

Definisi git commitdari halaman manual:

Menyimpan kandungan semasa indeks dalam komit baru bersama dengan mesej log dari pengguna yang menerangkan perubahan.

Petua Git / GitHub No. 4: Komen komited anda seperti yang anda mahukan orang lain memberi komen mereka

Terdapat 10 jenis pengekod: Mereka yang mengomentari komitmen mereka, dan mereka yang tidak. (Lelucon lama. Petunjuk: Asas apa yang saya gunakan?)

Saya dengan bebas mengaku menjadi pelekat untuk mesej log komit yang baik. Saya menyiapkan repositori saya untuk memerlukan mesej untuk setiap komit, dan saya dikenali untuk menghantar pesanan lewat malam yang terganggu ketika melakukan pendaratan dengan log mengikut urutan "xx." Sekiranya anda jenis pembangun yang berpendapat (1) kod itu harus dibahas sendiri dan (2) komen sebaris jauh lebih penting daripada log perubahan, cuba kloning repositori yang belum pernah anda lihat sebelumnya dan kenal pasti komit baru-baru ini yang mungkin menyebabkan masalah terbaru disiarkan tanpa membaca semua kod. Seperti yang anda lihat, log komitmen tepat adalah dua kali ganda lebih baik.

Petua Git / GitHub No. 5: Tekan semasa perubahan anda diuji

Bug yang paling teruk berkaitan dengan Git yang pernah saya alami musibah berlaku ketika syarikat penyumberan luar beralih dari Subversion tetapi tidak melatih pembangunnya mengenai perbezaan antara kawalan sumber terdistribusi dan kawalan sumber terpusat. Kira-kira sebulan kemudian, projek ini mengembangkan bug pelik yang tidak dapat dijumpai oleh siapa pun. Pada perjumpaan harian, para pembangun yang bertanggungjawab untuk bidang aplikasi yang bersikap tidak betul akan memprotes, "Saya telah memperbaikinya dua minggu yang lalu!" atau menuduh pemaju lain tidak terganggu untuk melakukan perubahan yang mereka periksa dengan teliti.

Akhirnya, seseorang mengenal pasti masalahnya dan mengajar semua pembangun bagaimana dan kapan pushmereka melakukan: Pendek kata, setiap kali ujian itu berjaya di bangunan tempatan. Kemudian syarikat itu melakukan festival penggabungan selama dua hari sebelum dapat membina dan menggunakan produk bersepadu yang dikemas kini.

Petua Git / GitHub No. 6: Cabang secara bebas

Salah satu kelebihan terbesar yang dimiliki Git daripada beberapa sistem kawalan versi lain adalah bahawa penggabungan biasanya berfungsi dengan baik, sekurang-kurangnya sebahagiannya kerana Git secara automatik memilih nenek moyang umum terbaik yang akan digunakan untuk penggabungan. Sebilangan besar pembangun perisian perlu mula membuat cawangan dalam projek mereka lebih kerap. Ini harus menjadi kejadian harian yang rutin, bukan subjek pertemuan strategi semua pihak yang menderita. Kemungkinannya adalah apabila projek cawangan selesai, diterima, dan siap untuk masuk ke dalam projek utama, penggabungan tersebut tidak akan menimbulkan masalah yang tidak dapat diatasi.

Saya tahu bahawa memerlukan beberapa penyesuaian, terutamanya jika anda terjebak dalam syarikat yang melakukan kawalan kod sumber dengan CVS. Tetapi cubalah. Ini jauh lebih baik daripada meminta pelanggan melihat kod eksperimen anda yang belum selesai ketika projek trunk mesti diterbitkan kerana terdapat pepijat yang pecah. (Artikel ini menjelaskan percabangan asas dan penggabungan dengan baik.)

Petua Git / GitHub No. 7: Gabungkan dengan teliti

Walaupun bergabung dengan Git biasanya berfungsi dengan baik, jika anda melakukannya tanpa berfikir, anda kadang-kadang dapat menghadapi kesukaran. Langkah pertama adalah memastikan anda tidak mengalami perubahan tanpa had. Dari git mergehalaman manual:

Sebelum menerapkan perubahan di luar, anda harus membuat kerja anda sendiri dalam keadaan baik dan dilakukan secara tempatan, jadi ia tidak akan disekat jika terdapat konflik. Lihat juga git-stash.

Lihat juga petua No. 8.

Walaupun semuanya bergerak ke selatan semasa git merge, anda tidak boleh:

Sekiranya anda mencuba penggabungan yang mengakibatkan konflik yang rumit dan ingin memulakannya semula, anda boleh pulih dengan git merge —abort.

Perintah susulan git mergebiasanya git mergetool, dengan andaian anda suka menggunakan GUI untuk penggabungan. Jika anda lebih suka kaedah lama-sekolah, anda boleh mengedit fail-fail dalam konflik dengan editor program kegemaran anda, keluarkan sepenuhnya <<<<<<<, =======dan >>>>>>>garis-garis, save fail disemak semula, dan git addsetiap fail anda tetap.

Petua Git / GitHub No. 8: Stash sebelum menukar cawangan

Aliran kerja pembangun perisian jarang linear. Pengguna mempunyai semangat untuk melaporkan pepijat, pengurus mempunyai keberanian untuk memprioritaskan tiket selain dari yang anda pilih untuk bekerja, dan anda sendiri mungkin berubah fikiran tentang apa yang anda mahu lakukan.

Itu dia, dengan tiga fail yang dikomitmen untuk dilepaskan, dan fail keempat dalam keadaan yang berubah tetapi tidak berfungsi. ( git statusPerintah akan memberitahu anda semua ini jika anda tidak ingat di mana anda berada.) Tiba-tiba anda perlu menyelesaikan masalah bug dalam versi pengeluaran. Anda perlu menukar cawangan sebelum ini, tetapi anda tidak boleh. Direktori kerja anda kotor dan anda mempunyai dua jam kerja yang anda tidak mahu kehilangan.

Masukkan git stash. Voilà! Sekarang anda telah menyimpan semua perubahan anda di cawangan WIP (sedang berjalan), dan anda boleh beralih ke cabang pengeluaran dari direktori bersih anda. Apabila anda selesai melakukannya, beralih kembali ke tempat anda berada git stash apply.

Petua Git / GitHub No. 9: Gunakan inti untuk berkongsi coretan dan pasta

GistHub "inti" - potongan kod yang dikongsi - bukan ciri Git, tetapi mereka menggunakan Git. Semua inti adalah repositori Git, dan GitHub Gist memudahkan untuk membagikannya. Anda boleh mencari Gist untuk inti umum mengikut topik, bahasa pengaturcaraan, status bercabang, dan status berbintang. Anda juga boleh membuat inti rahsia dan membagikannya melalui URL.

Petua Git / GitHub No. 10: Terokai GitHub

Banyak projek sumber terbuka yang menarik mempunyai repositori di GitHub. Explore GitHub menyediakan antara muka melayari untuk mencari sebahagian daripadanya, tetapi kebanyakannya lebih mudah untuk menaip beberapa huruf nama projek di kotak carian untuk mencari reposinya. Contohnya, ketik jqatau backatau anguntuk mencari tiga kerangka JavaScript sumber terbuka utama.

Petua Git / GitHub No. 11: Menyumbang untuk projek sumber terbuka

Selama anda melayari projek sumber terbuka, mengapa tidak menyumbang kepada mereka? Ia tidak sekeras yang anda fikirkan, dan anda akan belajar banyak. Sebagai contoh, anda boleh mengklon projek jquery / jquery (jQuery Core), dan melihat-lihat README.MD. Berhampiran bahagian atas anda akan melihat:

Dalam semangat pengembangan perisian sumber terbuka, jQuery sentiasa mendorong sumbangan kod komuniti. Untuk membantu anda memulakan dan sebelum anda menulis kod, pastikan anda membaca garis panduan sumbangan penting ini dengan teliti ...

Itu diikuti oleh tiga pautan. Yang pertama dari tiga akan memulakan anda dengan cepat. Tidak setiap projek sumber terbuka menyusun rancangan dengan begitu jelas, tetapi mereka semua mencuba.

Fahami perbezaan antara menjadi penyumbang dan komited. Seorang penyumbang telah menandatangani perjanjian yang diperlukan dan memberikan sumbangan untuk projek tersebut. Seorang pelayan diberi kuasa untuk benar-benar memberikan sumbangan yang diberikan kepada repositori projek. Oleh kerana akan ada kelewatan semasa komitator menguji sumbangan anda dan anda tidak mahu mengikat cawangan induk anda, anda harus membuat perubahan di cabang lain (lihat tip No. 6) sebelum menghantar permintaan tarik (lihat tip No .16).