12 Ciri Menakjubkan GitHub

Untuk kehidupan saya, saya tidak dapat memikirkan sebarang intro, jadi...

#1 Mengedit kod pada GitHub.com

Saya akan mulakan dengan apa yang saya rasa semua orang sudah tahu (walaupun saya sendiri tidak tahu mengenainya seminggu yang lalu). Apabila melihat mana-mana fail teks pada GitHub, dalam mana-mana repositori, anda boleh melihat pensel kecil di bahagian atas sebelah kanan. Jika anda mengklik padanya, anda boleh mengedit fail ini. Setelah selesai, klik Cadangkan perubahan fail dan GitHub akan mencipta fork dan Pull Request. Menakjubkan, bukan? Dia mencipta garpu sendiri! Tidak perlu mencantas dan memuat naik kod kepada diri sendiri, buat perubahan secara setempat dan hantar semula ke GitHub dengan Permintaan Tarik. Sangat mudah jika anda perlu membuat suntingan yang minimum. bukan Permintaan Tarik yang sebenar

#2 Memasukkan imej

Penerangan masalah tidak terhad kepada komen teks sahaja. Adakah anda tahu anda boleh menampal imej terus dari papan keratan? Apabila ditampal, anda akan melihatnya dimuat naik (ke awan, tidak syak lagi) dan bertukar menjadi markup untuk memaparkan imej. Anggun!

#3 Pemformatan kod

