12 Kamangha-manghang Mga Tampok ng GitHub

Para sa buhay ko, wala akong maisip na intro, kaya...

#1 Pag-edit ng code sa GitHub.com

Magsisimula ako sa kung ano ang sa tingin ko ay alam na ng lahat (bagaman ako mismo ay walang ideya tungkol dito noong isang linggo). Kapag tinitingnan ang anumang text file sa GitHub, sa anumang repositoryo, makakakita ka ng maliit na lapis sa kanang tuktok. Kung mag-click ka dito, maaari mong i-edit ang file na ito. Kapag kumpleto na, i-click ang Ipanukala ang pagbabago ng file at gagawa ang GitHub ng fork at Pull Request. Kamangha-manghang, hindi ba? Siya mismo ang gumagawa ng tinidor! Hindi na kailangang mag-fork at mag-upload ng code sa iyong sarili, gumawa ng mga pagbabago sa lokal at ipadala ito pabalik sa GitHub na may Hiling na Pull. Tunay na maginhawa kung kailangan mong gumawa ng kaunting mga pag-edit. hindi isang tunay na Hiling na Hilahin

#2 Paglalagay ng mga larawan

Ang mga paglalarawan ng problema ay hindi limitado sa mga text na komento lamang. Alam mo bang maaari kang mag-paste ng mga larawan nang direkta mula sa clipboard? Kapag na-paste, makikita mo itong na-upload (sa cloud, walang duda) at naging markup para ipakita ang larawan. Mabait!

#3 Pag-format ng code

