Git
Chapters ▾ 2nd Edition

6.2 GitHub - Придонес кон проект

Придонес кон проект

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

Формирање проекти

Ако сакате да придонесете за постоечки проект на кој немате притисок, можете да го "разоткриете" проектот. Кога ќе "разделите" проект, GitHub ќе направи копија од проектот што е целосно ваш; таа живее во вашиот именски простор и може да притиснете.

Note

Историски гледано, терминот ‘` вилушка ’ е малку негативен во контекст, што значи дека некој зеде проект со отворен код во различен правец, понекогаш создавајќи конкурентен проект и поделба на соработниците. Во GitHub, `` вилушка ' е едноставно ист проект во вашиот сопствен именски простор, овозможувајќи ви да ги промениш проектите јавно како начин да придонесете поотворено.

На овој начин, проектите не мора да се грижат за додавање на корисници како соработници за да им овозможат пристап до нив. Луѓето можат да се откажат од проект, да се придвижат кон него и да ги придонесат своите промени назад во оригиналното складиште, создавајќи го она што се нарекува Барање за повлекување, кое ќе го покриеме следно. Ова отвора низа за дискусија со преглед на кодот, а сопственикот и соработникот потоа може да комуницираат за промената се додека сопственикот не се задоволи со него, во кој момент сопственикот може да го спои.

За да видете проект, посетете ја страницата на проектот и кликнете на копчето "Вилушка" во горниот десен агол на страницата.

The ``Fork'' button.
Figure 84. The “Fork” button.

По неколку секунди, ќе бидете префрлени на вашата нова страница со проектот, со своја сопствена копија од кодот кој може да се запише.

GitHub Тек

GitHub е дизајниран околу одреден процес на работа на соработка, центриран на барањата за повлекување. Овој проток работи без разлика дали соработувате со тесно поврзан тим во едно заедничко складиште или глобално дистрибуирана компанија или мрежа на странци кои придонесуваат за проектот преку десетици вилушки. Тој е центриран на работниот процес << _topic_branch >>, опфатен во гранката на грандиозност <ch03-git-branching # ch03-git-branching >>.

Еве како функционира генерално:

  1. Вилушкајте го проектот

  2. Креирајте гранка на тема од master.

  3. Направете некои обврски за подобрување на проектот.

  4. Притиснете ја оваа гранка во вашиот GitHub проект.

  5. Отворете барање за повлекување на GitHub.

  6. Дискутирајте и, опционално, продолжете со извршување.

  7. Сопственикот на проектот го спојува или затвора Барањето за повлекување.

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

Ајде да одиме низ еден пример за предлагање на промена на проект со отворен код, хостиран на GitHub користејќи го овој проток.

Креирање на барање за повлекување

Тони бара код за да работи на неговиот програмски микропроцесор Arduino и најде одлична програмска датотека на GitHub на https://github.com/schacon/blink [].

The project we want to contribute to.
Figure 85. The project we want to contribute to.

Единствениот проблем е тоа што стапката на трепкање е премногу брзо. Сметаме дека е многу поубаво да чекаме 3 секунди, наместо 1 помеѓу секоја промена на државата. Значи, да ја подобриме програмата и да ја поднесеме назад кон проектот како предложена промена.

Прво, кликнуваме на копчето "Вилушка" како што беше споменато претходно за да добиеме сопствена копија од проектот. Нашето корисничко име тука е ‘` 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 'three seconds is better' (5)
[slow-blink 5ca509d] three seconds is better
 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 забележа дека сме натерале нова тема да се подели и ни претставува големо зелено копче за да ги провериме нашите промени и да отвориме барање за повлекување на оригиналниот проект.

Како алтернатива, можете да отидете на страницата ‘` Филијали '’ на `https://github.com/ <user> / <project> / branches" за да ја лоцирате вашата филијала и оттаму да отворите ново барање за повлекување.

Pull Request button
Figure 86. Pull Request button

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

Ние, исто така, видиме листа на обврските во нашата гранка на теми кои се "напред" на "господарната гранка" (во овој случај, само онаа) и обединета разлика на сите промени што ќе бидат направени, ако оваа гранка споени од сопственикот на проектот.

