Git
Chapters ▾ 2nd Edition

6.2 GitHub - Како се даје допринос пројекту

Како се даје допринос пројекту

Сада када вам је налог подешен, хајде да прођемо кроз неке детаље који би вам могли бити од користи када желите да дате допринос постојећем пројекту.

Рачвање пројеката

Ако желите да дате допринос постојећем пројекту за који немате дозволу гурања промена, можете да га „рачвате” (fork). GitHub ће направити копију пројекта која је потпуно ваша; пројекат сада живи у вашем простору имена и можете да гурате на њега.

Белешка

Историјски, термин „fork” је имао помало негативну конотацију јер је описивао ситуацију када неко поведе пројекат отвореног кода у другом правцу, неретко стварајући супарнички пројекат и подели сараднике. У сервису GitHub, „fork” је једноставно исти пројекат у вашем простору имена, што вам дозвољава да јавно правите промене пројекта као начин да се допринос даје још отвореније.

На овај начин пројекти не морају да брину о додавању корисника као сарадника да би им дали дозволу за гурање промена. Људи могу да рачвају пројекат, гурају на рачву и дају свој допринос својих промена назад оригиналном репозиторијуму тако што ће креирати нешто што се зове захтев за повлачење (Pull Request), што ћемо описати касније. Ово отвара тему за дискусију са прегледом кода, па онда власник или особа која даје допринос могу да разговарају о промени све док власник не буде задовољан; након тога власник може да споји промене.

Да бисте рачвали пројекат, посетите страницу пројекта и кликните на дугме „Fork” у горњем десном углу странице.

_„Fork”_ дугме
Слика 88. „Fork” дугме

Након неколико секунди, бићете одведени на страницу свог новог пројекта, са својом сопственом копијом кода по којој можете да пишете.

GitHub процес рада

GitHub је дизајниран према одређеном процесу рада за сарадњу који је фокусиран на захтеве за повлачење. Овај начин рада функционише било да сарађујете са добро увезаним тимом на једном дељеном репозиторијуму, или са глобално дистрибуираном компанијом или мрежом странаца који дају допринос пројекту преко бројних рачви. Базира се на Тематске гране процесу рада који смо описали у Гранање у програму Гит.

Ево како ради у општем случају:

  1. Рачвате пројекат.

  2. Направите тематску грану из master.

  3. Направите неке комитове да побољшате пројекат.

  4. Гурнете ову грану на свој GitHub пројекат.

  5. Отворите захтев за повлачење на GitHub сервису.

  6. Дискутујете и можда наставите да комитујете.

  7. Власник пројекта споји или затвори захтев за повлачење.

  8. Синхронизујете ажурирану мастер грану назад у своју рачву.

У основи, ово је процес рада са руководиоцем интеграције који смо описали у Процес рада са руководиоцем интеграције, али уместо да се користе имејлови за комуникацију и преглед промена, тимови користе GitHub веб алате.

Хајде да прођемо кроз пример предлагања промена пројекту отвореног кода који је хостован на GitHub сервису користећи овај процес рада.

Савет

Уместо GitHub веб интерфејса, за већину ствари можете да користите званични GitHub CLI алат. Алат може да се користи на Виндоус, МекОС и Линукс системима. Посетите GitHub CLI почетну страницу за инструкције инсталације и упутство за коришћење.

Како се прави захтев за повлачење

Тони тражи кôд који хоће да извршава на свом Ардуино програмабилном микроконтролеру и нашао је одличан фајл програма на сервису GitHub на адреси https://github.com/schacon/blink.

Пројекат коме желимо да дамо допринос
Слика 89. Пројекат коме желимо да дамо допринос

Једини проблем је што је брзина трептања сувише велика. Мислимо да би било много боље да се код сваке промене стања чека три секунде уместо једне. Зато хајде да унапредимо програм и да га пошаљемо назад на пројекат као предложену промену.

