12 Fitur Luar Biasa dari GitHub

Seumur hidup saya, saya tidak bisa memikirkan intro apa pun, jadi...

#1 Mengedit kode di GitHub.com

Saya akan mulai dengan apa yang menurut saya sudah diketahui semua orang (walaupun saya pribadi tidak mengetahuinya seminggu yang lalu). Saat melihat file teks apa pun di GitHub, di repositori mana pun, Anda dapat melihat pensil kecil di kanan atas. Jika Anda mengkliknya, Anda dapat mengedit file ini. Setelah selesai, klik Usulkan perubahan file dan GitHub akan membuat fork dan Pull Request. Luar biasa, bukan? Dia menciptakan garpu itu sendiri! Tidak perlu melakukan fork dan mengunggah kode ke diri Anda sendiri, membuat perubahan secara lokal dan mengirimkannya kembali ke GitHub dengan Permintaan Tarik. Sangat nyaman jika Anda perlu melakukan sedikit pengeditan. bukan Permintaan Tarik yang sebenarnya

#2 Memasukkan gambar

Deskripsi masalah tidak terbatas pada komentar teks saja. Tahukah Anda bahwa Anda dapat menempelkan gambar langsung dari clipboard? Saat ditempel, Anda akan melihatnya diunggah (tidak diragukan lagi ke cloud) dan diubah menjadi markup untuk menampilkan gambar. Anggun!

#3 Pemformatan kode

