GitHub-тың 12 таңғажайып мүмкіндіктері

Менің өмірім үшін мен ешқандай кіріспе туралы ойлай алмаймын, сондықтан ...

№1 GitHub.com сайтындағы өңдеу codeы

Мен бәрі біледі деп ойлайтын нәрседен бастайын (бір апта бұрын мен бұл туралы білмедім). GitHub-та кез келген репозиторийдегі кез келген мәтіндік файлды көргенде, жоғарғы оң жақта шағын қарындашты көре аласыз. Егер сіз оны бассаңыз, бұл файлды өңдеуге болады. Аяқтағаннан кейін «Файлды өзгертуді ұсыну» түймесін басыңыз және GitHub шанышқы мен тарту сұрауын жасайды. Керемет, солай емес пе? Ол шанышқыны өзі жасайды! Кодты өзіңізге жүктеп салудың, жергілікті түрде өзгертулер енгізудің және оны тарту сұрауымен GitHub-қа жіберудің қажеті жоқ. Ең аз өңдеулер жасау қажет болса, өте ыңғайлы. нақты тарту сұрауы емес

№2 Суреттерді кірістіру

Мәселелердің сипаттамасы тек мәтіндік түсініктемелермен шектелмейді. Суреттерді тікелей алмасу буферінен қоюға болатынын білесіз бе? Қойылған кезде оның жүктеп салынғанын (бұлтқа, сөзсіз) және кескінді көрсету үшін белгілеуге айналғанын көресіз. Керемет!

№3 Кодты пішімдеу