Најпре кликнемо на дугме ’Fork’ које смо раније поменули да добијемо своју личну копију пројекта. Овде је наше корисничко име „tonychacon” тако да је наша копија овог пројекта на адреси https://github.com/tonychacon/blink и ту можемо да је уређујемо. Клонираћемо пројекат локално, направити тематску грану, променити кôд и коначно гурнути те промене назад на GitHub.

$ git clone https://github.com/tonychacon/blink (1)
Cloning into 'blink'...

$ cd blink
$ git checkout -b slow-blink (2)
Switched to a new branch 'slow-blink'

$ sed -i '' 's/1000/3000/' blink.ino (macOS) (3)
# If you're on a Linux system, do this instead:
# $ sed -i 's/1000/3000/' blink.ino (3)

$ git diff --word-diff (4)
diff --git a/blink.ino b/blink.ino
index 15b9911..a6cc5a5 100644
--- a/blink.ino
+++ b/blink.ino
@@ -18,7 +18,7 @@ void setup() {
// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  [-delay(1000);-]{+delay(3000);+}               // wait for a second
  digitalWrite(led, LOW);    // turn the LED off by making the voltage LOW
  [-delay(1000);-]{+delay(3000);+}               // wait for a second
}

$ git commit -a -m 'Change delay to 3 seconds' (5)
[slow-blink 5ca509d] Change delay to 3 seconds
 1 file changed, 2 insertions(+), 2 deletions(-)

$ git push origin slow-blink (6)
Username for 'https://github.com': tonychacon
Password for 'https://tonychacon@github.com':
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/tonychacon/blink
 * [new branch]      slow-blink -> slow-blink

  1. Клонирамо нашу рачву пројекта локално.

  2. Направимо описну тематску грану.

  3. Изменимо кôд.

  4. Проверимо да ли је промена добра.

  5. Комитујемо промену на тематску грану.

  6. Гурнемо нову тематску грану назад на нашу GitHub рачву.

Ако се сада вратимо на нашу GitHub рачву, видећемо да је GitHub приметио да смо гурнули нову тематску грану и приказује нам велико зелено дугме да одјавимо промене и отворимо захтев за повлачење ка првобитном пројекту.

Други начин је да одете на страницу „Branches” на https://github.com/<корисник>/<пројекат>/branches да лоцирате своју грану и отворите нов захтев за повлачење одатле.

Дугме _Pull Request_
Слика 90. Дугме Pull Request

Ако кликнемо на то зелено дугме, видећемо екран који нас пита да нашем захтеву за повлачење дамо наслов и опис. Скоро увек вреди потрудити се мало за ово, пошто добар опис помаже власнику првобитног пројекта да схвати шта желите да урадите, да ли су ваше предложене промене исправне и да ли ће прихватање промена побољшати првобитни пројекат.

Можемо да видимо и листу комитова на нашој тематској грани који су „испред” master гране (у овом случају, само један) и уједињену разлику свих промена које ће бити направљене ако власник пројекта одлучи да споји ову грану.

Страница за прављење захтева за повлачење
Слика 91. Страница за прављење захтева за повлачење

Када на овом екрану кликнете на дугме ’Create pull request’, власник пројекта који сте рачвали ће добити обавештење да неко предлаже промену и добиће линк до странице која има све информације у вези тога.

Белешка

Мада се захтеви за повлачење најчешће користе за јавне пројекте као што је овај када сарадник има комплетну промену која је спремна да се примени, користе се често и код интерних пројекта на почетку циклуса развоја. Пошто можете да наставите да гурате на тематске гране чак и након што се отвори захтев за повлачење, он се често отвара рано и користи се као начин за тимску итерацију над радом у контексту, уместо да се отвори на самом крају процеса.

Итерација над захтевом за повлачење

Сада власник пројекта може да погледа предложену промену и да је споји, да је одбије, или да је коментарише. Рецимо да му се допада идеја, али му се више свиђа да светло буде искључено мало дуже него што је укључено.

Овакав разговор би се обављао имејловима у процесима рада који су представљени у Дистрибуирани Гит, али се на GitHub сервису ово дешава онлајн. Власник пројекта може да прегледа уједињену разлику и остави коментар кликом на било коју линију.