Jika anda perlu menulis blok kod, mulakan dengan tiga tanda belakang dan GitHub akan cuba meneka bahasa pengaturcaraan yang anda tulis. Tetapi jika anda menyiarkan sekeping kod dalam bahasa pengaturcaraan seperti Vue, Typescript atau JSX, anda boleh menentukan bahasa secara eksplisit supaya penyerlahan sintaks adalah betul. Perhatikan ```jsx pada baris pertama: ... memastikan paparan yang betul bagi coretan kod: (Ini juga terpakai kepada Gist, dengan cara ini. Jika anda menentukan sambungan .jsf untuk intipati, sintaks JSF akan diserlahkan). Berikut ialah senarai semua sintaks yang disokong .

#4 Menutup masalah menggunakan "kata ajaib" dalam Permintaan Tarik

Katakan anda membuat Permintaan Tarik yang membetulkan isu #234. Anda boleh memasukkan teks "membetulkan isu #234" ke dalam perihalan permintaan anda (atau di mana-mana dalam sebarang ulasan permintaan perubahan). Selepas ini, menggabungkan Permintaan Tarik akan "secara automatik" menutup masalah. Sejuk, bukan? Berikut ialah maklumat lanjut tentang perkara ini dalam dokumentasi .

# 5 Pautan ke komen

Pernahkah anda perlu membuat pautan ke ulasan tertentu dan tidak tahu caranya? Hari-hari itu sudah lama berlalu kerana saya akan memberitahu anda tentang rahsia: Untuk membuat pautan ke ulasan, anda hanya klik pada tarikh/masa di sebelah tajuk. Lihat, gaearon kini mempunyai foto!

Pautan kod #6

Jadi anda ingin membuat pautan ke baris kod tertentu. Dalam kes ini, cuba ini: Klik pada nombor baris di sebelah kod yang dikehendaki dalam fail terbuka. Wah, nampak? URL telah berubah, nombor baris kini kelihatan di dalamnya! Jika anda menahan kekunci SHIFT dan klik pada nombor baris lain, maka voila! – URL akan berubah lagi dan julat baris akan diserlahkan. URL ini kini akan menghala ke fail ini dan julat baris ini. Tetapi tunggu, ia menunjukkan kepada benang semasa. Bagaimana jika fail berubah? Anda mungkin memerlukan, dalam kes ini, pautan kekal ke fail dalam keadaan semasanya. Saya sangat malas, jadi saya mengambil satu tangkapan skrin semua perkara di atas: Ngomong-ngomong, tentang URL...

#7 Menggunakan URL GitHub sebagai Baris Perintah

Menavigasi melalui GitHub menggunakan UI diatur dengan sangat mudah. Tetapi kadangkala, untuk sampai ke lokasi tertentu, lebih pantas untuk hanya menaipnya ke dalam URL. Sebagai contoh, jika saya ingin pergi ke cawangan yang saya sedang usahakan dan melihat bagaimana ia dibandingkan dengan master, saya hanya boleh menaip /compare/branchname selepas nama repositori. Ini akan membawa saya ke halaman perbezaan untuk cawangan itu: Tetapi ini adalah perbezaan daripada cawangan induk, tetapi jika saya bekerja dengan cawangan integrasi sebelum ini, saya boleh memasukkan /compare/integration-branch...my-branch dalam URL Untuk pencinta hotkey: CTRL+L atau CMD+L mengalihkan kursor ke bar URL (sekurang-kurangnya dalam penyemak imbas Chrome dan Firefox). Ini, digabungkan dengan autolengkap pelayar, menjadikan navigasi antara cawangan lebih mudah. Petua profesional: Gunakan anak panah untuk menavigasi melalui cadangan autolengkap Chrome dan tekan SHIFT+DELETE untuk mengalih keluar item daripada sejarah (contohnya, selepas menggabungkan cawangan). (Saya tidak tahu sama ada lebih mudah untuk membaca kekunci pintasan ini jika saya meletakkan ruang di dalamnya, seperti SHIFT + DELETE. Tetapi secara teknikal “+” bukan sebahagian daripadanya, jadi saya tidak menyukai pilihan ini. Ia kerana perkara seperti ini saya tidak tidur pada waktu malam, Rhonda.)

# 8 Buat senarai untuk masalah

Adakah anda mahu kotak pilihan dalam huraian masalah anda? Dan adakah anda mahu bar bagus seperti "2 daripada 5" muncul apabila anda melihat isu daripada senarai? Tiada masalah! Anda boleh membuat kotak semak interaktif menggunakan sintaks berikut:

• [ ] Lebar skrin (integer)
• [x] Sokongan pekerja perkhidmatan
• [x] Dapatkan sokongan
• [ ] Sokongan flexbox CSS
• [ ] Elemen tersuai

Sintaks: ruang, sempang, ruang, kurungan segi empat buka, ruang (atau x), kurungan segi empat tutup, ruang dan beberapa perkataan. Selepas itu, anda sebenarnya boleh menyemak/nyahtanda butang ini! Atas sebab tertentu, ini kelihatan seperti sihir teknikal kepada saya. Anda boleh menanda kotak! Dan pada masa yang sama teks asal berubah! Sungguh menakutkan untuk memikirkan apa yang akan mereka lakukan seterusnya. Oh, dan jika masalah ini terdapat dalam panel projek, maka kemajuan akan dipaparkan di sana juga: Jika anda tidak faham apa yang saya maksudkan dengan "panel projek" - baca di bawah. Hanya beberapa sentimeter lebih rendah pada halaman ini.

#9 Panel projek dalam GitHub

Untuk projek besar saya selalu menggunakan Jira. Dan untuk projek peribadi saya, saya sentiasa menggunakan Trello. Saya sangat suka kedua-dua alat ini. Apabila saya mengetahui beberapa minggu yang lalu bahawa GitHub menawarkan pilihannya sendiri, betul-betul dalam tab Projek pada repositori, saya fikir adalah masuk akal untuk menduplikasi set tugas yang sudah saya kerjakan dalam Trello. Tiada apa-apa yang lucu di sini. Dan kini perkara yang sama dalam projek GitHub: Secara beransur-ansur mata anda akan terbiasa dengan imej kontras rendah Demi kelajuan, saya telah menambahkan semua perkara di atas sebagai nota, bermakna ia bukan isu GitHub "sebenar". Tetapi kuasa pengurusan isu dalam GitHub terletak pada penyepaduannya dengan seluruh repositori - jadi mungkin lebih baik untuk menambah isu sedia ada daripada repositori ke papan pemuka. Klik Tambah Kad di penjuru kanan sebelah atas dan cari perkara yang ingin anda tambahkan. Di sinilah sintaks carian khas berguna : contohnya, type is:pr is:open dan anda boleh menyeret mana-mana Pull Request terbuka ke panel, atau label:bug jika anda perlu membetulkan sebarang ralat. Anda juga boleh menukar nota sedia ada kepada isu. Dan akhirnya, daripada borang masalah sedia ada, tambahkannya pada projek di panel kanan. Ia akan masuk ke dalam senarai triage panel projek itu, jadi anda boleh memilih lajur untuk meletakkannya Apabila perihalan "tugas" berada dalam repositori yang sama dengan kod yang melaksanakan tugas ini, ia adalah sangat (sangat) mudah. Ini bermakna bertahun-tahun dari sekarang, anda akan dapat menjalankan git blame pada baris kod dan mengetahui keseluruhan isu yang membawa kepada baris itu, tanpa perlu menjejaki semuanya di Jira/Trello/tempat lain.

Kecacatan

Selama tiga minggu yang lalu saya telah bereksperimen dengan melakukan segala-galanya dalam GitHub dan bukannya Jira (dalam projek kecil, jenis gaya Kanban) dan menyukainya. Tetapi saya tidak dapat membayangkan ini untuk projek Scrum di mana kelajuan pembangunan dan seumpamanya perlu dinilai dan dikira dengan betul. Berita baiknya ialah projek GitHub mempunyai sedikit "ciri khas" yang menukar kepada sistem lain tidak akan mengambil banyak masa. Jadi cubalah dan lihat sejauh mana anda menyukainya. Saya tidak tahu betapa pentingnya ini, tetapi saya mendengar tentang ZenHub dan membukanya buat kali pertama 10 minit yang lalu. Ia pada asasnya adalah lanjutan GitHub di mana anda boleh menilai isu dan mencipta "epik" dan kebergantungan. Terdapat graf kelajuan pembangunan dan kelesuan; Ia kelihatan seperti satu perkara yang menakjubkan. Bacaan lanjut: dokumentasi GitHub pada Projek.

#10 Gwiki

Untuk set halaman yang tidak berstruktur—seperti Wikipedia—Wiki GitHub (yang saya panggil Gwiki sahaja mulai sekarang) sangat bagus. Untuk set halaman berstruktur - contohnya, seperti dokumentasi anda - tidak begitu banyak. Tiada cara untuk menunjukkan bahawa "halaman ini adalah anak halaman itu"; tiada perkara yang mudah seperti butang "Bahagian seterusnya" dan "Bahagian sebelumnya". Hansel dan Gretel pasti akan tersesat di sini, kerana tiada "serbuk roti" (pengendali penyahpepijatan khas - lebih kurang trans.) di sini sama ada. (Nota pengarang: Pernahkah anda membaca cerita ini? Ia hanya tidak berperikemanusiaan. Dua samseng muda membunuh seorang wanita tua yang kelaparan yang miskin, membakarnya hidup-hidup di dalam ketuharnya sendiri . Dan sudah tentu, meninggalkan keadaan huru-hara yang tidak dapat difahami sesiapa pun. Saya rasa itulah sebabnya orang muda hari ini sangat sensitif - cerita yang dibacakan kepada kanak-kanak pada waktu tidur hari ini tidak cukup kejam!) Teruskan - untuk mencuba Gwiki secara sebenar, saya memasukkan beberapa halaman daripada NodeJS sebagai halaman wiki, kemudian mencipta tersuai bar sisi untuk mensimulasikan struktur sebenar tapak. Bar sisi ini sentiasa ada, walaupun halaman semasa tidak diserlahkan. Pautan perlu diselenggara secara manual, tetapi secara keseluruhan semuanya berfungsi dengan baik. Jika anda mahu, anda boleh lihat : Ini sukar untuk bersaing dengan sesuatu seperti GitBook (yang digunakan dalam dokumentasi Redux ) atau tapak web yang dipesan lebih dahulu. Tetapi ini sudah menjadi 80% yang baik dan semuanya betul dalam repositori anda. Saya hanya peminat ini. Saya mencadangkan bahawa jika anda telah mengatasi fail README.md tunggal dan memerlukan beberapa halaman berbeza untuk manual pengguna atau dokumentasi yang lebih terperinci, adalah wajar untuk kekal dengan Gwiki. Jika kekurangan struktur/navigasi mengganggu anda, teruskan ke perkara lain.

#11 Halaman GitHub

Anda mungkin sudah tahu bahawa Halaman GitHub boleh digunakan untuk mengehoskan tapak web statik. Dan jika anda tidak tahu, maka anda tahu sekarang. Walau bagaimanapun, bahagian ini dikhususkan untuk topik yang lebih khusus: menggunakan Jekyll untuk membuat tapak web. Dalam bentuk yang paling mudah, GitHub Pages + Jekyll boleh memaparkan fail README.md menggunakan tema yang kelihatan cantik. Sebagai contoh, lihat halaman readme saya dari about-github : Jika anda mengklik pada tab tetapan untuk tapak GitHub ini, dayakan Halaman GitHub dan pilih tema Jekyll... Kemudian kita akan mendapat halaman dalam gaya tema Jekyll : Anda kemudiannya boleh membuat keseluruhan tapak statik berdasarkan terutamanya pada fail penanda yang boleh diedit dengan mudah, pada asasnya menjadikan GitHub sebagai CMS. Walaupun saya sebenarnya tidak menggunakan ini, ini adalah cara tapak web dibina menggunakan rangka kerja Bootstrap menggunakan React, jadi tiada apa-apa yang mengerikan mengenainya. Saya perhatikan bahawa Ruby mesti berjalan pada mesin tempatan (pengguna Windows akan bertukar pandangan pemahaman di sini dan pergi ke arah lain, pengguna macOS akan berkata: "Apa masalahnya, ke mana anda pergi? Ruby adalah platform universal! Terdapat juga GEMS sistem pengurusan pakej!”) ( Perlu diingat juga bahawa "Kandungan atau tingkah laku yang agresif atau mengancam" tidak dibenarkan pada Halaman GitHub, jadi anda tidak akan dapat menyiarkan versi cerita Hansel dan Gretel anda di sana).

Pendapat saya

Semakin saya melihat gabungan GitHub Pages + Jekyll (untuk artikel ini), semakin saya fikir keseluruhan idea itu berbau pelik. Idea "membuat laman web anda sendiri dengan usaha yang minimum" adalah bagus. Tetapi untuk mengusahakannya, anda masih memerlukan versi semasa pada mesin tempatan. Dan untuk sesuatu yang "mudah" terdapat terlalu banyak arahan baris arahan. Saya membelek tujuh muka surat dalam bahagian Bermula dan merasakan satu-satunya perkara yang mudah ialah saya . Dan saya belum mengetahui sintaks mudah untuk halaman utama atau asas "Mekanisme Templat berdasarkan bahasa Cecair" ringkas. Saya lebih suka menulis laman web sendiri! Sejujurnya, saya agak terkejut bahawa Facebook menggunakan ini untuk dokumentasi React apabila mereka mungkin boleh membina halaman sistem bantuan mereka menggunakan React dan pra-pamerkan sebagai fail HTML statik setiap hari . Apa yang mereka perlu lakukan ialah mencari cara untuk menerima fail markup sedia ada seolah-olah ia datang daripada CMS. Bagaimana jika...

#12 Menggunakan GitHub sebagai CMS

Katakan kami mempunyai tapak web dengan beberapa teks, tetapi kami tidak mahu menyimpan teks itu sebagai penanda HTML. Sebaliknya, kami ingin menyimpan ketulan teks di suatu tempat yang boleh diedit dengan mudah oleh pengguna bukan pembangun. Sebaiknya dengan beberapa pilihan versi. Mungkin juga dengan beberapa jenis proses semakan rakan sebaya. Inilah yang saya cadangkan: gunakan fail penanda yang disimpan dalam repositori untuk menyimpan teks. Dan gunakan komponen di bahagian klien yang akan mendapatkan semula kepingan teks ini dan memaparkannya pada halaman. Saya peminat React, jadi berikut ialah contoh komponen <Markdown> yang betul, yang diberi laluan ke fail penurunan nilai, akan mengekstraknya, menghuraikannya dan menjadikannya sebagai HTML.

class Markdown extends React.Component {
    constructor(props) {
      super(props);

      // Конечно, вам нужно заменить это на свой URL
      this.baseUrl = 'https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';

      this.state = {
        markdown: '',
      };
    }

    componentDidMount() {
      fetch(`${this.baseUrl}/${this.props.url}`)
        .then(response => response.text())
        .then((markdown) => {
          this.setState({markdown});
        });
    }

    render() {
      return (
        <div dangerouslySetInnerHTML={{__html: marked(this.state.markdown)}} />
      );
    }
}

(Saya menggunakan pakej bertanda npm di sini untuk menghuraikan markup dalam HTML) URL menghala ke repositori contoh saya, yang mengandungi fail markup dalam direktori /text-snippets . (Anda juga boleh menggunakan API GitHub untuk mengambil content , tetapi saya ragu anda memerlukannya.) Anda boleh menggunakan komponen seperti ini seperti ini:

const Page = () => (
  <div className="page">
    <div className="about-us">
      <Markdown url="about-us.md" />
    </div>

    <div className="disclaimer">
      <p>A very important disclaimer:</p>

      <Markdown url="disclaimers/home-page-disclaimer.md" />
    </div>
  </div>
);

Jadi sekarang GitHub bertindak sebagai, dalam satu cara, CMS anda untuk kepingan teks yang anda ingin hos. Contoh di atas hanya mendapatkan semula markup selepas komponen dimuatkan dalam penyemak imbas. Jika anda memerlukan tapak statik, anda perlu memaparkannya pada pelayan. Berita baik! Tiada apa-apa yang menghalang anda daripada mendapatkan semula semua fail markup pada pelayan (menggunakan apa-apa strategi caching yang anda suka). Jika anda memutuskan untuk pergi ke laluan ini, masuk akal untuk menggunakan API GitHub untuk mendapatkan senarai semua fail penanda dalam direktori. Bonus - Utiliti GitHub! Saya telah menggunakan sambungan Chrome Octotree sejak sekian lama dan mengesyorkannya kepada anda. Bukan tanpa tempahan, tetapi saya masih mengesyorkannya. Ia memaparkan panel di sebelah kiri dengan paparan pokok repositori yang anda semak imbas. Dan daripada video ini saya belajar tentang octobox , yang pada pandangan saya juga merupakan utiliti yang sangat baik setakat ini. Ini ialah peti masuk untuk isu GitHub anda. Itu sahaja yang anda perlu tahu tentang dia. Bercakap tentang warna, saya mengambil semua tangkapan skrin di atas dalam tema ringan supaya tidak menakutkan anda. Tetapi jika saya lebih suka warna gelap dalam segala-galanya, maka mengapa bersabar dengan GitHub pucat maut? Di sini saya menggunakan gabungan sambungan Bergaya untuk penyemak imbas Chrome (yang boleh menggunakan tema pada mana-mana tapak web) dan gaya Gelap GitHub . Dan sebagai permulaan, tema gelap alatan pembangun GitHub (terbina dalam, anda hanya perlu mendayakannya) dan tema Atom One Dark untuk Chrome.

Bitbucket

Tegasnya, ia tidak sepenuhnya sesuai di sini, tetapi saya tidak boleh tidak menyebut Bitbucket. Dua tahun lalu saya memulakan projek dan menghabiskan setengah hari memilih hosting git terbaik. Jadi, Bitbucket menang dengan margin yang ketara. Saluran paip semakan kod mereka jauh mendahului persaingan (ini sudah lama sebelum GitHub mempunyai konsep penyemak). Sejak itu, GitHub juga telah memperoleh ulasan. Malangnya, saya tidak mempunyai peluang untuk menggunakan Bitbucket untuk tahun lepas - mungkin mereka telah bergerak ke hadapan dalam sesuatu lagi. Jadi saya mengesyorkan agar mereka yang bertanggungjawab memilih perkhidmatan hosting git juga memberi perhatian kepada Bitbucket.

Kesimpulan

Itu sahaja! Saya harap saya dapat memberitahu anda sekurang-kurangnya tiga perkara yang anda tidak tahu sebelum ini. Dan saya juga berharap anda mempunyai masa yang baik membaca artikel saya.