Pull Request creation
Figure 87. Pull Request creation page

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

Note

Иако барањата за влечење се користат често за вакви јавни проекти, кога соработникот има комплетна промена подготвена да се направи, таа често се користи и во внатрешните проекти на почетокот на развојниот циклус. Бидејќи можете да продолжите да вршите притисок врз гранката на тема дури * по * се отвора Барањето за влечење, тоа често се отвора рано и се користи како начин да се повтори работата на тим во контекст, наместо да се отвори на самиот крај на процесот.

Итерација на барањето за повлекување

Во овој момент, сопственикот на проектот може да ја разгледа предложената промена и да ја спои, да го одбие или да коментира. Да речеме дека му се допаѓа идејата, но би сакала малку подолго време за светлината да биде исклучена отколку натаму.

Каде што овој разговор може да се одвива преку е-пошта во работните процеси презентирани во << ch05-distributed-git >>, на GitHub ова се случува онлајн. Сопственикот на проектот може да ја прегледа унифицираната разлика и да остави коментар со кликнување на која било од редовите.

PR line comment
Figure 88. Comment on a specific line of code in a Pull Request

Откако одржувачот ќе го направи овој коментар, лицето кое го отворило барањето за потпишување (и навистина, некој друг што го следи складиштето) ќе добие известување. Ќе продолжиме да го прилагодуваме ова подоцна, но ако има вклучено известување преку е-пошта, Тони ќе добие е-пошта како оваа:

Email notification
Figure 89. Comments sent as email notifications

Секој може исто така да остави општи коментари за барањето за повлекување. Во << _ pr_discussion >> можеме да видиме пример на сопственикот на проектот коментирајќи ја линијата на кодот, а потоа оставајќи општ коментар во делот за дискусија. Можете да видите дека кодек коментари се доведени во разговорот, како и.

PR discussion page
Figure 90. Pull Request discussion page

Сега соработникот може да види што треба да направат за да ја прифатат нивната промена. За среќа, ова е многу едноставно. Каде преку е-маил можеби ќе треба да ја превртувате вашата серија и да ја поднесете повторно на мејлинг листата, со GitHub вие едноставно се обврзувате на гранката на тема повторно и притиснете, што автоматски ќе го ажурира барањето за повлекување. Во << _ pr_final >> исто така можете да видите дека стариот коментар во коментарот е пропаднат во ажурираното барање за повлекување, бидејќи е направено на линија која оттогаш е променета.

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

PR final
Figure 91. Pull Request final

Интересно е да се забележи дека ако кликнете на табулаторот ‘` Датотеки смени ’ на ова барање за повлекување, ќе го добиете `` унифициран ' разлик - односно вкупната разлика во вкупниот износ што ќе се внесе во вашиот главната гранка, ако оваа гранка на тема беше споена внатре. Во git diff термини, тој во основа автоматски ви покажува` git diff master …​ <branch> `за гранката на која се заснова ова барање за повлекување. Види << _what_is_introduced >> за повеќе за овој тип на разлика.

Другата работа што ќе забележите е дека GitHub проверува дали да се спореди барањето за повлекување и да се обезбеди копче за да се направи спојување за вас на серверот. Ова копче се појавува само ако имате пристап за запишување во складиштето и можно е тривијално спојување. Ако го кликнете, GitHub ќе изврши спојување со "не-брз напред", што значи дека дури и ако спојувањето * може да биде брзо напред, сепак ќе создаде спојување.

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

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

Note
Not Only Forks

Важно е да се напомене дека исто така можете да отворите барање за повлекување помеѓу две гранки во истото складиште. Ако работите со некоја функција со некој и двајцата имате пристап за запишување на проектот, можете да притиснете на гранка на тема во складиштето и да го отворите барањето за повлекување на неа до "master" филијалата на истиот проект за да го иницирате шифрата преглед и дискусија. Не е неопходно.

Напредно барање за повлекување

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

Повлечете ги барањата како закрпи

Важно е да се разбере дека многу проекти навистина не мислат на Пат Барања како редици на совршени закрпи кои треба да се применуваат чисто по редослед, бидејќи повеќето проекти засновани на списоци размислуваат за придонеси од сериите на печ. Повеќето GitHub проекти размислуваат за гранките за укинување на повик како итеративни разговори околу предложената промена, што кулминира со унифициран раздел кој се применува со спојување.

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

На пример, ако се вратиш повторно и погледнете повторно во << _ pr_final >>, ќе забележите дека соработникот не го повратил своето извршување и испрати друго барање за повлекување. Наместо тоа, тие додадоа нови обврски и ги туркаа до постојната гранка. На овој начин, ако се вратите назад и ќе го разгледате ова барање за повлекување во иднина, можете лесно да го најдете целиот контекст за тоа зошто биле донесени одлуки. Притискањето на копчето `Merge 'на страницата намерно создава обврска за спојување која го упатува Барањето за потпишување, така што лесно може да се врати и да се испита оригиналниот разговор ако е потребно.