Коментарисање одређене линије кода у захтеву за повлачење
Слика 92. Коментарисање одређене линије кода у захтеву за повлачење

Када одржавалац направи овај коментар, особа која је отворила захтев за повлачење (заправо, свако ко прати репозиторијум) добиће обавештење. Касније ћемо показати како променити ова подешавања, али ако су му била укључена имејл обавештења, Тони ће добити овакав имејл:

Коментари послати као имејл обавештења
Слика 93. Коментари послати као имејл обавештења

Свако може да остави опште коментаре на захтев за повлачење. У Страница за дискусију захтева за повлачење видимо пример где власник пројекта коментарише линију кода, а онда оставља општи коментар у одељку за дискусију. Можете видети да се коментари о коду такође довлаче и у овај разговор.

Страница за дискусију захтева за повлачење
Слика 94. Страница за дискусију захтева за повлачење

Сада сарадник може да види шта треба да уради да би се промена прихватила. Срећом, ово је веома једноставно. Док бисте преко имејлова морали да поново смотате серију закрпи и пошаљете је поново на мејлинг листу, са GitHub сервисом можете једноставно да поново комитујете на тематској грани и да гурнете промене које ће аутоматски ажурирати захтев за повлачење. У Коначни захтев за повлачење такође можете да видите и то да је стари коментар на коду сакривен у ажурираном захтеву за повлачење, пошто је постављен на линији која се од тада изменила.

Додавање комитова на постојећи захтев за повлачење не окида обавештавање, тако да након што Тони гурне своје исправке, одлучује да остави коментар како би обавестио власника пројекта да је направио захтевану промену.

Коначни захтев за повлачење
Слика 95. Коначни захтев за повлачење

Занимљива ствар коју можете приметити је да ако на овом захтеву за повлачење кликнете на картицу „Files Changed”, добићете „уједињену” разлику — другим речима, укупну нагомилану разлику која би била уведена у вашу главну грану ако би се ова тематска грана спојила са њом. Ако посматрамо git diff, ово вам у суштини аутоматски покаже git diff master…​<грана> за грану на којој је базиран захтев за повлачење. Погледајте Како утврдити шта је уведено за више информација о овој врсти разлике.

Друга ствар коју ћете приметити је то да GitHub проверава да ли се захтев за повлачење глатко спаја и нуди дугме које уместо вас ради спајање на серверу. Ово дугме се појављује само ако имате дозволу писања у репозиторијум и ако је могућ тривијални спој. Ако кликнете на њега, GitHub ће извршити „не премотавај унапред” спајање, што значи да чак и ако би спајање могло да буде премотавање унапред, ипак ће се направити нови комит спајања.

Ако вам више одговара, можете и једноставно да повучете грану и обавите спајање локално. Ако спојите ову грану у master грану и гурнете то на GitHub, захтев за повлачење ће се аутоматски затворити.

Ово је основни процес рада који користи већина GitHub пројеката. Праве се тематске гране, над њима се отварају се захтеви за повлачење, следи дискусија, евентуално се ради још мало на грани и на крају се захтев или затвори или споји.

Белешка
Не само рачве

Важно је приметити да можете отворити и захтев за повлачење између две гране у истом репозиторијуму. Ако са неком особом радите на могућности и обоје имате дозволу за писање по пројекту, можете да гурнете тематску грану на репозиторијум и отворите захтев за повлачење у master грану тог истог пројекта да бисте покренули преглед кода и дискусију. Нема потребе за рачвањем.

Напредни захтеви за повлачење

Сада када смо показали основе давања доприноса пројекту на сервису GitHub, хајде да погледамо неколико занимљивих савета и трикова о захтевима за повлачење тако да можете бити ефикаснији док их користите.

Захтеви за повлачење као закрпе

Важно је разумети да многи пројекти не гледају на захтеве за повлачење као на низ савршених закрпа које чисто треба да се примене тим редом, као што већина пројеката базираних на мејлинг листи гледа на доприносе у низу закрпи. Већина GitHub пројеката гледа на гране за које се захтева повлачење као итеративне разговоре о предложеној промени, који кулминирају у јединствену разлику која се прихвата спајањем.

