GitHub-ın 12 heyrətamiz xüsusiyyəti

Həyatım üçün heç bir intro düşünə bilmirəm, ona görə də...

#1 GitHub.com-da redaktə kodu

Hər kəsin artıq bildiyini düşündüyüm şeylə başlayacağam (baxmayaraq ki, bir həftə əvvəl şəxsən bu barədə heç bir fikrim yox idi). GitHub-da hər hansı bir anbarda hər hansı mətn faylına baxarkən yuxarı sağda kiçik bir karandaş görə bilərsiniz. Bunun üzərinə klikləsəniz, bu faylı redaktə edə bilərsiniz. Tamamlandıqdan sonra Fayl dəyişikliyini təklif et klikləyin və GitHub çəngəl yaradacaq və Sorğu çəkəcək. Təəccüblüdür, elə deyilmi? Çəngəli özü yaradır! Kodu çəngəlləyib özünüzə yükləməyə, yerli olaraq dəyişikliklər etməyə və Pull Sorğu ilə GitHub-a geri göndərməyə ehtiyac yoxdur. Minimum redaktə etmək lazımdırsa, çox rahatdır. tamamilə real Pull Sorğu deyil

#2 Şəkillərin daxil edilməsi

Problemin təsviri yalnız mətn şərhləri ilə məhdudlaşmır. Şəkilləri birbaşa panodan yapışdıra biləcəyinizi bilirdinizmi? Yerləşdirildikdə, onun yükləndiyini (şübhəsiz ki, buludda) və şəkli göstərmək üçün işarəyə çevrildiyini görəcəksiniz. Zərif!

#3 Kodun formatlaşdırılması

