GitHub-ning 12 ta ajoyib xususiyatlari

Hayotim uchun men hech qanday intro haqida o'ylay olmayman, shuning uchun ...

#1 GitHub.com saytidagi tahrirlash kodi

Men hamma biladigan narsadan boshlayman (garchi men bir hafta oldin bu haqda hech qanday tasavvurga ega bo'lmaganman). GitHub-da, istalgan omborda istalgan matn faylini ko'rayotganda, yuqori o'ng tomonda kichik qalamni ko'rishingiz mumkin. Agar siz uni bossangiz, ushbu faylni tahrirlashingiz mumkin. Tugallangach, "Faylni o'zgartirishni taklif qilish" tugmasini bosing va GitHub vilka va Pull so'rovini yaratadi. Ajoyib, shunday emasmi? U vilkani o'zi yaratadi! Kodni o'zingizga yuklash va o'zingizga yuklash, mahalliy o'zgartirishlar kiritish va uni GitHub-ga Pull so'rovi bilan qaytarib yuborishning hojati yo'q. Agar minimal tahrir qilish kerak bo'lsa, juda qulay. juda haqiqiy Pull so'rovi emas

№2 Tasvirlarni kiritish

Muammolarning tavsifi faqat matnli sharhlar bilan cheklanmaydi. Tasvirlarni to'g'ridan-to'g'ri clipboarddan joylashtirishingiz mumkinligini bilarmidingiz? Joylashtirilganda, siz uning yuklanganini (shubhasiz bulutga) va tasvirni ko'rsatish uchun belgiga aylantirilganini ko'rasiz. Ajoyib!

№3 Kodni formatlash

Agar siz kod blokini yozishingiz kerak bo'lsa, uchta orqa belgidan boshlang va GitHub qaysi dasturlash tilida yozayotganingizni taxmin qilishga harakat qiladi. Ammo agar siz Vue, Typescript yoki JSX kabi dasturlash tilida kod parchasini joylashtirsangiz, sintaksisni ta'kidlash to'g'ri bo'lishi uchun tilni aniq belgilashingiz mumkin. Birinchi qatordagi ``` jsx ga e'tibor bering: ... kod parchasining to'g'ri ko'rsatilishini ta'minlash: (Aytgancha, bu Gist uchun ham amal qiladi. Agar gist uchun .jsf kengaytmasini belgilasangiz, JSF sintaksisi ta'kidlanadi). Bu erda barcha qo'llab-quvvatlanadigan sintaksislar ro'yxati .

#4 Pull so'rovlarida "sehrli so'zlar" yordamida muammolarni yopish

Aytaylik, siz №234-muammoni tuzatuvchi Pull So'rovini yaratdingiz. Siz so'rovingiz tavsifiga (yoki o'zgartirish so'rovining istalgan joyiga) "234-muammoni tuzatish" matnini kiritishingiz mumkin. Shundan so'ng, Pull So'rovini birlashtirish muammoni "avtomatik ravishda" yopadi. Ajoyib, shunday emasmi? Hujjatlarda bu haqda ko'proq ma'lumot mavjud .

#5 Fikrlarga havola

Hech qachon ma'lum bir izohga havola yaratishingiz kerak bo'lganmi va buni qanday qilishni bilmadingizmi? O'sha kunlar o'tib ketdi, chunki men sizga sirni ochaman: izohga havola yaratish uchun sarlavha yonidagi sana/vaqtni bosish kifoya. Qarang, endi Gaearonning surati bor!

№6 kod havolasi

Shunday qilib, siz ma'lum bir kod qatoriga havola yaratmoqchisiz. Bunday holda, buni sinab ko'ring: ochiq faylda kerakli kod yonidagi qator raqamini bosing. Voy, qarangmi? URL o'zgardi, qator raqami endi unda ko'rinadi! Agar siz SHIFT tugmachasini bosib ushlab tursangiz va boshqa qator raqamini bossangiz, voila! – URL yana oʻzgaradi va qatorlar oraligʻi taʼkidlanadi. Bu URL endi ushbu faylga va qatorlar qatoriga ishora qiladi. Lekin kuting, u joriy mavzuga ishora qiladi. Agar fayl o'zgarsa nima bo'ladi? Ehtimol, bu holda faylga hozirgi holatida doimiy havola kerak bo'ladi. Men juda dangasaman, shuning uchun yuqoridagilarning barchasidan bitta skrinshot oldim: Aytgancha, URL manzillar haqida...

#7 GitHub URL manzilidan buyruq qatori sifatida foydalanish

UI yordamida GitHub orqali navigatsiya qilish juda qulay tarzda tashkil etilgan. Ammo ba'zida ma'lum bir joyga borish uchun uni URL manziliga kiritish tezroq bo'ladi. Misol uchun, agar men ishlayotgan filialga borib, uning master bilan qanday solishtirilishini ko'rmoqchi bo'lsam, ombor nomidan keyin oddiygina /qiyoslash/branchname yozishim mumkin. Bu meni ushbu filialning farq sahifasiga olib boradi: Lekin bular asosiy filialdan farqlar, lekin agar men ilgari integratsiya boʻlimi bilan ishlagan boʻlsam, URL-ga /compare/integration-branch...my-branch ni kiritishim mumkin. Tezkor tugmachalarni sevuvchilar uchun: CTRL+L yoki CMD+L kursorni URL satriga olib boradi (hech bo'lmaganda Chrome va Firefox brauzerlarida). Bu brauzerni avtoto'ldirish bilan birgalikda filiallar o'rtasida navigatsiyani ancha osonlashtiradi. Maslahat: Chrome avtomatik toʻldirish takliflari boʻylab harakatlanish uchun oʻqlardan foydalaning va tarixdan elementlarni olib tashlash uchun (masalan, filialni birlashtirgandan keyin) SHIFT+DELETE tugmalarini bosing. (Men SHIFT + DELETE kabi bo'sh joy qo'ysam, ushbu yorliqlarni o'qish osonroq bo'ladimi yoki yo'qligini bilmayman. Lekin texnik jihatdan "+" ularning bir qismi emas, shuning uchun menga bu variant yoqmaydi. Bu Shu kabi narsalar tufayli kechalari uxlamayman, Ronda.)

№8 Muammolar ro'yxatini yarating

Muammo tavsifida belgilash katakchasini xohlaysizmi? Ro‘yxatdagi muammoni ko‘rganingizda “5 dan 2 tasi” kabi ajoyib chiziq paydo bo‘lishini xohlaysizmi? Hammasi joyida! Quyidagi sintaksisdan foydalanib, interaktiv katakchalarni yaratishingiz mumkin:

• [ ] Ekran kengligi (butun son)
• [x] Xizmat xodimlarini qo'llab-quvvatlash
• [x] Yordamni olish
• [ ] CSS flexbox-ni qo'llab-quvvatlash
• [ ] Maxsus elementlar

Sintaksis: bo'shliq, defis, bo'sh joy, ochiladigan kvadrat qavs, bo'sh joy (yoki x), yopilish kvadrat qavs, bo'sh joy va ba'zi so'zlar. Shundan so'ng, siz ushbu tugmalarni tekshirishingiz/belgidan olib tashlashingiz mumkin! Negadir bu menga qandaydir texnik sehrdek tuyuladi. Siz katakchalarni belgilashingiz mumkin! Va ayni paytda asl matn o'zgaradi! Ularning keyin nima qilishini o'ylash qo'rqinchli. Oh, va agar bu muammo loyiha panelida bo'lsa, u erda taraqqiyot ham ko'rsatiladi: Agar siz "loyiha paneli" deganda nimani nazarda tutayotganimni tushunmasangiz - quyida o'qing. Bu sahifada bir necha santimetr pastroq.

GitHub-dagi №9 loyiha panellari

Katta loyihalar uchun men doimo Jira-dan foydalanganman. Va shaxsiy loyihalarim uchun men har doim Trello-dan foydalanganman. Menga bu ikkala vosita juda yoqadi. Bir necha hafta oldin GitHub o'z variantini taklif qilganini bilganimda, to'g'ridan-to'g'ri omborning Loyihalar yorlig'ida , men Trelloda ishlayotgan vazifalar to'plamini takrorlash mantiqiy deb o'yladim. Bu erda hech qanday kulgili narsa yo'q. Endi GitHub loyihasida ham xuddi shunday: Sekin-asta ko'zlaringiz past kontrastli tasvirga o'rganib qoladi Tezlik uchun men yuqoridagilarning barchasini eslatma sifatida qo'shdim, ya'ni ular "haqiqiy" GitHub muammolari emas. Ammo GitHub-da muammolarni boshqarishning kuchi uning boshqa omborlar bilan integratsiyalashuvida yotadi - shuning uchun mavjud muammolarni ombordan asboblar paneliga qo'shish yaxshiroqdir. Yuqori o'ng burchakdagi "Kartalarni qo'shish" tugmasini bosing va qo'shmoqchi bo'lgan narsani toping. Bu erda maxsus qidiruv sintaksisi yordam beradi : masalan, is :pr is:open yozing va siz istalgan ochiq Pull So'rovini panelga sudrab o'tishingiz mumkin yoki xatolarni tuzatishingiz kerak bo'lsa label:bug . Bundan tashqari, mavjud eslatmalarni muammolarga aylantirishingiz mumkin. Va nihoyat, mavjud muammo shaklidan uni o'ng paneldagi loyihaga qo'shing. U ushbu loyiha panelining triaj ro'yxatiga kiradi, shuning uchun uni qaysi ustunga qo'yishni tanlashingiz mumkin Agar "vazifa" ning tavsifi ushbu vazifani amalga oshiradigan kod bilan bir xil omborda bo'lsa, bu juda (juda) qulay. Bu shuni anglatadiki, ko'p yillar o'tgach, siz Jira/Trello/boshqa joyda hammasini kuzatmasdan turib, kod qatorida git blame-ni ishga tushirishingiz va ushbu qatorga olib kelgan muammoni to'liq aniqlashingiz mumkin bo'ladi .

Kamchiliklar

So'nggi uch hafta davomida men Jira o'rniga (kichik loyihada, Kanban uslubida) hamma narsani GitHub'da qilishni sinab ko'rdim va uni yaxshi ko'raman. Ammo men buni Scrum loyihasi uchun tasavvur qila olmayman, bu erda rivojlanish tezligi va shunga o'xshash narsalarni to'g'ri baholash va hisoblash kerak. Yaxshi xabar shundaki, GitHub loyihalarida juda kam "maxsus xususiyatlar" mavjudki, boshqa tizimga o'tish ko'p vaqtni talab qilmaydi. Shunday qilib, sinab ko'ring va sizga qanchalik yoqqanini ko'ring. Bu qanchalik muhimligini bilmayman, lekin men ZenHub haqida eshitdim va uni birinchi marta 10 daqiqa oldin ochdim. Bu GitHub-ning kengaytmasi bo'lib, unda siz muammolarni baholashingiz va "epiklar" va bog'liqliklarni yaratishingiz mumkin. Rivojlanish tezligi va charchash grafiklari mavjud; Bu shunchaki ajoyib narsaga o'xshaydi. Qo'shimcha o'qish: Loyihalar bo'yicha GitHub hujjatlari.

#10 Gwiki

Vikipediya kabi tuzilmagan sahifalar toʻplami uchun GitHub Wiki (men hozir uni Gwiki deb atayman) juda yaxshi. Tuzilgan sahifalar to'plami uchun - masalan, hujjatlaringiz kabi - unchalik ko'p emas. "Ushbu sahifa o'sha sahifaning bolasi" ekanligini ko'rsatishning hech qanday usuli yo'q, "Keyingi bo'lim" va "Oldingi bo'lim" tugmalari kabi qulay narsalar mavjud emas. Hansel va Gretel, albatta, bu erda yo'qolib ketishadi, chunki bu erda ham "non bo'laklari" (maxsus disk raskadrovka operatorlari - taxminan trans.) yo'q. (Muallifning eslatmasi: Siz bu voqeani o‘qidingizmi ? Bu shunchaki g‘ayriinsoniy. Ikki yosh bezori kambag‘al och kampirni o‘ldirib, uni o‘z pechida tiriklayin yoqib yubordi . Va, albatta, hech kim tushunmasligi uchun butunlay tartibsizlikni qoldirdi. Menimcha, shuning uchun ham. Hozirgi yoshlar jahannamdek sezgir – bolalarga uxlashdan oldin o‘qiladigan hikoyalar hozirgi kunlarda shafqatsiz emas!) Davom etaman – Gwiki-ni haqiqatda sinab ko‘rish uchun NodeJS’dan bir nechta sahifalarni wiki sahifalari sifatida kiritdim, keyin esa maxsus yaratdim. saytning haqiqiy tuzilishini taqlid qilish uchun yon panel. Joriy sahifa ajratib ko'rsatilmagan bo'lsa-da, bu yon panel har doim mavjud. Aloqalarni qo'lda saqlash kerak bo'ladi, lekin umuman hamma narsa yaxshi ishlaydi. Agar xohlasangiz, ko'rib chiqishingiz mumkin : Bu GitBook ( Redux hujjatlarida qo'llaniladigan ) yoki buyurtma veb-sayt kabi narsalar bilan deyarli raqobatlasha olmaydi. Ammo bu allaqachon yaxshi 80% va sizning omboringizda hamma narsa to'g'ri. Men shunchaki buning muxlisiman. Agar siz bitta README.md faylidan oshib ketgan bo'lsangiz va foydalanuvchi qo'llanmalari yoki batafsilroq hujjatlar uchun bir nechta turli sahifalarga muhtoj bo'lsangiz, Gwiki-ga yopishib olishingizni maslahat beraman. Agar tuzilma/navigatsiya etishmasligi sizni bezovta qilsa, boshqa narsaga o'ting.

№11 GitHub sahifalari

GitHub sahifalaridan statik veb-saytni joylashtirish uchun foydalanish mumkinligini allaqachon bilishingiz mumkin. Va agar bilmagan bo'lsangiz, endi bilasiz. Biroq, ushbu bo'lim aniqroq mavzuga bag'ishlangan: veb-sayt yaratish uchun Jekyll-dan foydalanish. Eng oddiy ko'rinishida GitHub Pages + Jekyll README.md faylini chiroyli ko'rinadigan mavzu yordamida ko'rsatishi mumkin. Masalan, about-github dan mening readme sahifamga qarang : Agar siz ushbu GitHub sayti uchun sozlamalar yorlig'ini bossangiz, GitHub sahifalarini yoqing va Jekyll mavzusini tanlang... Keyin biz Jekyll mavzusi uslubidagi sahifani olamiz : Keyin siz asosan oson tahrirlanadigan belgilash fayllariga asoslangan butun statik sayt yaratishingiz mumkin, bu esa GitHub-ni CMS-ga aylantiradi. Garchi men buni amalda ishlatmagan bo'lsam ham, veb-saytlar React yordamida Bootstrap tizimidan foydalangan holda shunday qurilgan, shuning uchun buning hech qanday dahshatli joyi yo'q. Shuni taʼkidlaymanki, Ruby mahalliy kompyuterda ishlayotgan boʻlishi kerak (Windows foydalanuvchilari bu yerda bir-birini tushunishadi va boshqa yoʻldan borishadi, macOS foydalanuvchilari: “Muammo nimada, qayerga ketyapsan? Ruby universal platforma! GEMS ham bor. paketlarni boshqarish tizimi!”) (Shuningdek, GitHub sahifalarida “Agressiv yoki tahdidli kontent yoki xatti-harakatlar”ga ruxsat berilmaganligini ham taʼkidlash joiz, shuning uchun siz Hansel va Gretel hikoyasining oʻz versiyasini u yerda joylashtira olmaysiz).

Mening fikrim

Men GitHub Pages + Jekyll kombinatsiyasiga (ushbu maqola uchun) qanchalik ko'p qaragan bo'lsam, bu g'oyaning g'alati hidi paydo bo'ldi deb o'yladim. "O'z veb-saytingizni minimal kuch bilan yaratish" g'oyasi ajoyib. Ammo u bilan ishlash uchun siz hali ham mahalliy kompyuterda joriy versiyaga muhtojmiz. Va juda "oddiy" narsa uchun buyruq qatori buyruqlari juda ko'p. Ishga kirishish bo'limidagi yetti sahifani ko'zdan kechirdim va bu boradagi yagona narsa men ekanligimni his qildim . Va men hatto asosiy sahifaning oddiy sintaksisini yoki oddiy "Suyuq tilga asoslangan shablonni yaratish mexanizmi" asoslarini tushunmadim. Men o'zim veb-sayt yozishni afzal ko'raman! Rostini aytsam, Facebook buni React hujjatlari uchun ishlatayotganidan hayratdaman, chunki ular React yordamida yordam tizimi sahifalarini yaratishi va har kuni statik HTML fayllari sifatida oldindan ko'rsatishi mumkin edi . Ular qilishlari kerak bo'lgan narsa - mavjud belgilash fayllarini xuddi CMSdan kelgandek qabul qilish yo'lini topishdir. Agar .. bo'lsa nima bo'ladi...

#12 GitHub-dan CMS sifatida foydalanish

Aytaylik, bizda matnli veb-sayt bor, lekin biz bu matnni HTML belgisi sifatida saqlashni xohlamaymiz. Buning o'rniga, biz dasturchi bo'lmagan foydalanuvchilar tomonidan osonlik bilan tahrirlanishi mumkin bo'lgan matn qismlarini saqlashni xohlaymiz. Tercihen ba'zi versiya variantlari bilan. Ehtimol, ba'zi bir ko'rib chiqish jarayoni bilan ham. Men taklif qiladigan narsa: matnni saqlash uchun omborda saqlangan belgilash fayllaridan foydalaning. Va mijoz tomonida ushbu matn qismlarini oladigan va ularni sahifada ko'rsatadigan komponentdan foydalaning. Men React muxlisiman, shuning uchun bu erda tegishli <Markdown> komponentining misoli keltirilgan, u markdown fayliga yo'l berilganda uni ajratib oladi, tahlil qiladi va HTML sifatida ko'rsatadi.

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)}} />
      );
    }
}