Ово је важна разлика, јер се у општем случају промена предлаже пре него што се сматра да је кôд савршен, што је много ређи случај код доприноса базираних на низу закрпа са мејлинг листе. Ово омогућава правовремени разговор са одржаваоцима тако да је долазак до доброг решења углавном плод тимског рада заједнице. Када се кôд предложи захтевом за повлачење и одржаваоци или заједница предложе промену, низ закрпа се у општем случају не смотава поново, већ се разлика гурне као нови комит на грани, водећи разговор даље тако да је контекст претходног рада недирнут.

На пример, ако се вратите назад и опет погледате Коначни захтев за повлачење, приметићете да сарадник није ребазирао свој комит и послао још један захтев за повлачење. Уместо тога, додао је нове комитове и гурнуо их на постојећу грану. На овај начин, ако се касније вратите назад и погледате овај захтев за повлачење, моћи ћете лако да нађете контекст због кога су донете одлуке. Ако на сајту кликните на дугме „Merge”, намерно се прави комит спајања који указује на захтев за повлачење тако да лако можете да се вратите назад и истражите оригиналну дискусију, ако то буде било потребно.

Како одржати корак са узводним гранама

Ако ваш захтев за повлачење постане застарео или се из неког другог разлога не спаја глатко, то треба да поправите како би одржавалац могао лако да га споји. GitHub ће вам ово тестирати и обавестиће вас на дну сваког захтева за повлачење о томе да ли је спој тривијалан или не.

Захтев за повлачење се не спаја глатко
Слика 96. Захтев за повлачење се не спаја глатко

Ако видите нешто као Захтев за повлачење се не спаја глатко, треба да поправите своју грану тако да постане зелена и да одржавалац не мора да ради додатни посао.

Ово можете урадити на два главна начина. Можете или да ребазирате своју грану на врх одредишне (обично је то master грана репозиторијума који сте рачвали), или да спојите одредишну грану у своју грану.

Већина програмера на сервису GitHub ће изабрати другу опцију, из истих разлога које смо прешли у претходном одељку. Оно што је важно је историја и коначно спајање, тако да вам ребазирање не даје много тога сем нешто чистије историје, а с друге стране је много компликованије и подложније грешкама.

Ако желите да спојите одредишну грану како би ваш захтев за повлачење могао да се споји, треба да додате првобитни репозиторијум као нови удаљени репозиторијум, преузмете (fetch) податке са њега, спојите главну грану тог репозиторијума у своју тематску грану, средите све евентуалне проблеме и на крају гурнете то назад на исту грану за коју сте отворили захтев за повлачење.

На пример, рецимо да је у примеру „tinychacon” који смо користили малопре, првобитни аутор направи промену која ствара конфликт са захтевом за повлачење. Хајде да прођемо кроз те кораке.

$ git remote add upstream https://github.com/schacon/blink (1)

$ git fetch upstream (2)
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
Unpacking objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
From https://github.com/schacon/blink
 * [new branch]      master     -> upstream/master

$ git merge upstream/master (3)
Auto-merging blink.ino
CONFLICT (content): Merge conflict in blink.ino
Automatic merge failed; fix conflicts and then commit the result.

$ vim blink.ino (4)
$ git add blink.ino
$ git commit
[slow-blink 3c8d735] Merge remote-tracking branch 'upstream/master' \
    into slower-blink

$ git push origin slow-blink (5)
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 682 bytes | 0 bytes/s, done.
Total 6 (delta 2), reused 0 (delta 0)
To https://github.com/tonychacon/blink
   ef4725c..3c8d735  slower-blink -> slow-blink

  1. Додавање првобитног репозиторијума као удаљеног са именом upstream.

  2. Преузимање најновијег рада са тог удаљеног репозиторијума.

  3. Спајање главне гране у вашу тематску грану.

  4. Решавање конфликта који су настали.

  5. Гурање назад на исту тематску грану.