Одржување со Upstream

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

PR merge failure
Figure 92. Pull Request does not merge cleanly

Ако видите нешто како << _ pr_fail >>, ќе сакате да ја поправите вашата гранка, така што ќе стане зелена и одржувачот не мора да работи дополнително.

Имате две главни опции за да го направите тоа. Можете да го ребалансирате филијалата на врвот на она што е целниот гранка (обично "господар" филијала на складиштето што сте го навеле), или можете да ја спои целната гранка во вашата гранка.

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

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

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

$ 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. Додајте го оригиналното складиште како далечинско наречено "нагорниот"

  2. Донеси ја најновата работа од тој далечински управувач

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

  4. Исправи го конфликтот што се случи

  5. Придвижете се назад кон истата гранка

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

PR fixed
Figure 93. Pull Request now merges cleanly

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

Ако апсолутно сакате да ја оспорите филијалата за да го исчистите, сигурно може да го сторите тоа, но многу е охрабрен да не го притискате гранката на која веќе е отворена Барањето за влечење. Ако другите луѓе го повлекоа и направија повеќе работа на тоа, ќе наидете на сите прашања наведени во << _rebase_peril >>. Наместо тоа, притиснете го преработениот филијала во нова филијала на GitHub и отворете сосема ново барање за потпишување кое ќе го референцира стариот, а потоа затворете го оригиналот.

Референци

Вашето следно прашање може да биде: "Како да го користам старото барање за повлекување?" Излезе дека има многу, многу начини да се повикувате на други работи речиси насекаде каде што можете да напишете во GitHub.

Ајде да започнеме со тоа како да се препратиме на друго барање за повлекување или проблем. Сите барања за повлекување и прашања се доделени броеви и тие се единствени во рамките на проектот. На пример, не можете да добивате Pull Request # 3 and Issue # 3. Ако сакате да се повикате на било кое барање за повлекување од било кое друго, едноставно можете да ставите # <num> во кој било коментар или опис. Можете исто така да бидете поспецифични ако барањето за издавање или повлекување живее на друго место; напишете корисничко име # <num>, ако упатувате на прашање или барање за повлекување во вилушка од складиштето во кое што сте, или корисничко / репо # <num> за да упатите нешто во друго складиште.

Ајде да погледнеме еден пример. Да речеме дека ја прекршивме гранката во претходниот пример, создадовме ново барање за повлекување, и сега сакаме да го повикаме старото барање за повлекување од новиот. Ние исто така сакаме да се повикаме на прашање во вилушка на складиштето и прашање во сосема поинаков проект. Ние можеме да го пополниме описот како << _ pr_references >>.

PR references
Figure 94. Cross references in a Pull Request.

Кога ќе го поднесеме ова барање за повлекување, ќе видиме сето тоа изречено како << _ pr_references_render >>.

PR references rendered
Figure 95. Cross references rendered in a Pull Request.

Забележете дека целосниот URL на GitHub што го ставаме таму беше скратен само со потребните информации.

Сега, ако Тони се врати и го затвора оригиналното барање за повлекување, можеме да видиме дека со споменување во новиот, GitHub автоматски создаде trackback настан во временската линија за повлекување. Ова значи дека секој што го посетува ова барање за повлекување и гледа дека е затворен, лесно може да се поврзе со оној кој го заменил. Врската ќе изгледа нешто како << _ pr_closed >>.