Kung kailangan mong magsulat ng isang bloke ng code, magsimula sa tatlong backtick at susubukan ng GitHub na hulaan kung anong programming language ang iyong isinusulat. Ngunit kung nagpo-post ka ng isang piraso ng code sa isang programming language tulad ng Vue, Typescript, o JSX, maaari mong tahasang tukuyin ang wika upang tama ang pag-highlight ng syntax. Pansinin ang ```jsx sa unang linya: ... tinitiyak ang tamang pagpapakita ng snippet ng code: (Nalalapat din ito sa Gist, sa pamamagitan ng paraan. Kung tinukoy mo ang .jsf extension para sa isang gist, ang JSF syntax ay iha-highlight). Narito ang isang listahan ng lahat ng sinusuportahang syntax .

#4 Pagsasara ng mga problema gamit ang "magic words" sa Pull Requests

Sabihin nating gumawa ka ng Pull Request na nag-aayos ng isyu #234. Maaari mong ipasok ang tekstong "nag-aayos ng isyu #234" sa paglalarawan ng iyong kahilingan (o saanman sa anumang komento ng kahilingan sa pagbabago). Pagkatapos nito, ang pagsasama ng Pull Request ay "awtomatikong" magsasara ng problema. Astig, di ba? Narito ang higit pang impormasyon tungkol dito sa dokumentasyon .

#5 Link sa mga komento

Kinailangan mo na bang gumawa ng link sa isang partikular na komento at hindi mo alam kung paano? Ang mga araw na iyon ay matagal na dahil papayagan kita sa isang sikreto: Upang lumikha ng isang link sa isang komento, i-click mo lang ang petsa/oras sa tabi ng pamagat. Tingnan mo, may litrato na ngayon si gaearon!

#6 Code link

Kaya gusto mong lumikha ng isang link sa isang tiyak na linya ng code. Sa kasong ito, subukan ito: Mag-click sa numero ng linya sa tabi ng gustong code sa bukas na file. Wow, nakikita mo? Ang URL ay nagbago, ang numero ng linya ay makikita na dito! Kung pinindot mo ang SHIFT key at mag-click sa isa pang numero ng linya, pagkatapos ay voila! – Magbabago muli ang URL at mai-highlight ang hanay ng mga row. Ang URL na ito ay tuturo na ngayon sa file na ito at sa hanay ng mga linyang ito. Pero teka, tumuturo ito sa kasalukuyang thread. Paano kung magbago ang file? Malamang na kailangan mo, sa kasong ito, ng isang permanenteng link sa file sa kasalukuyang estado nito. Masyado akong tamad, kaya kumuha ako ng isang screenshot ng lahat ng nasa itaas: Siyanga pala, tungkol sa mga URL...

#7 Paggamit ng GitHub URL bilang Command Line

Ang pag-navigate sa pamamagitan ng GitHub gamit ang UI ay nakaayos nang napakaginhawa. Ngunit minsan, para makarating sa isang partikular na lokasyon, mas mabilis na i-type lang ito sa URL. Halimbawa, kung gusto kong pumunta sa isang branch na pinagtatrabahuhan ko at makita kung paano ito maihahambing sa master, maaari kong i-type lang ang /compare/branchname pagkatapos ng pangalan ng repository. Dadalhin ako nito sa diff page para sa branch na iyon: Ngunit ito ay mga pagkakaiba mula sa master branch, ngunit kung nagtrabaho ako sa integration branch dati, maaari kong ilagay ang /compare/integration-branch...my-branch sa URL Para sa mga mahilig sa hotkey: Inililipat ng CTRL+L o CMD+L ang cursor sa URL bar (kahit sa mga browser ng Chrome at Firefox). Ito, na sinamahan ng autocompletion ng browser, ay ginagawang mas madali ang pag-navigate sa pagitan ng mga sangay. Pro tip: Gamitin ang mga arrow upang mag-navigate sa mga suhestyon sa autocomplete ng Chrome, at pindutin ang SHIFT+DELETE upang alisin ang mga item sa history (halimbawa, pagkatapos pagsamahin ang isang sangay). (Hindi ko alam kung magiging mas madaling basahin ang mga shortcut key na ito kung maglalagay ako ng puwang sa mga ito, tulad ng SHIFT + DELETE. Ngunit sa teknikal na paraan, ang “+” ay hindi bahagi ng mga ito, kaya hindi ko gusto ang opsyong ito. Ito ay Dahil sa mga ganitong bagay hindi ako natutulog sa gabi, Rhonda.)

#8 Gumawa ng mga listahan para sa mga problema

Gusto mo ba ng checkbox sa paglalarawan ng iyong problema? At gusto mo bang lumitaw ang isang magandang bar tulad ng "2 sa 5" kapag tiningnan mo ang isang isyu mula sa listahan? Walang problema! Maaari kang lumikha ng mga interactive na checkbox gamit ang sumusunod na syntax:

• [ ] Lapad ng screen (integer)
• [x] Suporta ng manggagawa sa serbisyo
• [x] Kumuha ng suporta
• [ ] CSS flexbox support
• [ ] Mga custom na elemento

Syntax: space, hyphen, space, opening square bracket, space (o x), closing square bracket, space at ilang salita. Pagkatapos noon, maaari mo talagang suriin/i-uncheck ang mga button na ito! Para sa ilang kadahilanan, ito ay tila isang uri ng teknikal na mahika para sa akin. Maaari mong lagyan ng tsek ang mga kahon! At sa parehong oras ang orihinal na teksto ay nagbabago! Nakakatakot isipin kung ano ang susunod nilang gagawin. Oh, at kung ang problemang ito ay nasa panel ng proyekto, ang pag-unlad ay ipapakita din doon: Kung hindi mo naiintindihan ang ibig kong sabihin sa "panel ng proyekto" - basahin sa ibaba. Ilang sentimetro lang ang baba sa page na ito.

#9 Mga panel ng proyekto sa GitHub

Para sa malalaking proyekto palagi kong ginagamit si Jira. At para sa aking mga personal na proyekto, palagi kong ginagamit ang Trello. Talagang gusto ko ang parehong mga tool na ito. Nang malaman ko ilang linggo na ang nakalipas na ang GitHub ay nag-aalok ng sarili nitong opsyon, sa tab na Mga Proyekto ng repositoryo, naisip kong makatuwirang i-duplicate ang hanay ng mga gawain na nakatrabaho ko na sa Trello. Walang nakakatawa dito. At ngayon ang parehong bagay sa proyekto ng GitHub: Unti-unting masasanay ang iyong mga mata sa low-contrast na imahe Para sa kapakanan ng bilis, idinagdag ko ang lahat ng nasa itaas bilang mga tala, ibig sabihin ang mga ito ay hindi "tunay" na mga isyu sa GitHub. Ngunit ang kapangyarihan ng pamamahala ng isyu sa GitHub ay nakasalalay sa pagsasama nito sa natitirang repositoryo - kaya mas mabuting magdagdag ng mga umiiral nang isyu mula sa repositoryo sa dashboard. I-click ang Magdagdag ng Mga Card sa kanang sulok sa itaas at hanapin kung ano ang gusto mong idagdag. Dito magagamit ang isang espesyal na syntax sa paghahanap : halimbawa, ang uri ay:pr is:open at maaari mong i-drag ang anumang bukas na Pull Request sa panel, o label:bug kung kailangan mong ayusin ang anumang mga error. Maaari mo ring i-convert ang mga kasalukuyang tala sa mga isyu. At sa wakas, mula sa umiiral na form ng problema, idagdag ito sa proyekto sa kanang panel. Mapupunta ito sa listahan ng triage ng panel ng proyektong iyon, para mapili mo kung saang column ito ilalagay Kapag ang paglalarawan ng isang "gawain" ay nasa parehong repository ng code na nagpapatupad ng gawaing ito, ito ay napaka (napaka) maginhawa. Nangangahulugan ito na maraming taon mula ngayon, magagawa mong patakbuhin ang git blame sa isang linya ng code at malaman ang kabuuan ng isyu na humantong sa linyang iyon, nang hindi kinakailangang subaybayan ang lahat ng ito sa Jira/Trello/sa ibang lugar.

Bahid

Sa huling tatlong linggo, nag-eeksperimento ako sa paggawa ng lahat sa GitHub sa halip na Jira (sa isang maliit na proyekto, uri ng istilo ng Kanban) at mahalin ito. Ngunit hindi ko maisip ito para sa isang proyekto ng Scrum kung saan ang bilis ng pag-unlad at mga katulad nito ay kailangang masuri at makalkula nang maayos. Ang magandang balita ay ang mga proyekto ng GitHub ay may napakakaunting "mga espesyal na tampok" na ang paglipat sa ibang system ay hindi magtatagal ng maraming oras. Kaya subukan ito at makita kung gaano mo ito gusto. Hindi ko alam kung gaano kahalaga ito, ngunit narinig ko ang tungkol sa ZenHub at binuksan ko ito sa unang pagkakataon 10 minuto ang nakalipas. Ito ay mahalagang isang extension ng GitHub kung saan maaari mong i-rate ang mga isyu at lumikha ng mga "epiko" at dependencies. May mga graph ng bilis ng pag-unlad at pagka-burnout; Mukhang ito ay isang kamangha-manghang bagay. Karagdagang pagbabasa: Dokumentasyon ng GitHub sa Mga Proyekto.

#10 Gwiki

Para sa isang hindi nakaayos na hanay ng mga pahina—tulad ng Wikipedia—ang GitHub Wiki (na tatawagin ko na lang na Gwiki mula ngayon) ay mahusay. Para sa isang nakabalangkas na hanay ng mga pahina - halimbawa, tulad ng iyong dokumentasyon - hindi masyado. Walang paraan upang ipahiwatig na "ang page na ito ay anak ng isang iyon"; walang ganoong maginhawang mga bagay tulad ng "Next section" at "Nakaraang seksyon" na mga button. Siguradong maliligaw sina Hansel at Gretel dito, dahil wala ring "breadcrumbs" (mga espesyal na debugging operator - humigit-kumulang trans.) dito. (Tala ng may-akda: Nabasa mo na ba ang kwentong ito? Ito ay hindi makatao. Dalawang batang thug ang pumatay sa isang kawawang gutom na matandang babae, sinunog siya ng buhay sa sarili niyang hurno . At siyempre, nag-iiwan ng kumpletong gulo para walang makaintindi. Sa tingin ko, iyon ang dahilan kung bakit ang mga kabataan ngayon ay napakasensitibo na - ang mga kwentong binabasa sa mga bata sa oras ng pagtulog sa mga araw na ito ay hindi sapat na malupit!) Moving on – upang subukang tunay ang Gwiki, nagpasok ako ng ilang pahina mula sa NodeJS bilang mga pahina ng wiki, pagkatapos ay gumawa ng custom sidebar upang gayahin ang aktwal na istraktura ng site. Ang sidebar na ito ay palaging naroroon, kahit na ang kasalukuyang pahina ay hindi naka-highlight. Ang mga link ay kailangang mapanatili nang manu-mano, ngunit sa pangkalahatan lahat ay gumagana nang maayos. Kung gusto mo, maaari mong tingnan ang : Halos hindi ito maaaring makipagkumpitensya sa isang bagay tulad ng GitBook (na ginagamit sa dokumentasyon ng Redux ) o isang pasadyang website. Ngunit ito ay isang magandang 80% nito at lahat ay tama sa iyong imbakan. Fan lang ako nito. Iminumungkahi ko na kung nalampasan mo na ang nag-iisang README.md file at kailangan mo ng ilang magkakaibang pahina para sa mga manwal ng gumagamit o mas detalyadong dokumentasyon, makatuwirang manatili sa Gwiki. Kung ang kakulangan ng istraktura/nabigasyon ay nakakaabala sa iyo, lumipat sa ibang bagay.

#11 Mga Pahina sa GitHub

Maaaring alam mo na na ang Mga Pahina ng GitHub ay maaaring gamitin upang mag-host ng isang static na website. At kung hindi mo alam, alam mo na ngayon. Gayunpaman, ang seksyong ito ay nakatuon sa isang mas tiyak na paksa: gamit ang Jekyll upang lumikha ng isang website. Sa pinakasimpleng anyo nito, maaaring i-render ng GitHub Pages + Jekyll ang README.md file gamit ang magandang hitsura na tema. Halimbawa, tingnan ang aking pahina ng readme mula sa about-github : Kung nag-click ka sa tab ng mga setting para sa GitHub site na ito, paganahin ang Mga Pahina ng GitHub, at piliin ang tema ng Jekyll... Pagkatapos ay makakakuha tayo ng isang pahina sa estilo ng tema ng Jekyll : Pagkatapos ay maaari kang lumikha ng isang buong static na site na pangunahing nakabatay sa madaling ma-edit na mga markup file, mahalagang gawing CMS ang GitHub. Bagama't hindi ko pa ito aktwal na ginagamit, ito ay kung paano ang mga website ay binuo gamit ang Bootstrap framework gamit ang React, kaya walang kakila-kilabot tungkol dito. Pansinin ko na dapat ay tumatakbo si Ruby sa lokal na makina (ang mga gumagamit ng Windows ay magpapalitan ng pang-unawang sulyap dito at pumunta sa kabilang paraan, sasabihin ng mga gumagamit ng macOS: "Ano ang problema, saan ka pupunta? Si Ruby ay isang unibersal na platform! Mayroon ding GEMS package management system!”) ( Dapat ding tandaan na ang "Agresibo o nagbabantang nilalaman o gawi" ay hindi pinapayagan sa Mga Pahina ng GitHub, kaya hindi mo mai-post doon ang iyong bersyon ng kwentong Hansel at Gretel).

Aking opinyon

Habang tinitingnan ko ang kumbinasyon ng GitHub Pages + Jekyll (para sa artikulong ito), mas naisip kong kakaiba ang buong ideya. Ang ideya ng "paggawa ng iyong sariling website na may kaunting pagsisikap" ay mahusay. Ngunit upang magawa ito kailangan mo pa rin ang kasalukuyang bersyon sa lokal na makina. At para sa isang bagay na "simple" mayroong masyadong maraming command line command. Binasa ko ang pitong pahina sa seksyong Pagsisimula at naramdaman kong ang simple lang tungkol dito ay ako . At hindi ko pa naisip ang simpleng syntax para sa pangunahing pahina o ang mga pangunahing kaalaman ng isang simpleng "Templating Mechanism batay sa Liquid language." Mas gugustuhin kong magsulat ng isang website sa aking sarili! Sa totoo lang, medyo nagulat ako na ginagamit ito ng Facebook para sa dokumentasyon ng React kapag maaari nilang buuin ang kanilang mga page ng help system gamit ang React at pre-render bilang mga static na HTML file araw-araw . Ang kailangan lang nilang gawin ay humanap ng paraan para makatanggap ng mga umiiral nang markup file na parang nagmumula sila sa CMS. Paano kung...

#12 Paggamit ng GitHub bilang isang CMS

Sabihin nating mayroon kaming website na may ilang text, ngunit hindi namin gustong iimbak ang text na iyon bilang HTML markup. Sa halip, gusto naming mag-imbak ng mga chunks ng text sa isang lugar na madaling i-edit ng mga user na hindi developer. Mas mainam na may ilang pagpipilian sa bersyon. Marahil kahit na may ilang uri ng proseso ng peer review. Narito ang iminumungkahi ko: gamitin ang mga markup file na nakaimbak sa repositoryo upang iimbak ang teksto. At gumamit ng isang bahagi sa panig ng kliyente na kukuha ng mga piraso ng tekstong ito at ipapakita ang mga ito sa pahina. Ako ay isang tagahanga ng React, kaya narito ang isang halimbawa ng isang wastong <Markdown> na bahagi na, na binibigyan ng landas sa isang markdown file, ay i-extract ito, i-parse ito, at ire-render ito bilang 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)}} />
      );
    }
}

(Ginagamit ko ang npm marked package dito para i-parse ang markup sa HTML) Ang URL ay tumuturo sa aking halimbawang repository, na naglalaman ng mga markup file sa /text-snippet directory . (Maaari mo ring gamitin ang GitHub API para kumuha ng content , ngunit duda ako na kakailanganin mo iyon.) Maaari kang gumamit ng component na tulad nito:

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

Kaya ngayon gumaganap ang GitHub bilang, sa isang paraan, ang iyong CMS para sa mga piraso ng text na gusto mong i-host. Kinukuha lang ng halimbawa sa itaas ang markup pagkatapos ma-load ang component sa browser. Kung kailangan mo ng static na site, kakailanganin mong i-render ito sa server. Magandang balita! Walang pumipigil sa iyo na kunin ang lahat ng mga markup file sa server (gamit ang anumang diskarte sa pag-cache na gusto mo). Kung magpasya kang pumunta sa rutang ito, makatuwirang gamitin ang GitHub API upang makakuha ng listahan ng lahat ng markup file sa isang direktoryo. Bonus - Mga utility ng GitHub! Matagal ko nang ginagamit ang extension ng Octotree Chrome at inirerekumenda ko ito sa iyo. Hindi nang walang reserbasyon, ngunit inirerekomenda ko pa rin ito. Nagpapakita ito ng panel sa kaliwa na may tree view ng repositoryo na iyong bina-browse. At mula sa video na ito natutunan ko ang tungkol sa octobox , na sa tingin ko ay isang napakahusay na utility sa ngayon. Ito ang inbox para sa iyong mga isyu sa GitHub. Iyon lang ang kailangan mong malaman tungkol sa kanya. Sa pagsasalita ng mga kulay, kinuha ko ang lahat ng mga screenshot sa itaas sa isang magaan na tema upang hindi ka matakot. Ngunit kung mas gusto ko ang madilim na kulay sa lahat ng iba pa, kung gayon bakit magtitiis sa nakamamatay na maputlang GitHub? Dito ay gumamit ako ng kumbinasyon ng Naka-istilong extension para sa Chrome browser (na maaaring maglapat ng mga tema sa anumang website) at ang GitHub Dark style . At bilang panimula, madilim na tema ang mga tool ng developer ng GitHub (built-in, kailangan mo lang itong paganahin) at ang tema ng Atom One Dark para sa Chrome.

Bitbucket

Sa mahigpit na pagsasalita, hindi ito ganap na angkop dito, ngunit hindi ko lang maiwasang banggitin ang Bitbucket. Dalawang taon na ang nakalilipas nagsimula ako ng isang proyekto at gumugol ng kalahating araw sa pagpili ng pinakamahusay na git hosting. Kaya, nanalo ang Bitbucket sa isang makabuluhang margin. Ang kanilang code review pipeline ay malayo sa unahan ng kumpetisyon (ito ay matagal na bago ang GitHub ay nagkaroon ng konsepto ng isang reviewer). Simula noon, nakakuha na rin ang GitHub ng mga review. Sa kasamaang palad, hindi ako nagkaroon ng pagkakataong gumamit ng Bitbucket noong nakaraang taon - marahil ay nauna na sila sa isang bagay. Kaya't inirerekumenda ko na ang mga may pananagutan sa pagpili ng isang git hosting service ay bigyang-pansin din ang Bitbucket.

Konklusyon

Iyon lang! Umaasa ako na nasabi ko sa iyo ang hindi bababa sa tatlong bagay na hindi mo alam dati. At inaasahan ko rin na nasiyahan ka sa pagbabasa ng aking artikulo.