Када то урадите, захтев за повлачење ће аутоматски бити ажуриран и поново проверен да би се установило да ли се глатко спаја.

Захтев за повлачење се сада спаја глатко
Слика 97. Захтев за повлачење се сада спаја глатко

Једна од најбољих ствари у вези програма Гит је то што непрестано можете да радите овакве ствари. Ако имате пројекат који веома дуго траје, једноставно можете да спајате са одредишних грана изнова и изнова, а решавате само конфликте који настану од тренутка када сте последњи пут извршили спајање, што чини процес веома подесним за руковање.

Ако дефинитивно желите да ребазирате грану како бисте је почистили, то наравно можете урадити, али се строго препоручује да не форсирате гурање преко гране на којој је захтев за повлачење већ отворен. Ако су је други људи повукли и радили нешто на њој, долазите до гомиле проблема који су описани у Опасности ребазирања. Уместо тога, гурните ребазирану грану на нову грану на сервису GitHub и отворите потпуно нови захтев за спајањем који указује на стари, па онда затворите првобитни.

Референце

Ваше следеће питање би могло да буде „Како да укажем на стари захтев за повлачење?”. Испоставља се да постоји огроман број начина да укажете на скоро све што било где пишете на сервису GitHub.

Почнимо од тога како да унакрсно укажете на други захтев за повлачење или на тикет (Issue). Сви захтеви за повлачење и тикети имају своје бројеве који су јединствени за један пројекат. На пример, не можете имати захтев за повлачење #3 и тикет #3. Ако желите да укажете на захтев за повлачење или тикет са било ког другог, можете једноставно да ставите #<број> у било ком коментару или опису. Можете и да будете одређенији ако тикет или захтев за повлачење живи негде другде; пишите корисничко-име#<број> ако указујете на тикет или захтев за повлачење у рачви репозиторијума у којем се налазите, или корисничко-име/репозиторијум#<број> да укажете на нешто из неког другог репозиторијума.

Погледајмо пример. Рецимо да само ребазирали грану у претходном примеру, направили нови захтев за повлачење за њу, па сада желимо да укажемо на стари захтев за повлачење из новог. Такође желимо да укажемо на тикет у рачви репозиторијума и тикет у потпуно другом пројекту. Можемо да попунимо опис баш као што је то учињено у Унакрсне референце у захтеву за повлачење.

Унакрсне референце у захтеву за повлачење
Слика 98. Унакрсне референце у захтеву за повлачење

Када пошаљемо овај захтев за повлачење, видећемо да се све то приказује као Приказане унакрсне референце у захтеву за повлачење.

Приказане унакрсне референце у захтеву за повлачење
Слика 99. Приказане унакрсне референце у захтеву за повлачење

Приметите да је пун GitHub URL који смо унели скраћен само на неопходне информације.

Ако се сада Тони врати назад и затвори првобитни захтев за повлачење, то можемо да видимо његовим помињањем у новом, сервис GitHub аутоматски креира догађај праћења уназад (trackback event) у временској линији захтева за повлачење. Ово значи да ће свако ко посети овај захтев за повлачење и види да је затворен лако моћи да дође до оног којим је замењен. Линк ће изгледати отприлике као на Линк уназад на нови захтев за повлачење у временској линији затвореног захтева за повлачење.

PR затворен
Слика 100. Линк уназад на нови захтев за повлачење у временској линији затвореног захтева за повлачење

Поред бројева тикета, на одређени комит можете указати са SHA-1. Морате да наведете комплетан SHA-1 са 40 карактера, али ако сервис GitHub то види у коментару, линковаће га директно на комит. Опет, можете да указујете на комитове у рачвама или другим репозиторијума на исти начин као са што се ради у тикетима.

Маркдаун са GitHub укусом

Линковање других тикета је само почетак занимљивих ствари које можете радити са скоро било којим текстуалним пољем на сервису GitHub. У описима тикета и захтева за повлачење, коментарима, коментарима у коду и на многим другим местима, можете да користите нешто што се зове Маркдаун са GitHub укусом (GitHub Flavored Markdown). Маркдаун је као писање обичног текста који се затим приказује са стиловима.