Jika Anda perlu menulis satu blok kode, mulailah dengan tiga backtick dan GitHub akan mencoba menebak bahasa pemrograman apa yang Anda gunakan. Namun jika Anda memposting sepotong kode dalam bahasa pemrograman seperti Vue, TypeScript, atau JSX, Anda dapat secara eksplisit menentukan bahasanya sehingga penyorotan sintaksisnya benar. Perhatikan ```jsx di baris pertama: ...memastikan tampilan cuplikan kode yang benar: (Omong-omong, ini juga berlaku untuk Intisari. Jika Anda menentukan ekstensi .jsf untuk Intisari, sintaksis JSF akan disorot). Berikut adalah daftar semua sintaks yang didukung .

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

Katakanlah Anda membuat Permintaan Tarik yang memperbaiki masalah #234. Anda dapat memasukkan teks "perbaikan masalah #234" ke dalam deskripsi permintaan Anda (atau di mana pun dalam komentar permintaan perubahan). Setelah ini, menggabungkan Permintaan Tarik akan “secara otomatis” menutup masalah. Keren, bukan? Berikut informasi lebih lanjut tentang ini di dokumentasi .

#5 Tautan ke komentar

Pernahkah Anda perlu membuat tautan ke komentar tertentu dan tidak tahu caranya? Hari-hari itu sudah lama berlalu karena saya akan memberi tahu Anda sebuah rahasia: Untuk membuat tautan ke komentar, Anda cukup mengeklik tanggal/waktu di sebelah judul. Lihat, gaearon sekarang punya fotonya!

#6 Tautan kode

Jadi, Anda ingin membuat tautan ke baris kode tertentu. Dalam hal ini, coba ini: Klik pada nomor baris di sebelah kode yang diinginkan dalam file yang terbuka. Wah, lihat? URL telah berubah, nomor baris sekarang terlihat di dalamnya! Jika Anda menahan tombol SHIFT dan mengklik nomor baris lain, voila! – URL akan berubah lagi dan rentang baris akan disorot. URL ini sekarang akan mengarah ke file ini dan rentang baris ini. Tapi tunggu, ini menunjuk ke thread saat ini. Bagaimana jika filenya berubah? Anda mungkin memerlukan, dalam hal ini, tautan permanen ke file dalam kondisi saat ini. Saya sangat malas, jadi saya mengambil satu tangkapan layar dari semua hal di atas: Ngomong-ngomong, tentang URL...

#7 Menggunakan URL GitHub sebagai Baris Perintah

Menavigasi melalui GitHub menggunakan UI diatur dengan sangat nyaman. Namun terkadang, untuk menuju lokasi tertentu, lebih cepat cukup mengetikkannya ke dalam URL. Misalnya, jika saya ingin pergi ke cabang yang sedang saya kerjakan dan melihat perbandingannya dengan master, saya cukup mengetikkan /compare/branchname setelah nama repositori. Ini akan membawa saya ke halaman berbeda untuk cabang itu: Tapi ini perbedaan dari cabang master, tetapi jika saya pernah bekerja dengan cabang integrasi sebelumnya, saya bisa memasukkan /bandingkan/integrasi-cabang...cabang-saya di URL Untuk pecinta hotkey: CTRL+L atau CMD+L memindahkan kursor ke bilah URL (setidaknya di browser Chrome dan Firefox). Ini, dikombinasikan dengan pelengkapan otomatis browser, membuat navigasi antar cabang menjadi lebih mudah. Kiat pro: Gunakan panah untuk menelusuri saran pelengkapan otomatis Chrome, dan tekan SHIFT+DELETE untuk menghapus item dari riwayat (misalnya, setelah menggabungkan cabang). (Saya tidak tahu apakah akan lebih mudah membaca tombol pintas ini jika saya memberi spasi di dalamnya, seperti SHIFT + DELETE. Namun secara teknis “+” bukan bagian darinya, jadi saya tidak suka opsi ini. Ini karena hal seperti ini aku tidak bisa tidur di malam hari, Rhonda.)

#8 Buat daftar untuk masalah

Apakah Anda ingin kotak centang di deskripsi masalah Anda? Dan apakah Anda ingin bilah bagus seperti “2 dari 5” muncul saat Anda melihat masalah dari daftar? Tidak masalah! Anda dapat membuat kotak centang interaktif menggunakan sintaks berikut:

• [ ] Lebar layar (bilangan bulat)
• [x] Dukungan pekerja layanan
• [x] Dapatkan dukungan
• [ ] Dukungan kotak fleksibel CSS
• [ ] Elemen khusus

Sintaksis: spasi, tanda hubung, spasi, kurung siku pembuka, spasi (atau x), kurung siku penutup, spasi dan beberapa kata. Setelah itu, Anda sebenarnya dapat mencentang/menghapus centang tombol-tombol ini! Untuk beberapa alasan, ini tampak seperti keajaiban teknis bagi saya. Anda dapat mencentang kotaknya! Dan pada saat yang sama teks sumber berubah! Menakutkan memikirkan apa yang akan mereka lakukan selanjutnya. Oh, dan jika masalah ini ada di panel proyek, maka progresnya juga akan ditampilkan di sana: Jika Anda tidak mengerti apa yang saya maksud dengan "panel proyek" - baca di bawah. Hanya beberapa sentimeter lebih rendah di halaman ini.

#9 Panel proyek di GitHub

Untuk proyek besar saya selalu menggunakan Jira. Dan untuk proyek pribadi saya, saya selalu menggunakan Trello. Saya sangat menyukai kedua alat ini. Ketika saya mengetahui beberapa minggu yang lalu bahwa GitHub menawarkan opsinya sendiri, tepat di tab Proyek di repositori, saya pikir masuk akal untuk menduplikasi kumpulan tugas yang sudah saya kerjakan di Trello. Tidak ada yang lucu di sini Dan sekarang hal yang sama terjadi di proyek GitHub: Lambat laun mata Anda akan terbiasa dengan gambar berkontras rendah Demi kecepatan, saya telah menambahkan semua hal di atas sebagai catatan, artinya itu bukan masalah GitHub yang "nyata". Namun kekuatan manajemen masalah di GitHub terletak pada integrasinya dengan repositori lainnya - jadi mungkin lebih baik menambahkan masalah yang ada dari repositori ke dasbor. Klik Tambahkan Kartu di sudut kanan atas dan temukan apa yang ingin Anda tambahkan. Di sinilah sintaks pencarian khusus berguna : misalnya, ketik is:pr is:open dan Anda dapat menyeret Pull Request apa pun yang terbuka ke panel, atau label:bug jika Anda perlu memperbaiki beberapa bug. Anda juga dapat mengubah catatan yang ada menjadi terbitan. Dan terakhir, dari form soal yang ada, tambahkan ke project di panel sebelah kanan. Ini akan masuk ke daftar triase panel proyek itu, sehingga Anda dapat memilih kolom mana yang akan dimasukkan Ketika deskripsi "tugas" berada di repositori yang sama dengan kode yang mengimplementasikan tugas ini, ini sangat (sangat) nyaman. Ini berarti bahwa bertahun-tahun dari sekarang, Anda akan dapat menjalankan git menyalahkan sebaris kode dan mencari tahu keseluruhan masalah yang menyebabkan baris tersebut, tanpa harus melacak semuanya di Jira/Trello/di tempat lain.

Kekurangan

Selama tiga minggu terakhir saya telah bereksperimen dengan melakukan segala sesuatu di GitHub, bukan di Jira (pada proyek kecil, semacam gaya Kanban) dan menyukainya. Tapi saya tidak bisa membayangkan hal ini untuk proyek Scrum di mana kecepatan pengembangan dan sejenisnya perlu dinilai dan dihitung dengan benar. Kabar baiknya adalah proyek GitHub hanya memiliki sedikit "fitur khusus" sehingga beralih ke sistem lain tidak akan memakan banyak waktu. Jadi cobalah dan lihat seberapa besar Anda menyukainya. Saya tidak tahu betapa pentingnya hal ini, tetapi saya mendengar tentang ZenHub dan membukanya pertama kali 10 menit yang lalu. Ini pada dasarnya merupakan perpanjangan dari GitHub tempat Anda dapat menilai masalah dan membuat "epik" dan ketergantungan. Ada grafik kecepatan pengembangan dan kelelahan; Sepertinya itu hal yang luar biasa. Bacaan lebih lanjut: Dokumentasi GitHub tentang Proyek.

#10 Gwiki

Untuk kumpulan halaman yang tidak terstruktur—seperti Wikipedia—GitHub Wiki (yang akan saya sebut Gwiki mulai sekarang) sangat bagus. Untuk kumpulan halaman terstruktur - misalnya, seperti dokumentasi Anda - tidak terlalu banyak. Tidak ada cara untuk menunjukkan bahwa "halaman ini adalah turunan dari halaman itu"; tidak ada hal-hal praktis seperti tombol "Bagian selanjutnya" dan "Bagian sebelumnya". Hansel dan Gretel pasti akan tersesat di sini, karena tidak ada "remah roti" (operator debugging khusus - kira-kira trans.) di sini juga. (Catatan Penulis: Sudahkah Anda membaca cerita ini? Itu tidak manusiawi. Dua preman muda membunuh seorang wanita tua malang yang kelaparan, membakarnya hidup-hidup di ovennya sendiri . Dan tentu saja, meninggalkan kekacauan total yang tidak dapat dipahami oleh siapa pun. Saya pikir itu sebabnya anak-anak muda jaman sekarang sangat sensitif – cerita yang dibacakan kepada anak-anak sebelum tidur sekarang tidak cukup kejam!) Selanjutnya – untuk mencoba Gwiki secara nyata, saya memasukkan beberapa halaman dari NodeJS sebagai halaman wiki, lalu membuat custom sidebar untuk mensimulasikan struktur situs yang sebenarnya. Sidebar ini selalu ada, meskipun halaman saat ini tidak disorot. Tautan harus dipelihara secara manual, tetapi secara keseluruhan semuanya berfungsi dengan baik. Jika mau, Anda dapat melihat : Ini hampir tidak dapat bersaing dengan sesuatu seperti GitBook (yang digunakan dalam dokumentasi Redux ) atau situs web yang dipesan lebih dahulu. Tapi ini sudah 80% bagus dan semuanya baik-baik saja di repositori Anda. Saya hanya penggemar ini. Saya menyarankan jika Anda sudah terlalu besar dalam satu file README.md dan memerlukan beberapa halaman berbeda untuk panduan pengguna atau dokumentasi yang lebih rinci, masuk akal untuk tetap menggunakan Gwiki. Jika kurangnya struktur/navigasi mengganggu Anda, lanjutkan ke hal lain.

#11 Halaman GitHub

Anda mungkin sudah mengetahui bahwa Halaman GitHub dapat digunakan untuk menghosting situs web statis. Dan jika Anda tidak mengetahuinya, maka Anda mengetahuinya sekarang. Namun, bagian ini didedikasikan untuk topik yang lebih spesifik: menggunakan Jekyll untuk membuat situs web. Dalam bentuknya yang paling sederhana, GitHub Pages + Jekyll dapat merender file README.md menggunakan tema yang terlihat bagus. Misalnya, lihat halaman readme saya dari about-github : Jika Anda mengklik tab pengaturan untuk situs GitHub ini, aktifkan Halaman GitHub, dan pilih tema Jekyll... Kemudian kita akan mendapatkan halaman dengan gaya tema Jekyll : Anda kemudian dapat membuat seluruh situs statis berdasarkan file markup yang mudah diedit, yang pada dasarnya mengubah GitHub menjadi CMS. Meskipun saya belum benar-benar menggunakannya, ini adalah bagaimana situs web dibangun menggunakan kerangka Bootstrap menggunakan React, jadi tidak ada yang salah dengan itu. Saya perhatikan bahwa Ruby harus berjalan di mesin lokal (pengguna Windows di sini akan bertukar pandangan pemahaman dan sebaliknya, pengguna macOS akan berkata: "Apa masalahnya, mau kemana? Ruby adalah platform universal! Ada juga PERMATA sistem manajemen paket!”) ( Perlu diperhatikan juga bahwa "Konten atau perilaku yang agresif atau mengancam" tidak diperbolehkan di Halaman GitHub, jadi Anda tidak akan dapat memposting versi cerita Hansel dan Gretel Anda di sana).

Pendapat saya

Semakin saya melihat kombinasi Halaman GitHub + Jekyll (untuk artikel ini), semakin saya merasa keseluruhan idenya berbau aneh. Ide "membuat situs web Anda sendiri dengan sedikit usaha" sangat bagus. Namun untuk mengerjakannya, Anda masih memerlukan versi terkini di mesin lokal. Dan untuk sesuatu yang "sederhana" ada terlalu banyak perintah baris perintah. Saya membaca sekilas tujuh halaman di bagian Memulai dan merasa satu-satunya hal yang sederhana tentang hal itu adalah saya . Dan saya bahkan belum menemukan sintaks sederhana untuk halaman utama atau dasar-dasar “Mekanisme Templating berdasarkan bahasa Liquid.” Saya lebih suka menulis situs web sendiri! Sejujurnya, saya sedikit terkejut bahwa Facebook menggunakan ini untuk dokumentasi React ketika mereka mungkin dapat membangun halaman sistem bantuan mereka menggunakan React dan melakukan pra-render sebagai file HTML statis setiap hari . Yang perlu mereka lakukan hanyalah menemukan cara untuk menerima file markup yang ada seolah-olah berasal dari CMS. Bagaimana jika...

#12 Menggunakan GitHub sebagai CMS

Katakanlah kita memiliki situs web dengan beberapa teks, namun kita tidak ingin menyimpan teks tersebut sebagai markup HTML. Sebaliknya, kami ingin menyimpan potongan teks di suatu tempat yang dapat dengan mudah diedit oleh pengguna non-pengembang. Lebih disukai dengan beberapa opsi versi. Mungkin bahkan dengan semacam proses tinjauan sejawat. Inilah yang saya sarankan: gunakan file markup yang disimpan di repositori untuk menyimpan teks. Dan gunakan komponen di sisi klien yang akan mengambil potongan teks ini dan menampilkannya di halaman. Saya penggemar React, jadi inilah contoh komponen <Markdown> yang tepat, yang, jika diberi jalur ke file penurunan harga, akan mengekstraknya, menguraikannya, dan merendernya 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 paket bertanda npm di sini untuk mengurai markup dalam HTML) URL menunjuk ke repositori contoh saya, yang berisi file markup di direktori /text-snippets . (Anda juga dapat menggunakan API GitHub untuk mengambil konten , tetapi saya ragu Anda memerlukannya.) Anda dapat menggunakan komponen 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 CMS Anda untuk potongan teks yang ingin Anda host. Contoh di atas hanya mengambil markup setelah komponen dimuat di browser. Jika Anda memerlukan situs statis, Anda harus merendernya di server. Kabar baik! Tidak ada yang menghentikan Anda untuk mengambil semua file markup di server (menggunakan strategi caching apa pun yang Anda suka). Jika Anda memutuskan untuk mengambil rute ini, masuk akal untuk menggunakan API GitHub untuk mendapatkan daftar semua file markup dalam sebuah direktori. Bonus - Utilitas GitHub! Saya telah menggunakan ekstensi Chrome Octotree selama beberapa waktu sekarang dan merekomendasikannya kepada Anda. Bukan tanpa syarat, tapi saya tetap merekomendasikannya. Ini menampilkan panel di sebelah kiri dengan tampilan hierarki dari repositori yang Anda jelajahi. Dan dari video ini saya belajar tentang octobox , yang menurut saya juga merupakan utilitas yang sangat bagus sejauh ini. Ini adalah kotak masuk untuk masalah GitHub Anda. Hanya itu yang perlu Anda ketahui tentang dia. Berbicara tentang warna, saya mengambil semua screenshot di atas dalam tema terang agar tidak membuat Anda takut. Tetapi jika saya lebih suka warna gelap dalam segala hal, lalu mengapa harus menggunakan GitHub yang pucat pasi? Di sini saya menggunakan kombinasi ekstensi Stylish untuk browser Chrome (yang dapat menerapkan tema ke situs web mana pun) dan GitHub Dark style . Dan sebagai permulaan, tema gelap alat pengembang GitHub (bawaan, Anda hanya perlu mengaktifkannya) dan tema Gelap Atom One untuk Chrome.

Bitbucket

Sebenarnya, ini tidak sepenuhnya tepat di sini, tapi saya tidak bisa tidak menyebutkan Bitbucket. Dua tahun lalu saya memulai sebuah proyek dan menghabiskan setengah hari memilih hosting git terbaik. Jadi, Bitbucket menang dengan selisih yang signifikan. Saluran peninjauan kode mereka jauh lebih maju dibandingkan pesaingnya (ini terjadi jauh sebelum GitHub memiliki konsep peninjau). Sejak itu, GitHub juga memperoleh ulasan. Sayangnya, saya belum sempat menggunakan Bitbucket selama setahun terakhir - mungkin mereka sudah bergerak maju lagi. Jadi saya menyarankan mereka yang bertanggung jawab memilih layanan hosting git juga memperhatikan Bitbucket.

Kesimpulan

Itu saja! Saya harap saya dapat memberi tahu Anda setidaknya tiga hal yang sebelumnya tidak Anda ketahui. Dan saya juga berharap Anda bersenang-senang membaca artikel saya.