Егер сізге code блогын жазу қажет болса, үш кері белгіден бастаңыз және GitHub сіз қандай бағдарламалау тілінде жазып жатқаныңызды анықтауға тырысады. Бірақ Vue, Typescript немесе JSX сияқты бағдарламалау тілінде code бөлігін жариялап жатсаңыз, синтаксисті бөлектеу дұрыс болуы үшін тілді нақты көрсете аласыз. Бірінші жолдағы ```jsx-ке назар аударыңыз: ...code үзіндісінің дұрыс көрсетілуін қамтамасыз ету: (Айтпақшы, бұл Gist-ке де қатысты. Егер сіз түйін үшін .jsf кеңейтімін көрсетсеңіз, JSF синтаксисі бөлектеледі). Мұнда барлық қолдау көрсетілетін синтаксистердің тізімі берілген .

№4 Тарту сұрауларында «сиқырлы сөздер» арқылы есептерді жабу

№234 мәселені түзететін тарту сұрауын жасадыңыз делік. Сұраныс сипаттамасына (немесе өзгерту сұрауының кез келген түсініктемесінің кез келген жеріне) "№234 ақауды түзету" мәтінін енгізуге болады. Осыдан кейін, тарту сұрауын біріктіру мәселені «автоматты түрде» жояды. Керемет, солай емес пе? Бұл туралы қосымша ақпарат құжаттамада берілген .

№5 Пікірлерге сілтеме

Сізге белгілі бір түсініктемеге сілтеме жасау қажет болды және қалай екенін білмедіңіз бе? Бұл күндер артта қалды, өйткені мен сізге құпияны ашамын: Пікірге сілтеме жасау үшін тақырыптың жанындағы күнді/уақытты басыңыз. Қараңдар, енді Гаэронның фотосы бар!

№6 code сілтемесі

Сондықтан сіз codeтың белгілі бір жолына сілтеме жасағыңыз келеді. Бұл жағдайда мына әрекетті орындап көріңіз: Ашық файлдағы қажетті codeтың жанындағы жол нөмірін басыңыз. Уау, көрдің бе? URL мекенжайы өзгерді, жол нөмірі енді онда көрінеді! Егер сіз SHIFT пернесін басып тұрып, басқа жол нөмірін бассаңыз, Voila! – URL мекенжайы қайтадан өзгереді және жолдар ауқымы бөлектеледі. Бұл URL енді осы файлды және осы жолдар ауқымын көрсетеді. Бірақ күтіңіз, ол ағымдағы ағынды көрсетеді. Файл өзгерсе ше? Бұл жағдайда сізге ағымдағы күйдегі файлға тұрақты сілтеме қажет болуы мүмкін. Мен өте жалқаумын, сондықтан мен жоғарыда айтылғандардың бір скриншотын алдым: Айтпақшы, URL мекенжайлары туралы ...

№7 GitHub URL мекенжайын пәрмен жолы ретінде пайдалану

UI арқылы GitHub арқылы шарлау өте ыңғайлы ұйымдастырылған. Бірақ кейде белгілі бір орынға жету үшін оны URL мекенжайына теру жылдамырақ болады. Мысалы, мен жұмыс істеп жатқан фorалға барғым келсе және оның шебермен қалай салыстыратынын көргім келсе, репозиторий атауынан кейін жай ғана /compare/branchname деп тере аламын. Бұл мені сол фorалдың дифференциалды бетіне апарады: Бірақ бұл негізгі бөлімнен айырмашылықтар, бірақ мен бұрын интеграция тармағымен жұмыс істеген болсам, URL мекенжайына /compare/integration-branch...my-branch енгізе аламын. Жылдам пернелерді ұнататындар үшін: CTRL+L немесе CMD+L жүгіргіні URL жолына жылжытады (кем дегенде Chrome және Firefox браузерлерінде). Бұл шолғышты автотолтырумен біріктірілгенде фorалдар арасында шарлауды айтарлықтай жеңілдетеді. Кәсіби кеңес: Chrome автотолтыру ұсыныстары бойынша шарлау үшін көрсеткілерді пайдаланыңыз және тарихтан элементтерді жою үшін (мысалы, тармақты біріктіргеннен кейін) SHIFT+DELETE пернелер тіркесімін басыңыз. (Мен SHIFT + DELETE сияқты бос орын қойсам, осы пернелер тіркесімдерін оқу оңайырақ болатынын білмеймін. Бірақ техникалық тұрғыдан «+» олардың бөлігі емес, сондықтан маған бұл опция ұнамайды. Бұл Осындай нәрселерге байланысты мен түнде ұйықтамаймын, Ронда.)

№8 Мәселелер тізімдерін жасаңыз

Мәселе сипаттамасында құсбелгіні қалайсыз ба? Тізімнен мәселені қараған кезде «5-тен 2» сияқты тамаша жолақ пайда болғанын қалайсыз ба? Проблема жоқ! Келесі синтаксисті пайдаланып интерактивті құсбелгілерді жасауға болады:

• [ ] Экран ені (бүтін сан)
• [x] Қызметкерлерге қолдау көрсету
• [x] Қолдау алу
• [ ] CSS flexbox қолдауы
• [ ] Теңшелетін элементтер

Синтаксис: бос орын, сызықша, бос орын, ашылатын шаршы жақша, бос орын (немесе х), жабылатын тік жақша, бос орын және кейбір сөздер. Осыдан кейін сіз бұл түймелерді шынымен тексеріп/белгісін алып тастай аласыз! Неге екені белгісіз, бұл маған қандай да бір техникалық сиқыр сияқты болып көрінеді. Сіз ұяшықтарды белгілей аласыз! Сонымен бірге түпнұсқа мәтін өзгереді! Енді олар не ойлап табады деп ойлаудың өзі қорқынышты. О, егер бұл мәселе жоба панелінде болса, онда орындалу барысы да көрсетіледі: Егер сіз «жобалар тақтасы» дегенді түсінбесеңіз - төменде оқыңыз. Бұл бетте бір-екі сантиметр төмен.

GitHub ішіндегі №9 жоба панельдері

Үлкен жобалар үшін мен әрқашан Jira-ны қолдандым. Жеке жобаларым үшін мен әрқашан Trello-ны қолдандым. Маған бұл екі құрал да өте ұнайды. Мен бірнеше апта бұрын GitHub репозиторийдің «Жобалар» қойындысында өз опциясын ұсынатынын білгенде , мен Trello-да жұмыс істеп тұрған тапсырмалар жинағын көшіру мағынасы бар деп ойладым. Мұнда күлкілі ештеңе жоқ. Енді GitHub жобасында да дәл солай: Бірте-бірте сіздің көзіңіз төмен контрасты кескінге үйренеді Жылдамдық үшін мен жоғарыда аталғандардың барлығын ескертпелер ретінде қостым, яғни олар «нақты» GitHub мәселелері емес. Бірақ GitHub-тағы мәселелерді басқарудың күші оның репозиторийдің қалған бөлігімен интеграциясында жатыр - сондықтан бар мәселелерді репозиторийден бақылау тақтасына қосқан дұрыс. Жоғарғы оң жақ бұрыштағы Карталарды қосу түймесін басып , қосқыңыз келетін нәрсені табыңыз. Бұл жерде арнайы іздеу синтаксисі ыңғайлы болады : мысалы, is :pr is:open деп теріңіз және кез келген ашық Тарту сұрауын панельге сүйреп апаруға болады немесе кейбір қателерді түзету қажет болса label:bug . Сондай-ақ, бар жазбаларды мәселелерге түрлендіруге болады. Соңында, бар мәселе пішінінен оны оң жақ панельдегі жобаға қосыңыз. Ол сол жоба панелінің триаж тізіміне кіреді, сондықтан оны қай бағанға қою керектігін таңдауға болады «Тапсырманың» сипаттамасы осы тапсырманы орындайтын codeпен бір репозиторийде болғанда, бұл өте (өте) ыңғайлы. Бұл көптеген жылдардан кейін сіз Jira/Trello/басқа жерде оның барлығын қадағаламай-ақ, code жолында git blame-ді іске қосып, осы жолға әкелген мәселені толығымен анықтай алатыныңызды білдіреді .

Кемшіліктер

Соңғы үш апта бойы мен Jira-ның орнына GitHub-та барлығын жасап көрдім (шағын жобада, Канбан стилінде) және оны жақсы көремін. Бірақ мен мұны Scrum жобасы үшін елестете алмаймын, онда даму жылдамдығы және т.б. дұрыс бағаланып, есептелуі керек. Жақсы жаңалық, GitHub жобаларында «арнайы мүмкіндіктер» аз болғандықтан, басқа жүйеге ауысу көп уақытты қажет етпейді. Сондықтан көріңіз және оның қаншалықты ұнайтынын көріңіз. Мұның қаншалықты маңызды екенін білмеймін, бірақ мен ZenHub туралы естідім және оны 10 minutes бұрын бірінші рет аштым. Бұл GitHub кеңейтімі, онда сіз мәселелерді бағалай аласыз және «эпостар» мен тәуелділіктер жасай аласыз. Даму жылдамдығы мен күйіп кету графиктері бар; Бұл жай ғана ғажайып нәрсе сияқты. Қосымша оқу: Жобалар бойынша GitHub құжаттамасы.

№10 Гвики

Википедия сияқты құрылымсыз беттер жинағы үшін GitHub Wiki (мен енді оны Gwiki деп атаймын) тамаша. Құрылымдық беттер жинағы үшін - мысалы, құжаттама сияқты - соншалықты көп емес. «Бұл бет сол беттің баласы» деп көрсетудің ешқандай жолы жоқ, «Келесі бөлім» және «Алдыңғы бөлім» түймелері сияқты ыңғайлы нәрселер жоқ. Гансель мен Гретель бұл жерде міндетті түрде адасып кетер еді, өйткені мұнда да «нан үгінділері» (арнайы жөндеу операторлары – шамамен транс.) жоқ. (Authorдың ескертпесі: Сіз бұл оқиғаны оқыдыңыз ба ? Бұл жай ғана адамгершілікке жатпайды. Екі жас қаскөй аш кемпірді өлтіріп, оны өз пешінде тірідей өртеп жібереді . Әрине, ешкім түсінбейтін тәртіпсіздікті қалдырады. Менің ойымша, сондықтан. Қазіргі жастар өте сезімтал – бұл күндері балаларға ұйықтар алдында оқылатын әңгімелер өте қатыгез емес!) Әрі қарай жылжу – Gwiki-ді шынайы сынап көру үшін мен NodeJS-тен вики-парақшалар ретінде бірнеше бетті енгіздім, содан кейін әдетті жасадым. сайттың нақты құрылымын модельдеу үшін бүйірлік тақта. Ағымдағы бет ерекшеленбегенімен, бұл бүйірлік тақта әрқашан болады. Сілтемелерді қолмен жүргізу керек болады, бірақ тұтастай алғанда бәрі жақсы жұмыс істейді. Қаласаңыз, қарап шығуға болады : Бұл GitBook (ол Redux құжаттамасында қолданылады ) немесе тапсырыс беруші веб-сайт сияқты нәрсемен бәсекелесе алмайды . Бірақ бұл қазірдің өзінде жақсы 80% және сіздің репозиторийіңізде бәрі дұрыс. Мен тек осының жанкүйерімін. Мен бір README.md файлынан асып кетсеңіз және пайдаланушы нұсқаулығы немесе егжей-тегжейлі құжаттама үшін бірнеше түрлі беттер қажет болса, Gwiki-мен жұмыс істеуді ұсынамын. Егер құрылым/навигацияның болмауы сізді алаңдатса, басқа нәрсеге өтіңіз.

№11 GitHub беттері

GitHub беттерін статикалық веб-сайтты орналастыру үшін пайдалануға болатынын бұрыннан білетін шығарсыз. Ал егер сіз білмесеңіз, қазір білесіз. Дегенмен, бұл бөлім нақтырақ тақырыпқа арналған: веб-сайт жасау үшін Jekyll пайдалану. Ең қарапайым түрінде GitHub Pages + Jekyll README.md файлын әдемі көрінетін тақырыпты пайдаланып көрсете алады. Мысалы, about-github сайтындағы менің Readme бетімді қараңыз : Осы GitHub сайтының параметрлер қойындысын бассаңыз, GitHub беттерін қосыңыз және Jekyll тақырыбын таңдаңыз... Содан кейін біз Jekyll тақырыбының стиліндегі бетті аламыз : Содан кейін сіз негізінен оңай өңделетін түзету файлдарына негізделген тұтас статикалық сайт жасай аласыз, бұл негізінен GitHub-ты CMS-ге айналдырады. Мен мұны қолданбаған болсам да, React көмегімен Bootstrap негізін пайдаланып веб-сайттар осылай жасалады, сондықтан бұл туралы қорқынышты ештеңе жоқ. Мен Ruby жергілікті құрылғыда жұмыс істеп тұрғанын ескертемін (Windows пайдаланушылары мұнда түсіністікпен қарап, басқа жолмен жүреді, macOS пайдаланушылары: "Мәселе неде, қайда бара жатырсың? Ruby - әмбебап платформа! Сондай-ақ GEMS бар. пакетті басқару жүйесі!») (Сонымен қатар GitHub беттерінде «Агрессивті немесе қауіп төндіретін мазмұн немесе мінез-құлыққа» рұқсат етілмейтінін атап өткен жөн, сондықтан сіз онда Hansel және Gretel әңгімесінің нұсқасын орналастыра алмайсыз).

Менің ойым

Мен GitHub Pages + Jekyll комбинациясын (осы мақала үшін) көбірек қараған сайын, идеяның бәрі оғаш иісі бар деп ойладым. «Аз күш жұмсап өз веб-сайтыңызды жасау» идеясы керемет. Бірақ онымен жұмыс істеу үшін сізге әлі де жергілікті құрылғыдағы ағымдағы нұсқа қажет. Және соншалықты «қарапайым» нәрсе үшін пәрмен жолы командалары тым көп. Мен «Жұмысқа кірісу» бөліміндегі жеті бетті парақтап шықтым және оның жалғыз мен ғана қарапайым екенін сезіндім . Мен тіпті негізгі беттің қарапайым синтаксисін немесе қарапайым «Сұйық тілге негізделген үлгілеу механизмінің» негіздерін түсінбедім. Мен өзім веб-сайт жазғым келеді! Шынымды айтсам, Facebook мұны React құжаттамасы үшін пайдаланып жатқанына таң қалдым, өйткені олар React көмегімен анықтамалық жүйе беттерін құрастырып, күн сайын статикалық HTML файлдары ретінде алдын ала көрсете алады . Оларға бар болғаны, бар белгілеу файлдарын CMS-тен келген сияқты алу жолын табу керек. Болса не...

№12 GitHub-ды CMS ретінде пайдалану

Бізде мәтіні бар веб-сайт бар делік, бірақ біз бұл мәтінді HTML белгілеу ретінде сақтағымыз келмейді. Оның орнына біз мәтін бөліктерін әзірлеуші ​​емес пайдаланушылар оңай өңдей алатын жерде сақтағымыз келеді. Кейбір нұсқалар опциясымен жақсырақ. Мүмкін, тіпті әріптестік тексеру процесімен де. Мен мынаны ұсынамын: мәтінді сақтау үшін репозиторийде сақталған түзету файлдарын пайдаланыңыз. Және осы мәтін бөліктерін шығарып, оларды бетте көрсететін клиент жағында компонентті пайдаланыңыз. Мен React-тің жанкүйерімін, сондықтан төменде көрсетілген файлға жол берілгенде, оны шығарып, талдап, HTML түрінде көрсететін дұрыс <Markdown> компонентінің мысалы келтірілген.

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 тіліндегі түзетулерді талдау үшін осында npm белгіленген буманы пайдаланамын ) URL мекенжайы /text-snippets каталогындағы түзету файлдарын қамтитын мысал репозиторийімді көрсетеді . ( Мазмұнды алу үшін GitHub API интерфейсін де пайдалануға болады , бірақ бұл сізге қажет екеніне күмәнім бар.) Мынадай құрамдас бөлікті пайдалануға болады:

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

Енді GitHub сіз орналастырғыңыз келетін мәтін бөліктері үшін CMS ретінде әрекет етеді. Жоғарыда келтірілген мысал тек компонент браузерде жүктелгеннен кейін түзетуді шығарады. Егер сізге статикалық сайт қажет болса, оны serverде көрсетуге тура келеді. Жақсы жаңалық! Сервердегі барлық белгілеу файлдарын (сізге ұнайтын кез келген кэштеу стратегиясын қолдана отырып) шығарып алуға ештеңе кедергі болмайды. Егер сіз осы бағытқа баруды шешсеңіз, каталогтағы барлық белгілеу файлдарының тізімін алу үшін GitHub API пайдалану мағынасы бар. Бонус - GitHub утorталары! Мен Octotree Chrome кеңейтімін біраз уақыттан бері пайдаланып келемін және оны сізге ұсынамын. Брондаусыз емес, бірақ мен оны әлі де ұсынамын. Ол сол жақта сіз қарап жатқан репозиторийдің ағаш көрінісі бар панельді көрсетеді. Осы бейнеден мен октобокс туралы білдім , ол да маған әзірге өте жақсы утorта болып көрінеді. Бұл GitHub мәселелеріне арналған кіріс жәшігі. Ол туралы білу керек нәрсе осы ғана. Түстер туралы айтатын болсам, мен сізді қорқытпау үшін жоғарыдағы барлық скриншоттарды жеңіл тақырыпта түсірдім. Бірақ егер мен барлық нәрселерде қара түстерді ұнататын болсам, онда неліктен өлімге әкелетін бозғылт GitHub-қа шыдауға болады? Мұнда мен Chrome браузері үшін стильді кеңейтім (кез келген веб-сайтқа тақырыптарды қолдана алады) және GitHub Dark стилінің тіркесімін қолдандым . Жаңадан бастағандар үшін GitHub әзірлеуші ​​құралдарының қараңғы тақырыбы (кіріктірілген, оны қосу керек) және Chrome үшін Atom One Dark тақырыбы .

Битбукет

Қатаң айтқанда, бұл жерде мүлдем орынды емес, бірақ мен Bitbucket туралы айта алмаймын. Екі жыл бұрын мен жобаны бастадым және жарты күн бойы ең жақсы git хостингін таңдауға жұмсадым. Осылайша, Bitbucket айтарлықтай артықшылықпен жеңді. Олардың codeты шолу құбыры бәсекелестіктен әлдеқайда алда (бұл GitHub-те рецензент тұжырымдамасы болғанға дейін болды). Содан бері GitHub да шолуларға ие болды. Өкінішке орай, менде соңғы бір жылда Bitbucket қолданбасын пайдалану мүмкіндігі болмады - мүмкін олар тағы бір нәрседе алға жылжыды. Сондықтан мен git хостинг қызметін таңдауға жауапты адамдарға Bitbucket-ке назар аударуды ұсынамын.

Қорытынды

Осымен болды! Сізге бұрын белгісіз болған кем дегенде үш нәрсені айта алдым деп үміттенемін. Сондай-ақ, сіз менің мақаламды жақсы оқып шықтыңыз деп үміттенемін.