Погледајте Пример Маркдауна са GitHub укусом како је написан и како се приказује за пример како се коментари или текст могу написати а онда приказати користећи Маркдаун.

Пример Маркдауна
Слика 101. Пример Маркдауна са GitHub укусом како је написан и како се приказује

Маркдаун са GitHub укусом додаје још ствари које можете да урадите поред основне Маркдаун синтаксе. Све оне могу бити веома корисне када правите коментаре или описе за захтеве за повлачење или тикете.

Листа задатака

Прва веома корисна одлика GitHub специфичног Маркдауна, поготово код захтева за повлачење, јесте листа задатака. Листа задатака је листа ствари са пољима за штиклирање које желите да буду урађене. Када их ставите у тикет или захтев за повлачење, то обично означава ствари које желите да се ураде пре него што ставка може да се сматра као завршена.

Листу задатака можете да направите овако:

- [X] Write the code
- [ ] Write all the tests
- [ ] Document the code

Ако ово укључимо у опис нашег захтеву за повлачење или у опис тикета, видећемо да се приказује као Листа задатака приказана у Маркдаун коментару.

Пример листе задатака
Слика 102. Листа задатака приказана у Маркдаун коментару

Ово се често користи у захтевима за повлачење ради указивања на све оно што бисте желели да се обави на грани пре него што захтев за повлачење буде спреман за спајање. Оно што је овде стварно супер је то што једноставним кликом на поља за штиклирање ажурирате коментар — не морате директно да уређујете Маркдаун да бисте штиклирали задатке.

Штавише, GitHub ће потражити листе задатака у вашим тикетима и захтевима за повлачење и приказаће их као метаподатке на страницама које их исписују. На пример, ако имате захтев за повлачење са задацима и баците поглед на страницу која представља преглед свих захтева за повлачење, видећете докле се стигло са радом. Ово помаже људима да разбију захтеве за повлачење у мање задатке и помаже другим људима да прате напредовање гране. Пример овога можете видети у Сажетак листе задатака у листи захтева за повлачење.

Пример листе задатака
Слика 103. Сажетак листе задатака у листи захтева за повлачење

Ово је невероватно корисно када рано отворите захтев за повлачење и користите га да пратите свој напредак имплементације могућности.

Исечци кода

Такође можете да додате и исечке кода у коментаре. Ово је посебно корисно када желите да представите нешто што би могли да пробате пре него што се стварно имплементира као комит на вашој грани. Ово се такође често користи да се дода пример кода који не ради или шта би овај захтев за повлачење могао да имплементира.