(HTML formatidagi belgilarni tahlil qilish uchun bu yerda npm belgilangan paketidan foydalanaman ) URL manzili /text-snippets katalogidagi belgilash fayllarini o‘z ichiga olgan mening namunaviy omborimga ishora qiladi . ( Kontentni olish uchun GitHub API dan ham foydalanishingiz mumkin , lekin bu sizga kerak boʻlishiga shubha qilaman.) Siz shunga oʻxshash komponentdan foydalanishingiz mumkin:

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>
);

Shunday qilib, endi GitHub qaysidir ma'noda siz joylashtirmoqchi bo'lgan matn qismlari uchun CMS sifatida ishlaydi. Yuqoridagi misol faqat komponent brauzerga yuklangandan keyin belgilashni oladi. Agar sizga statik sayt kerak bo'lsa, uni serverda ko'rsatishingiz kerak bo'ladi. Xush habar! Serverdagi barcha belgilash fayllarini olishingizga hech narsa to'sqinlik qilmaydi (sizga yoqqan har qanday keshlash strategiyasidan foydalaning). Agar siz ushbu yo'ldan borishga qaror qilsangiz, katalogdagi barcha belgilash fayllari ro'yxatini olish uchun GitHub API-dan foydalanish mantiqan to'g'ri keladi. Bonus - GitHub yordam dasturlari! Men Octotree Chrome kengaytmasidan anchadan beri foydalanaman va uni sizga tavsiya qilaman. Rezervasyonlarsiz emas, lekin men buni hali ham tavsiya qilaman. U chap tomonda siz ko'rayotgan omborning daraxt ko'rinishidagi panelni ko'rsatadi. Va bu videodan men octobox haqida bilib oldim , bu ham menga hozirgacha juda yaxshi yordamchi dastur bo'lib tuyuladi. Bu sizning GitHub muammolaringiz uchun pochta qutisi. U haqida bilishingiz kerak bo'lgan hamma narsa shu. Ranglar haqida gapiradigan bo'lsak, men sizni qo'rqitmaslik uchun yuqoridagi barcha skrinshotlarni engil mavzuda oldim. Ammo men hamma narsada quyuq ranglarni afzal ko'rsam, nega o'lik rangpar GitHubga chidash kerak? Bu erda men Chrome brauzeri uchun Stylish kengaytmasi (har qanday veb-saytga mavzularni qo'llashi mumkin) va GitHub Dark uslubining kombinatsiyasidan foydalandim . Yangi boshlanuvchilar uchun GitHub ishlab chiquvchi asboblari qorong‘u mavzu (ichiga o‘rnatilgan, uni yoqishingiz kifoya) va Chrome uchun Atom One Dark mavzusi .

Bitbuket

To'g'risini aytganda, bu erda mutlaqo mos emas, lekin men Bitbucketni eslatib o'tolmayman. Ikki yil oldin men loyihani boshladim va yarim kun davomida eng yaxshi git hostingni tanladim. Shunday qilib, Bitbucket sezilarli farq bilan g'alaba qozondi. Ularning kodni ko'rib chiqish liniyasi raqobatdan ancha oldinda (bu GitHub hatto sharhlovchi tushunchasiga ega bo'lishidan ancha oldin edi). O'shandan beri GitHub ham sharhlarni oldi. Afsuski, o'tgan yil davomida menda Bitbucket-dan foydalanish imkoniyati bo'lmadi - ehtimol ular yana biror narsada oldinga siljishgan. Shuning uchun men git hosting xizmatini tanlashga mas'ul bo'lganlarga Bitbucket-ga ham e'tibor berishni tavsiya qilaman.

Xulosa

Ana xolos! Umid qilamanki, men sizga ilgari noma'lum bo'lgan kamida uchta narsani aytib bera oldim. Shuningdek, mening maqolamni o'qib yaxshi vaqt o'tkazdingiz degan umiddaman.