Bir kod bloku yazmağınız lazımdırsa, üç geri işarə ilə başlayın və GitHub hansı proqramlaşdırma dilində yazdığınızı təxmin etməyə çalışacaq. Ancaq Vue, Typescript və ya JSX kimi proqramlaşdırma dilində kod parçasını yerləşdirirsinizsə, sintaksisin vurğulanmasının düzgün olması üçün dili açıq şəkildə təyin edə bilərsiniz. Birinci sətirdəki ```jsx-ə diqqət yetirin: ...kod parçasının düzgün göstərilməsini təmin etmək: (Yeri gəlmişkən, bu, Gist-ə də aiddir. Əgər siz əsas üçün .jsf genişlənməsini təyin etsəniz, JSF sintaksisi vurğulanacaq). Burada bütün dəstəklənən sintaksislərin siyahısı verilmişdir .

# 4 Çəkmə sorğularında "sehrli sözlər" istifadə edərək problemlərin bağlanması

Tutaq ki, siz 234-cü məsələni həll edən Pull Sorğu yaratdınız. Sorğunuzun təsvirinə (və ya hər hansı dəyişiklik sorğusu şərhinin istənilən yerinə) "234 nömrəli problemi həll edir" mətnini daxil edə bilərsiniz. Bundan sonra, Pull Sorğunun birləşdirilməsi problemi "avtomatik olaraq" bağlayacaqdır. Əla, elə deyilmi? Bu barədə sənədlərdə daha çox məlumat var .

#5 Şərhlərə keçid

Heç vaxt konkret şərhə keçid yaratmağa ehtiyacınız olub və necə olduğunu bilmirsiniz? O günlər çoxdan geridə qaldı, çünki mən sizə bir sirri açacağam: Şərhə keçid yaratmaq üçün sadəcə başlığın yanındakı tarix/saat üzərinə klikləyin. Bax, gaearon indi şəkli var!

#6 Kod bağlantısı

Beləliklə, müəyyən bir kod xəttinə keçid yaratmaq istəyirsiniz. Bu halda, bunu cəhd edin: Açıq faylda istədiyiniz kodun yanındakı sətir nömrəsinə klikləyin. Vay, bax? URL dəyişdi, sətir nömrəsi indi orada görünür! SHIFT düyməsini basıb saxlayın və başqa sətir nömrəsinə klik etsəniz, voila! – URL yenidən dəyişəcək və sıra aralığı vurğulanacaq. Bu URL indi bu faylı və bu sətir aralığını göstərəcək. Ancaq gözləyin, o, cari mövzuya işarə edir. Fayl dəyişsə nə olacaq? Çox güman ki, bu halda, mövcud vəziyyətdə olan fayla daimi keçid lazımdır. Mən çox tənbələm, ona görə də yuxarıdakıların hamısından bir skrinşot çəkdim: Yeri gəlmişkən, URL-lər haqqında...

#7 GitHub URL-dən Komanda Xətti kimi istifadə

UI istifadə edərək GitHub vasitəsilə naviqasiya çox rahat şəkildə təşkil olunub. Ancaq bəzən müəyyən bir yerə çatmaq üçün onu sadəcə URL-ə daxil etmək daha sürətli olur. Məsələn, işlədiyim filiala getmək və onun master ilə necə müqayisə edildiyini görmək istəsəm, deponun adından sonra sadəcə /müqayisə/branchname yaza bilərəm. Bu, məni həmin filial üçün fərq səhifəsinə aparacaq: Amma bunlar master filialdan fərqlərdir, lakin mən əvvəl inteqrasiya filialı ilə işləmişəmsə, URL-də /müqayisə/inteqrasiya-branch...my-branch daxil edə bilərəm. İsti düymələri sevənlər üçün: CTRL+L və ya CMD+L kursoru URL çubuğuna aparır (ən azı Chrome və Firefox brauzerlərində). Bu, brauzerin avtomatik tamamlanması ilə birlikdə filiallar arasında naviqasiyanı çox asanlaşdırır. İpucu: Chrome-un avtomatik tamamlama təklifləri arasında getmək üçün oxlardan istifadə edin və elementləri tarixçədən silmək üçün SHIFT+DELETE düymələrini basın (məsələn, filialı birləşdirdikdən sonra). (Bilmirəm, SHIFT + DELETE kimi boşluq qoysam, bu qısayol düymələrini oxumaq daha asan olardı. Amma texniki cəhətdən “+” onların bir hissəsi deyil, ona görə də bu seçimi bəyənmirəm. Bu bu kimi şeylərə görə gecələr yatmıram, Rhonda.)

#8 Problemlər üçün siyahılar yaradın

Probleminizin təsvirində qeyd qutusunu istəyirsiniz? Siyahıdan bir məsələyə baxdığınız zaman “5-dən 2-si” kimi gözəl bir çubuğun görünməsini istəyirsiniz? Problem deyil! Aşağıdakı sintaksisdən istifadə edərək interaktiv onay qutuları yarada bilərsiniz:

• [ ] Ekran eni (tam)
• [x] Xidmət işçisi dəstəyi
• [x] Dəstəyi gətirin
• [ ] CSS flexbox dəstəyi
• [ ] Fərdi elementlər

Sintaksis: boşluq, defis, boşluq, açılış kvadrat mötərizə, boşluq (və ya x), bağlanan kvadrat mötərizə, boşluq və bəzi sözlər. Bundan sonra, həqiqətən bu düymələri yoxlaya / işarəni silə bilərsiniz! Nədənsə bu, mənə bir növ texniki sehr kimi görünür. Qutuları işarələyə bilərsiniz! Və eyni zamanda orijinal mətn dəyişir! Bundan sonra nə ilə qarşılaşacaqlarını düşünmək qorxuncdur. Oh, bu problem layihə panelindədirsə, irəliləyiş orada da göstəriləcək: Əgər "layihə paneli" dedikdə nəyi nəzərdə tutduğumu başa düşmürsənsə - aşağıda oxuyun. Bu səhifədə cəmi bir neçə santimetr aşağıdır.

GitHub-da #9 Layihə panelləri

Böyük layihələr üçün həmişə Jira-dan istifadə etmişəm. Şəxsi layihələrim üçün isə həmişə Trello-dan istifadə etmişəm. Bu alətlərin hər ikisini çox bəyənirəm. Bir neçə həftə əvvəl GitHub-un öz seçimini təklif etdiyini öyrənəndə anbarın Layihələr sekmesinde artıq Trello-da işlədiyim tapşırıqlar toplusunu təkrarlamağın mənası olduğunu düşündüm. Burada gülməli heç nə yoxdur. İndi də GitHub layihəsində eyni şey: Tədricən gözləriniz aşağı kontrastlı görüntüyə alışacaq Sürət naminə yuxarıdakıların hamısını qeydlər kimi əlavə etdim, yəni onlar "real" GitHub problemləri deyil. Lakin GitHub-da məsələnin idarə edilməsinin gücü onun deponun qalan hissəsi ilə inteqrasiyasındadır – ona görə də, yəqin ki, mövcud məsələləri repozitoriyadan idarə panelinə əlavə etmək daha yaxşıdır. Yuxarı sağ küncdəki Kartları əlavə et üzərinə klikləyin və əlavə etmək istədiyinizi tapın. Burada xüsusi axtarış sintaksisi kömək edir : məsələn, yazın : pr is:open və siz istənilən açıq Pull Sorğunu panelə və ya bəzi səhvləri düzəltmək lazımdırsa label:bug üzərinə sürükləyə bilərsiniz. Siz həmçinin mövcud qeydləri məsələlərə çevirə bilərsiniz. Və nəhayət, mövcud problem formasından onu sağ paneldəki layihəyə əlavə edin. O, həmin layihə panelinin triaj siyahısına daxil olacaq, beləliklə, onu hansı sütuna qoyacağınızı seçə bilərsiniz “Tapşırığın” təsviri bu tapşırığı həyata keçirən kodla eyni depoda olduqda, bu, çox (çox) rahatdır. Bu o deməkdir ki, indidən uzun illər sonra siz Jira/Trello/başqa yerdə hər şeyi izləmək məcburiyyətində qalmadan kod sətirində git blame işlədə və bu xəttə gətirib çıxaran problemin arxasında tam hekayəni anlaya biləcəksiniz. .

Qüsurlar

Son üç həftə ərzində mən Jira əvəzinə GitHub-da hər şeyi (kiçik bir layihədə, Kanban üslubunda) etməyi sınadım və onu sevdim. Ancaq inkişaf sürətinin və buna bənzər şeylərin düzgün qiymətləndirilməsi və hesablanması lazım olan bir Scrum layihəsi üçün bunu təsəvvür edə bilmirəm. Yaxşı xəbər budur ki, GitHub layihələrinin o qədər az “xüsusi xüsusiyyətləri” var ki, başqa sistemə keçid çox vaxt aparmayacaq. Odur ki, cəhd edin və nə qədər bəyəndiyinizə baxın. Bunun nə qədər vacib olduğunu bilmirəm, amma ZenHub haqqında eşitdim və ilk dəfə 10 dəqiqə əvvəl açdım. Bu, mahiyyətcə GitHub-ın genişləndirilməsidir, burada məsələləri qiymətləndirə və "dastanlar" və asılılıqlar yarada bilərsiniz. İnkişaf sürəti və tükənmə qrafikləri var; Bu sadəcə heyrətamiz bir şey kimi görünür. Əlavə oxu: Layihələr üzrə GitHub sənədləri.

#10 Qviki

Vikipediya kimi strukturlaşdırılmamış səhifələr dəsti üçün GitHub Wiki (bundan sonra onu Gwiki adlandıracağam) əladır. Strukturlaşdırılmış səhifələr dəsti üçün - məsələn, sənədləriniz kimi - o qədər də çox deyil. “Bu səhifə həmin səhifənin övladıdır” deməyin heç bir yolu yoxdur, “Növbəti bölmə” və “Əvvəlki bölmə” düymələri kimi rahat şeylər yoxdur. Hansel və Gretel burada mütləq itəcəkdilər, çünki burada da “çörək qırıntıları” (xüsusi sazlama operatorları - təqribən trans.) yoxdur. (Müəllifin qeydi: Bu hekayəni oxumusunuz ? Bu, sadəcə olaraq, qeyri-insanidir. İki gənc quldur kasıb ac qoca qadını öldürür, onu öz sobasında diri-diri yandırır . Və təbii ki, heç kimin başa düşməməsi üçün tam bir qarışıqlıq qoyurlar. Məncə, buna görədir. İndiki gənclər cəhənnəm kimi həssasdırlar – bu günlərdə uşaqlara yatmazdan əvvəl oxunan hekayələr kifayət qədər qəddar deyil!) İrəliləyərək – Gwiki-ni real olaraq sınamaq üçün NodeJS-dən bir neçə səhifəyə wiki səhifələri kimi daxil oldum, sonra xüsusi bir səhifə yaratdım. saytın faktiki strukturunu simulyasiya etmək üçün yan panel. Cari səhifə vurğulanmasa da, bu yan panel həmişə oradadır. Bağlantılar əl ilə saxlanılmalı olacaq, lakin ümumilikdə hər şey yaxşı işləyir. İstəyirsinizsə, baxa bilərsiniz : Bu, çətin ki, GitBook ( Redux sənədlərində istifadə olunur ) və ya sifarişli vebsayt kimi bir şeylə rəqabət edə bilər. Ancaq bu, artıq yaxşı 80% -dir və hər şey sizin deponuzdadır. Mən sadəcə bunun pərəstişkarıyam. Təklif edirəm ki, əgər tək README.md faylını ötüb keçmisinizsə və istifadəçi təlimatları və ya daha ətraflı sənədlər üçün bir neçə fərqli səhifəyə ehtiyacınız varsa, Gwiki ilə bağlı qalmaq məntiqlidir. Əgər strukturun/naviqasiyanın olmaması sizi narahat edirsə, başqa bir şeyə keçin.

#11 GitHub Səhifələri

Artıq bilirsiniz ki, GitHub Səhifələri statik veb saytı yerləşdirmək üçün istifadə edilə bilər. Əgər bilmirsinizsə, indi bilirsiniz. Bununla belə, bu bölmə daha konkret bir mövzuya həsr edilmişdir: veb-sayt yaratmaq üçün Jekyll-dən istifadə. Ən sadə formada GitHub Pages + Jekyll gözəl görünüşlü mövzudan istifadə edərək README.md faylını göstərə bilər. Məsələn, about-github- dan mənim readme səhifəmə nəzər salın : Bu GitHub saytının parametrlər sekmesine klikləsəniz, GitHub Səhifələrini aktivləşdirin və Jekyll mövzusunu seçin... Sonra Jekyll mövzusunun üslubunda bir səhifə alacağıq : Daha sonra siz GitHub-u CMS-ə çevirərək, əsasən asanlıqla redaktə edilə bilən işarələmə fayllarına əsaslanan bütün statik sayt yarada bilərsiniz. Mən əslində bundan istifadə etməsəm də, React istifadə edərək Bootstrap çərçivəsindən istifadə edərək vebsaytlar belə qurulur, buna görə də bunda qorxulu heç nə yoxdur. Qeyd edirəm ki, Ruby yerli maşında işləməlidir (Windows istifadəçiləri burada anlayışla nəzər salacaq və başqa yolla gedəcəklər, macOS istifadəçiləri deyəcəklər: "Problem nədir, hara gedirsən? Ruby universal platformadır! GEMS də var. paket idarəetmə sistemi!”) (Həmçinin qeyd etmək lazımdır ki, GitHub Səhifələrində “Təcavüzkar və ya hədələyici məzmun və ya davranış”a icazə verilmir, ona görə də Hansel və Gretel hekayəsi versiyasını orada yerləşdirə bilməyəcəksiniz).

Mənim fikrim

GitHub Səhifələri + Jekyll birləşməsinə (bu məqalə üçün) nə qədər çox baxsam, bütün fikrin qəribə qoxusunu bir o qədər çox düşündüm. "Minimum səylə öz veb saytınızı yaratmaq" ideyası əladır. Ancaq bunun üzərində işləmək üçün hələ də yerli maşındakı cari versiyaya ehtiyacınız var. Və belə "sadə" bir şey üçün çoxlu əmr satırı əmrləri var. Başlanğıc bölməsində yeddi səhifəni vərəqlədim və bu barədə sadə olan yeganə şeyin mən olduğunu hiss etdim . Mən hətta əsas səhifə üçün sadə sintaksisi və ya sadə “Maye dilə əsaslanan Şablonlama Mexanizmi”nin əsaslarını belə başa düşməmişəm. Özüm veb sayt yazmağı üstün tuturam! Düzünü desəm, Facebook-un bunu React sənədləri üçün istifadə etməsinə bir az təəccüblənirəm ki, onlar hər gün React-dən istifadə edərək yardım sistemi səhifələrini yarada və statik HTML faylları kimi əvvəlcədən göstərə bildilər . Onların etməli olduqları şey, mövcud işarələmə fayllarını CMS-dən gələn kimi qəbul etmək üçün bir yol tapmaqdır. Birdən...

#12 GitHub-dan CMS kimi istifadə

Tutaq ki, bəzi mətnləri olan vebsaytımız var, lakin biz həmin mətni HTML işarəsi kimi saxlamaq istəmirik. Əvəzində biz mətn hissələrini inkişaf etdirməyən istifadəçilər tərəfindən asanlıqla redaktə edilə bilən yerdə saxlamaq istərdik. Tercihen bəzi versiya variantları ilə. Bəlkə də bir növ həmyaşıdların nəzərdən keçirmə prosesi ilə. Təklif etdiyim budur: mətni saxlamaq üçün depoda saxlanan işarələmə fayllarından istifadə edin. Və müştəri tərəfində bu mətn hissələrini əldə edəcək və onları səhifədə göstərəcək bir komponentdən istifadə edin. Mən React-in pərəstişkarıyam, ona görə də burada düzgün <Markdown> komponentinin nümunəsi verilmişdir ki, ona markdown faylına yol verildikdə onu çıxaracaq, təhlil edəcək və HTML kimi göstərəcək.

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

(Mən HTML-də işarələməni təhlil etmək üçün burada npm ilə işarələnmiş paketdən istifadə edirəm ) URL /text-snippets kataloqunda işarələmə fayllarını ehtiva edən nümunə depoma işarə edir . ( Məzmunu əldə etmək üçün GitHub API-dən də istifadə edə bilərsiniz , lakin buna ehtiyacınız olacağına şübhə edirəm.) Bu kimi komponentdən istifadə edə bilərsiniz:

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

Beləliklə, indi GitHub, yerləşdirmək istədiyiniz mətn parçaları üçün CMS kimi fəaliyyət göstərir. Yuxarıdakı nümunə yalnız komponent brauzerə yükləndikdən sonra işarələməni alır. Əgər sizə statik sayt lazımdırsa, onu serverdə göstərməli olacaqsınız. Yaxşı xəbər! Serverdəki bütün işarələmə fayllarını əldə etməyə heç nə mane olmur (istədiyiniz hər hansı keşləmə strategiyasından istifadə etməklə). Bu marşrutla getmək qərarına gəlsəniz, kataloqdakı bütün işarələmə fayllarının siyahısını əldə etmək üçün GitHub API-dən istifadə etməyin mənası var. Bonus - GitHub utilitləri! Artıq bir müddətdir ki, Octotree Chrome genişləndirməsindən istifadə edirəm və onu sizə tövsiyə edirəm. Rezervasyon olmadan deyil, amma yenə də tövsiyə edirəm. O, baxdığınız anbarın ağac görünüşü ilə solda paneli göstərir. Və bu videodan mən octobox haqqında öyrəndim , bu da mənə indiyə qədər çox yaxşı bir köməkçi proqram kimi görünür. Bu, GitHub problemləriniz üçün gələnlər qutusudur. Onun haqqında bilmək lazım olan hər şey budur. Rənglərdən söz düşmüşkən, sizi qorxutmamaq üçün yuxarıda göstərilən bütün skrinşotları yüngül mövzuda çəkdim. Ancaq hər şeydə tünd rənglərə üstünlük verirəmsə, o zaman ölümcül solğun GitHub-a niyə dözüm? Burada mən Chrome brauzeri üçün Qəşəng genişləndirmə (hər hansı bir vebsayta mövzu tətbiq edə bilər) və GitHub Dark üslubunun birləşməsindən istifadə etdim . Başlayanlar üçün GitHub tərtibatçı alətləri qaranlıq mövzu (daxili, sadəcə onu aktivləşdirməlisiniz) və Chrome üçün Atom One Dark mövzusu .

Bitbucket

Düzünü desəm, burada tamamilə uyğun deyil, amma Bitbucket-i qeyd etməyə kömək edə bilmirəm. İki il əvvəl bir layihəyə başladım və yarım gün ərzində ən yaxşı git hostinqini seçdim. Beləliklə, Bitbucket əhəmiyyətli fərqlə qalib gəldi. Onların kodu nəzərdən keçirmə boru kəməri rəqabətdən xeyli irəlidədir (bu, GitHub-da rəyçi konsepsiyasına malik olmamışdan çox əvvəl idi). O vaxtdan bəri GitHub da rəylər əldə etdi. Təəssüf ki, son bir ildə Bitbucket-dən istifadə etmək şansım olmadı - bəlkə də onlar yenidən bir işdə irəlilədilər. Ona görə də tövsiyə edirəm ki, git hosting xidmətinin seçiminə cavabdeh olanlar Bitbucket-ə də diqqət yetirsinlər.

Nəticə

Hamısı budur! Ümid edirəm ki, sizə əvvəllər məlum olmayan ən azı üç şeyi deyə bildim. Həm də ümid edirəm ki, məqaləmi oxuyub xoş vaxt keçirdiniz.