Да бисте додали исечак кода, треба да га „оградите” краткоузлазним акцентима (`).

```java
for(int i=0 ; i < 5 ; i++)
{
   System.out.println("i is : " + i);
}
```

Ako dodate ime jezika kao što smo gore učinili sa java, GitHub će probati i da истакне sintaksу isečkа. U slučaju gornjeg primera, приказ би изгледао као Приказан пример ограђеног исечка кода.

Приказ ограђеног кôда
Слика 104. Приказан пример ограђеног исечка кода

Цитирање

Ако одговарате на мањи део дугачког коментара, можете селективно да цитирате коментар тако што ћете линије почети карактером >. Заправо, ово је толико корисно и толико често да постоји и пречица на тастатури. Ако у коментару обележите текст на који желите директно да одговорите и притисните тастер r, пречица ће у пољу коментара да цитира тај текст уместо вас.

Цитати изгледају отприлике овако:

> Whether 'tis Nobler in the mind to suffer
> The Slings and Arrows of outrageous Fortune,

How big are these slings and in particular, these arrows?

Када се прикаже, коментар ће изгледа као Приказ примера цитата.

Приказ цитата
Слика 105. Приказ примера цитата

Емођи

За крај, у коментарима можете да користите и емођије. Ово се заправо врло често користи у коментарима које видите на многим GitHub тикетима и захтевима за повлачење. Постоји чак и помоћник за емођије на сервису GitHub. Ако куцате коментар и почнете са карактером :, аутоматски довршавач ће вам помоћи да пронађете оно што тражите.

Аутоматски довршавач за емођије
Слика 106. Аутоматски довршавач за емођије у акцији

Емођији имају облик :<име>: било где у коментару. На пример, можете да напишете нешто овако:

I :eyes: that :bug: and I :cold_sweat:.

:trophy: for :microscope: it.

:+1: and :sparkles: on this :ship:, it's :fire::poop:!

:clap::tada::panda_face:

Када се прикаже, изгледаће отприлике као Коментар са пуно емођија.

Емођи
Слика 107. Коментар са пуно емођија

Ово није нешто много корисно, али додаје елемент забаве и емоција медијуму којим се иначе тешко исказује емоције.

Белешка

Ових дана заправо постоји велики број веб сервиса који користе емођи карактере. Одличан списак на који се можете позвати да нађете емођи који осликава оно што желите да кажете налази се на:

https://www.webfx.com/tools/emoji-cheat-sheet/

Слике

Технички ово није Маркдаун са GitHub укусом, али је невероватно корисно. Поред додавања линкова ка сликама у коментарима, што можете бити тешко за налажење и уграђивање URL адреса, GitHub вам омогућава и да превучете и пустите слике у текст поља и да их тако уградите.

Превлачење и пуштање слика
Слика 108. Превуците и пустите слике да бисте их пошаљете на сервер и аутоматски уградите

Ако погледате на Превуците и пустите слике да бисте их пошаљете на сервер и аутоматски уградите, видећете мали савет „Parsed as Markdown” изнад текст поља. Клик на то ће вам приказати велики пано са свиме што можете урадити са Маркдауном на сервису GitHub.

Одржавање вашег јавног GitHub репозиторијума ажурним

Једном када рачвате GitHub репозиторијум, ваш репозиторијум (ваша „рачва”) постоји независно од оригиналног. Тачније, када оригинални репозиторијум има нове комитове, GitHub вас обавештава поруком као што је:

This branch is 5 commits behind progit:master.

Али сервис GitHub никада неће аутоматски ажурирати ваш GitHub репозиторијум; то је нешто што морате сами да урадите. На срећу, врло је једноставно.

Једна могућност не захтева никакву конфигурацију. На пример, ако се рачвали из https://github.com/progit/progit2.git, своју master грану можете да одржавате ажурном на следећи начин:

$ git checkout master (1)
$ git pull https://github.com/progit/progit2.git (2)
$ git push origin master (3)

  1. Ако сте били на некој другој грани, вратите се на master.

  2. Преузмите промене са https://github.com/progit/progit2.git и спојите их у master.

  3. Гурните своју master грану на origin.

Ово функционише, али је помало незгодно што морате сваки пут да исписујете URL за преузимање. Тај посао можете да аутоматизујете са мало конфигурисања:

$ git remote add progit https://github.com/progit/progit2.git (1)
$ git fetch progit (2)
$ git branch --set-upstream-to=progit/master master (3)
$ git config --local remote.pushDefault origin (4)

  1. Додајете изворни репозиторијум и дајете му име. Овде сам изабрао да га назовем progit.

  2. Преузимате референце на гране progit репозиторијума, тачније на master.

  3. Постављате своју master грану да преузме из progit удаљеног.

  4. Дефинишете да подразумевани репозиторијум у који се гура буде origin.

Једном када се ово уради, процес рада постаје доста простији:

$ git checkout master (1)
$ git pull (2)
$ git push (3)

  1. Ако сте били на некој другој грану, враћате се на master.

  2. Преузимате промене са progit и спајате промене у master.

  3. Гурате своју master грану на origin.

Овај приступ може бити користан, али има и лоших страна. Програм Git ће задовољно одрадити овај посао у тишини, али вас неће упозорити ако направите комит на master, повучете са progit, па затим гурнете на origin — све ове операције су исправне у овако постављеном систему. Тако да морате пазити да никада директно не комитујете на master, јер та грана у суштини припада узводном репозиторијуму.

scroll-to-top