PR closed
Figure 96. Link back to the new Pull Request in the closed Pull Request timeline.

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

GitHub со вкус на Markdown

Поврзувањето со други прашања е само почеток на интересни работи што можете да ги направите со речиси секое поле за текст на GitHub. Во Описот за Прашања и Потрага, коментари, кодови на коментари и повеќе, можете да го користите она што се нарекува ‘` GitHub со вкус на Markdown '’. Markdown е како да пишувате во обичен текст, но кој е богато прикажан.

Погледнете << _ example_markdown >> за пример за тоа како може да се напишат коментари или текст, а потоа да се претстават со помош на Markdown.

Example Markdown
Figure 97. An example of GitHub Flavored Markdown as written and as rendered.

GitHub вкусот на Markdown додава повеќе работи што можете да ги направите надвор од основната синтакса на Markdown. Сите овие можат да бидат навистина корисни кога креирате корисни Барање за повлекување или издавање коментари или описи.

Листа на задачи

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

Можете да креирате листа на задачи како што е ова:

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

Ако го вклучиме ова во описот на нашето барање за повлекување или проблем, ќе го видиме како << _ eg_task_lists >>

Example Task List
Figure 98. Task lists rendered in a Markdown comment.

Ова често се користи во барањата за повлекување за да се покаже што би сакале да направите на филијалата пред да се појави барање за повлекување. Навистина кул дел е тоа што можете едноставно да кликнете на полињата за да го обновите коментарот - не мора да го уредувате Markdown директно за да ги проверите задачите.

Освен тоа, GitHub ќе бара листи со задачи во вашите Прашања и Повлекување барања и ќе ги прикаже како метаподатоци на страниците што ги наведуваат. На пример, ако имате барање за повлекување со задачи и гледате на страната за преглед на сите барања за повлекување, можете да видите колку е направено. Ова им помага на луѓето да ги срушат барањата за повлекување во подзадачи и им помага на другите луѓе да го следат напредокот на филијалата. Можете да видите пример за ова во << _ task_list_progress >>.

Example Task List
Figure 99. Task list summary in the Pull Request list.

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

Код фрагменти

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

За да додадете фрагмент од кодот, мора да го "оградите" во backticks.

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

Ако додадете име на јазик како што го сторивме таму со "java", GitHub исто така ќе се обиде да синтакса нагласи фрагмент. Во случај на горенаведениот пример, тоа ќе заврши како рендерирање како << _ md_code >>.

Rendered fenced code
Figure 100. Rendered fenced code example.

Цитирање

Ако реагирате на мал дел од долгите коментари, можете селективно да цитирате од другиот коментар од претходните линии со знакот >. Всушност, ова е толку вообичаено и толку корисно што за неа има кратенка на тастатурата. Ако нагласите текст во коментар за кој сакате директно да одговорите и да го притиснете копчето 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?

Once rendered, the comment will look like Rendered quoting example..

Rendered quoting
Figure 101. Rendered quoting example.

Emoji

Конечно, можете исто така да користите емоти во вашите коментари. Ова всушност се користи доста опширно во коментарите што ги гледате на многу прашања на GitHub и Pull Requests. Постои дури и помошник за емоции во GitHub. Ако пишувате коментар и почнувате со знак :, автокомплетер ќе ви помогне да го пронајдете она што го барате.

Emoji autocompleter
Figure 102. Emoji autocompleter in action.

Emojis земаат форма на : <name>: каде било во коментарот. На пример, би можеле да напишете нешто вака:

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:

Кога ќе биде изречена, ќе изгледа нешто како << _ md_emoji >>.

Emoji
Figure 103. Heavy emoji commenting.

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

Note

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

Слики

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

Drag and drop images
Figure 104. Drag and drop images to upload them and auto-embed them.

Ако погледнете на << _ md_drag >>, можете да видите мал "` Парсери како Markdown "навестување над полето за текст. Кликнување на тоа ќе ви даде целосен измамник на се што можете да направите со Markdown на GitHub.