-
1. Вступ
- 1.1 Про систему контролю версій
- 1.2 Коротка історія Git
- 1.3 Основи Git
- 1.4 Git, зазвичай, тільки додає дані
- 1.5 Три стани
- 1.6 Командний рядок
- 1.7 Інсталяція Git
- 1.8 Початкове налаштування Git
- 1.9 Отримання допомоги
- 1.10 Підсумок
-
2. Основи Git
- 2.1 Створення Git-репозиторія
- 2.2 Запис змін до репозиторія
- 2.3 Перегляд історії комітів
- 2.4 Скасування речей
- 2.5 Взаємодія з віддаленими сховищами
- 2.6 Теґування
- 2.7 Псевдоніми Git
- 2.8 Підсумок
-
3. Галуження в git
- 3.1 Гілки у кількох словах
- 3.2 Основи галуження та зливання
- 3.3 Управління гілками
- 3.4 Процеси роботи з гілками
- 3.5 Віддалені гілки
- 3.6 Перебазовування
- 3.7 Підсумок
-
4. Git на сервері
- 4.1 Протоколи
- 4.2 Отримання Git на сервері
- 4.3 Генерація вашого публічного ключа SSH
- 4.4 Налаштування Серверу
- 4.5 Демон Git
- 4.6 Розумний HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Варіанти стороннього хостингу
- 4.10 Підсумок
-
5. Розподілений Git
-
6. GitHub
-
7. Інструменти Git
- 7.1 Вибір ревізій
- 7.2 Інтерактивне індексування
- 7.3 Ховання та чищення
- 7.4 Підписання праці
- 7.5 Пошук
- 7.6 Переписування історії
- 7.7 Усвідомлення скидання (reset)
- 7.8 Складне злиття
- 7.9 Rerere
- 7.10 Зневадження з Git
- 7.11 Підмодулі
- 7.12 Пакування
- 7.13 Заміна
- 7.14 Збереження посвідчення (credential)
- 7.15 Підсумок
-
8. Налаштування Git
-
9. Git and Other Systems
- 9.1 Git як клієнт
- 9.2 Міграція на Git
- 9.3 Підсумок
-
10. Git зсередини
- 10.1 Кухонні та парадні команди
- 10.2 Об’єкти Git
- 10.3 Посилання Git
- 10.4 Файли пакунки
- 10.5 Специфікація посилань (refspec)
- 10.6 Протоколи передачі
- 10.7 Супроводження та відновлення даних
- 10.8 Змінні середовища
- 10.9 Підсумок
-
A1. Додаток A: Git в інших середовищах
- A1.1 Графічні інтерфейси
- A1.2 Git у Visual Studio
- A1.3 Git в Eclipse
- A1.4 Git у Bash
- A1.5 Git у Zsh
- A1.6 Git у Powershell
- A1.7 Підсумок
-
A2. Додаток B: Вбудовування Git у ваші застосунки
- A2.1 Git з командного рядка
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Додаток C: Команди Git
- A3.1 Налаштування та конфігурація
- A3.2 Отримання та створення проектів
- A3.3 Базове збереження відбитків
- A3.4 Галуження та зливання
- A3.5 Поширення й оновлення проектів
- A3.6 Огляд та порівняння
- A3.7 Зневаджування
- A3.8 Латання (patching)
- A3.9 Електронна пошта
- A3.10 Зовнішні системи
- A3.11 Адміністрування
- A3.12 Кухонні команди
6.2 GitHub - Як зробити внесок до проекту
Як зробити внесок до проекту
Тепер, коли ваш обліковий запис налаштовано, розгляномо деякі подробиці, що можуть стати вам у нагоді при роботі над вже існуючим проектом.
Робимо форк проекту
Якщо ви бажаєте зробити внесок до існуючого проекту, проте у вас немає права на викладання до нього змін, ви можете створити “форк” (fork) проекту.
Коли ви створюєте ``форк проекту, GitHub створює копію проекту, що є повністю вашою. Вона існує в просторі імен вашого користувача, ви можете викладати до неї зміни.
|
Зауваження
|
Історично термін “форк” має дещо негативне забарвлення, зазвичай це означало, що хтось узяв проект з відкритим кодом та повів його в іншому напрямку, іноді створюючи конкуруючий проект та забираючи частину розробників. У GitHub “форк” - це просто той самий проект у вашому власному просторі імен, що дозволяє вам робити зміни до проекту публічно, це засіб зробити внесок у більш відкритій спосіб. |
Таким чином, проектам не доводиться піклуватися про надання користувачам права на викладання змін. Кожен може створити форк проекту, викласти до нього зміни, та додати свої зміни до оригінального сховища за допомогою “Запита на Забирання Змін” (Pull Request), про який ми поговоримо далі. Цей запит відкриває нитку дискусії з можливістю переглядати код, власник та автор змін можуть спілкуватися про зміни доки власник не стане ними задоволений, після чого власник може злити зміни до свого сховища.
Щоб зробити форк проекту, зайдіть на сторінку проекту та натисніть на кнопку “Fork” зверху праворуч.
Через декілька секунд, ви опинитесь на сторінці вашого нового проекту, з вашою власною копією коду, яку ви можете змінювати.
Потік роботи GitHub
GitHub був спроектований навколо конкретного методу співпраці, в центрі якого Запит на Пул. Цей метод працює і в разі співпраці у маленькій команді в одному спільному сховищі, і в глобальній розподіленій компанії, чи мережі незнайомців, які допомагають проекту через десятки форків. Він базується на процесі роботи Тематичні гілки, який ми вже розглянули в Галуження в git.
Ось як це в цілому працює:
-
Створіть форк проекту.
-
Створіть гілку на основі
master, в ній ви будете робити всі свої зміни. -
Зробіть якісь коміти, що поліпшують проект.
-
Викладайте цю гілку до свого проекту GitHub.
-
Відкрийте Запит на Пул за допомогою GitHub.
-
Обговоріть зміни, можливо зробіть ще декілька комітів.
-
Власник проекту заливає до проекту Запит на Пул, або закриває його.
Це дуже схоже на процес роботи Integration Manager, який ми розглянули в Процес роботи з менеджером інтеграції, проте замість використання електронної пошти для спілкування та огляду змін, команди використовують інструменти сайту GitHub.
Детально розглянемо приклад того, як запропонувати зміни до проекту з відкритим кодом, що зберігає код на GitHub, за допомогою цієї схеми.
Створення запиту на пул
Тоні шукає код, який можна запустити на його мікроконтролері на платі Arduino, та знайшов чудовий програмний файл на GitHub за адресою https://github.com/schacon/blink.
Єдина проблема в тому, що частота миготіння занадто велика, ми гадаємо, що набагато краще чекати 3 секунди замість 1 між кожною зміною стану. Отже ми покращуємо програму та надсилаємо назад до проекту як пропоновану зміну.
Спочатку, ми натискаємо на кнопку 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 '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-
Клонуємо наш форк проекту локально
-
Створюємо окрему гілку зі зрозумілою назвою
-
Робимо наші зміни в коді
-
Перевіряємо, що зміни вірні
-
Робимо коміт наших змін до своєї гілки
-
Викладаємо нашу нову гілку назад до нашого форку GitHub.
Тепер, якщо ми повернемося до нашого форку на GitHub, ми можемо бачити, що GitHub помітив, що ми виклали нову гілку та виводить нам велику зелену кнопку щоб продивитись наші зміни та відкрити Запит на Пул до оригінального проекту.
Також ви можете перейти до сторінки “Branches” (гілки) за адресою https://github.com/<user>/<project>/branches, щоб знайти вашу гілку та відкрити новий Запит на Пул звідти.
Якщо ми натиснемо на цю зелену кнопку, ми побачимо сторінку, що просить надати нашому Запиту на злиття назву та опис. Майже завжди варто попрацювати над цим, оскільки гарний опис допомагає власнику оригінального проекту визначити, що ви намагалися зробити, чи правильні зміни ви пропонуєте, і чи прийняття цих змін поліпшить проект.
Ми також бачимо список комітів вашої гілки, які “ahead” (попереду) гілки master (у цьому випадку тільки один) та об’єднану різницю (unified diff) від усіх змін, що будуть зроблені, якщо цю гілку зіллє власник проекту.
Коли ви натиснете кнопку Create pull request (створити запит на пул) на цій сторінці, власник проекту, від якого ви створили форк, отримає повідомлення про те, що хтось пропонує зміни з посиланням на сторінку, що містить усю інформацію про ці зміни.
|
Зауваження
|
Хоч Запити на Пул зазвичай використовують у відкритих проектах так, як описано вище - коли зміни вже повністю готові, Запити на Пул також часто використовуються у внутрішніх проектах на початку циклу розробки. Оскільки ви можете продовжувати заливати зміни до гілки навіть після відкриття Запиту на Пул, нерідко його відкривають завчасно та використовують як спосіб ітеративного доопрацювання в команді, а не відкривають наприкінці процесу. |
Ітеративне доопрацювання за допомогою Запита на Пул
Тепер власник проекту може подивитися на пропоновані зміни та злити їх з проектом, відмовитись від них або прокоментувати їх. Припустимо, що ідея йому подобається, проте він бажає щоб світлодіод трохи довше був увімкнутим та вимкненим.
У представленому в Розподілений Git процесі роботи обговорення б проходило через електронну пошту, а на GitHub усе обговорення йде прямо на сайті. Власник проекту може продивлятись об’єднану різницю (unified diff) та залишити коментар, якщо він просто натисне на будь-який з рядків.
Коли супроводжувач (maintainer) зробить цей коментар, людина, що відкрила Запит на Пул (та насправді будь-хто, хто слідкує за сховищем) отримає повідомлення. Ми розглянемо прилаштування цього пізніше, проте якщо в нього були ввімкнені поштові повідомлення, Тоні отримає такого листа:
Хто завгодно може залишати загальні коментарі до Запиту на Пул. У Сторінка обговорення Запиту на Пул ми можемо побачити приклад того, як власник проекту прокоментував і окремий рядок коду, і залишив загальний коментар у секції обговорення. Ви можете побачити, що коментарі до коду також є частиною обговорення.
Тепер автори змін можуть бачити, що їм треба зробити, щоб їх зміни прийняли. На щастя це дуже просто зробити. Якби ви використовували пошту для спілкування, вам довелося б переробити ваші зміни та знову відправляти їх до поштової розсилки (mailing list), а за допомогою GitHub ви можете просто знову зробити коміт до своєї гілки та викласти зміни до GitHub, що автоматично оновить Запит на злиття. На Фінальний Запит на Пул ви також можете бачити, що коментарі до старого коду сховано в оновленому запиті на злиття, оскільки вони були зроблені до рядків, які відтоді змінилися.
Додавання комітів до існуючого запиту на злиття не спричиняє повідомлень, отже щойно Тоні надіслав свої виправлення, він вирішує залишити коментар, щоб проінформувати власників проекту, що він зробив потрібну зміну.
Зверніть увагу на те, що якщо ви натиснете на вкладку “Files Changed” (змінені файли) цього Запиту на Пул, ви отримаєте “об’єднану” різницю — тобто, повну агреговану різницю, яка буде додана до вашої головної гілки, якщо гілка зі змінами буде до неї злита. У термінах git diff, це просто автоматично виконана команда git diff master...<гілка>, для гілки, на якій базується цей Запит на Пул. Зверніться до Як дізнатися, що додано задля докладнішим описом цього типу різниці.
Ще ви помітите, що GitHub сам перевіряє, чи Запит на Пул може бути чисто злитим (без конфліктів) та показує кнопку для злиття прямо на сервері. Ця кнопка відображається тільки якщо у вас є доступ на запис до сховища та просте злиття можливе. Якщо ви на неї натиснете, GitHub зробить злиття “не-швидко-вперед” (non-fast-forward), тобто навіть якщо злиття могло бути здійснено швидко-вперед, все одно буде створений коміт злиття.
Якщо ви бажаєте, ви можете просто отримати гілку та злити її локально. Якщо ви зіллєте цю гілку до гілки master та викладете її до GitHub, Запит на Пул автоматично стане закритим.
Це базовий процес роботи, який використовує більшість проектів GitHub. Створюєте окрему гілку, одкриваєте Запит на Злиття для неї, виникає обговорення, можливо доводиться допрацювати цю гілку та нарешті запит або закривають, або зливають до проекту.
|
Зауваження
|
Не Тільки Форки
Важливо зазначити, що ви можете відкрити Запит на Пул між двома гілками одного сховища. Якщо ви працюєте над функціоналом з кимось та ви обидвоє маєте доступ на запис до проекту, ви можете викласти окрему гілку до сховища та відкрити Запит на Пул з неї до гілки |
Глибше про Запити на Пул
Ми розглянули основи того, як робити внесок до проекту на GitHub, розглянемо декілька цікавих порад та хитрощів про Запити на Пул, щоб ви могли користуватись ними ефективніше.
Запити на Пул як Патчі
Важливо розуміти, що багато проектів не розглядають Запити на Пул як чергу ідеальних патчів, які мають чисто накладатись саме в цьому порядку, як більшість основаних на поштових списках проектів розглядає послідовність патчів. Більшість проектів GitHub розглядають гілки Запитів на Пул як інтерактивну бесіду про запропоновані зміни, їх цікавить тільки результуючі зміни, які додаються до проекту за допомогою злиття.
Це важлива відмінність, адже зазвичай зміни пропонуються до того, як код доводять до ідеалу, що є дуже рідкісним у проектах, які використовують поштові списки з послідовностями патчів для співпраці. Це дозволяє обговоренню з супроводжувачем проекту розпочатись раніше, тому вірне рішення досягається спільними зусиллями. Коли код пропонується за допомогою Запита на Пул, та супроводжувачі або спільнота пропонує зміну, послідовність патчів зазвичай не створюється заново, а замість цього зміни просто викладаються як новий коміт до гілки, що просуває обговорення далі без втрати контексту попередньої праці.
Наприклад, якщо ви повернетесь та знову подивитесь на Фінальний Запит на Пул, ви можете помітити, що автор змін не робив перебазування свого коміту та не відправляв ще один Запит на Пул. Натомість він додав нові коміти та виклав їх до існуючої гілки. Таким чином, якщо ви повернетесь до цього Запиту на Пул у майбутньому, ви легко знайдете весь контекст всіх прийнятих рішень. При натисканні на кнопку “Merge” (злити) на сайті, GitHub навмисно створює коміт злиття з посиланням на Запит на Пул, щоб було легко повернутись та досліджувати обговорення при необхідності.
Йдемо в ногу з оригінальним проектом
Якщо ваш Запит на Пул стає застарілим, чи не може бути чисто злитим через щось інше, ви забажаєте виправити його, щоб супроводжувач проекту міг легко злити ваші зміни. GitHub перевіряє це та повідомляє вам наприкінці кожного Запиту на Пул чи може він бути злитим без конфліктів.
Якщо ви бачите щось схоже на Запит на Пул не може бути злитим чисто, ви захочете виправити свою гілку щоб зображення стало зеленим та супроводжувачу не довелося виконувати зайвої праці.
У вас є два основних варіанти, як це зробити. Ви можете перебазувати вашу гілку поверх цільової гілки (зазвичай це гілка master сховища, від якого ви зробили форк), або ви можете злити цільову гілку до вашої гілки.
Більшість розробників на 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-
Додаємо оригінальне сховище як віддалене під ім’ям “upstream”
-
Отримаємо останні зміни з цього сховища
-
Зливаємо головну гілку того сховища до нашої тематичної гілки
-
Виправляємо конфлікти
-
Заливаємо зміни назад до тієї ж нашої гілки
Щойно ви це зробите, Запит на Пул буде автоматично оновлений та знову пройде перевірка на можливість чистого злиття.
Одна з чудових рис Git полягає в тому, що ви можете це робити постійно. Якщо у вас дуже довготривалий проект, ви легко можете зливати з цільової гілки знов і знов та вам доведеться вирішувати тільки ті конфлікти, що виникли після останнього злиття, що дозволяє якось впоратися з процесом.
Якщо ви все одно бажаєте перебазувати гілку, щоб її почистити, ви безумовно можете це зробити, проте ми дуже рекомендуємо не заливати зміни насилу (force push) до гілки, для якої ви відкрили Запит на Злиття. Якщо інші люди взяли цю гілку та щось з нею робили, ви наштовхнетеся на багато труднощів, які описані в Небезпеки перебазовування. Замість цього, залийте перебазовану гілку до нової гілки на GitHub та відкривайте абсолютно новий Запит на Пул з посиланням на попередній, та закривайте перший.
Посилання
Можливо ваше наступне питання “А як мені зробити посилання на попередній Запит на Пул?”. Виявляється є дуже багато методів зробити посилання на інші речі будь-де, де ви можете писати на GitHub.
Почнемо з перехресних посилань між Запитом на Пул та Завданням (Issue). Усім Запитам на Злиття та Завданням присвоєні номери, що є унікальними в межах проекту. Наприклад, у вас може бути Запит на Пул #3 та Завдання #3. Якщо ви бажаєте послатись на будь-який Запит на Злиття чи Завдання з будь-якого іншого, ви можете просто написати #<номер> в будь-якому коментарі чи описі. Ви також можете бути більш детальними, якщо Завдання чи Запит на Пул знаходяться деінде. Пишіть <ім’я користувача>#<номер>, якщо ви хочете послатись на Завдання чи Запит на Пул у форку поточного сховища, або <ім’я користувача>/<назва сховища>#<номер>, щоб послатись на щось в іншому сховищі.
Розглянемо приклад. Припустимо, ми перебазували гілку в попередньому прикладі, створили новий запит на пул для неї, та тепер хочемо послатися на попередній запит на пул з нового. Ми також бажаємо послатись на завдання у форку сховища та на завдання з зовсім іншого проекту. Ми можемо заповнити поле опису як у Перехресні посилання в Запиті на Пул.
Коли ми відправимо цей запит на пул, ми побачимо, що він відображається як Відображення перехресних посилань у Запиті на Пул.
Зверніть увагу на те, що повний GitHub URL, що ми ввели, був скорочений саме так, щоб передати всю необхідну інформацію.
Тепер якщо Тоні повернеться назад та закриє оригінальний Запит на Пул, ми зможемо це побачити згадку про це в новому, адже GitHub автоматично створить подію зворотного стеження (trackback event) у хронології попереднього Запиту на Пул. Це означає, що будь-хто, хто зайде до цього Запиту на Пул та побачить, що він закритий, легко зможе перейти до сторінки запиту, що його замінив. Посилання буде виглядати приблизно як Згадка нового Запиту на Пул у журналі закритого Запиту на Пул..
Крім номерів завдань, ви також можете посилатись на окремий коміт за його SHA-1. Вам доведеться вказати всі 40 символів SHA-1, проте якщо GitHub побачить це в коментарі, він зробить посилання прямо на коміт. Знову ж таки, ви можете посилатись на коміти у форках чи інших сховищах саме так, як ви це робили із завданнями.
GitHub Flavored Markdown
Зв’язок з іншими завданнями це тільки мала частина цікавих речей, які ви можете робити майже в будь-якому текстовому полі на GitHub. В описах Завдань та Запитів на Пул, у коментарях, у коментарях до коду та ще багато де, ви можете використовувати так званий “GitHub різновид Markdown” (GitHub Flavored Markdown). Markdown це простий текст, який відображається з форматуванням.
Приклад написання та відображення GitHub-різновиду Markdown містить приклад того, як коментарі або текст можуть бути написані та відображені за допомогою Markdown.
GitHub-різновид Markdown додає деякі речі поза базовим синтаксисом Markdown. Вони можуть бути дуже корисними при створенні докладних описів Запитів на Пул або Завдань або коментарів до них.
Списки завдань
Перша дійсно корисна специфічна для GitHub функція Markdown, особливо при використанні з Запитами на Пул, це Список Завдань (Task List). Список завдань це список прапорців (checkbox) речей, які ви хочете зробити. Зазвичай його додають до Завдання або Запиту на Пул, щоб написати список речей, які мають бути виконані до того, як можна вважати роботу завершеною.
Ви можете створити список завдань так:
- [X] Write the code
- [ ] Write all the tests
- [ ] Document the codeЯкщо ми додамо це до опису нашого Запиту на Пул або Завдання, воно буде відображатись як Відображення списку завдань Markdown у коментарі.
Список завдань часто використовується в Запиті на Пул щоб позначити необхідні доопрацювання гілки, до того як Запит на Пул буде готовим до злиття. Дійсно чудове те, що ви можете просто натиснути на прапорець щоб оновити коментар — вам нема потреби редагувати код Markdown щоб змінювати позначку біля задачі.
Більш того, GitHub шукає список задач у ваших Завданнях та Запитах на Пул і відображає їх як метадані на сторінках, що виводять їх список. Наприклад, якщо ви маєте Запит на Пул із задачами та ви дивитесь на оглядову сторінку Запитів на Пул, ви зможете побачити як багато вже зроблено. Це допомагає людям розбити Запити на Пул на дрібніші завдання, та допомагає іншим слідкувати за прогресом гілки. Ви можете подивитись на приклад цього в Підсумок списку задач у списку Запитів на Пул..
Це неймовірно корисно, коли ви відкриваєте Запит на Пул заздалегідь та використовуєте його, щоб слідкувати за своїм прогресом під час написання нової функції.
Уривки коду
Ви також можете додавати уривки коду до коментарів. Це особливо корисно, якщо ви хочете показати щось, що ви могли б спробувати до того, як дійсно створювати такий коміт у своїй гілці. Їх також часто використовують щоб додати приклад коду, що не працює, чи коду, який міг би використати цей Запит на Пул.
Щоб додати уривок коду, вам треба “огородити” (fence) його зворотними апострофами.
```java
for(int i=0 ; i < 5 ; i++)
{
System.out.println("i is : " + i);
}
```Якщо додати назву мови, як ми зробили зараз (коли написали java), GitHub також спробує підсвітити синтаксис уривку.
Цитування
Якщо ви відповідаєте на маленьку частину довгого коментаря, ви можете вибірково процитувати частину іншого коментаря, якщо поставите на початку кожного рядка знак >. Насправді, це настільки поширена та корисна функція, що на клавіатурі для цього є окреме поєднання клавіш. Якщо ви виділите текст у коментарі, на який ви хочете відповісти та натиснете клавішу 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?При відображенні коментар буде виглядати як Відображення прикладу цитування..
Емодзі
Нарешті, ви також можете використовувати емодзі у ваших коментарях. Насправді їх використовують доволі широко в коментарях, їх можна побачити в багатьох Завданнях та Запитах на Пул GitHub. У GitHub навіть існує помічник емодзі.
Емодзі мають форму :<назва>: будь-де у коментарі. Наприклад, ви можете написати щось таке:
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:При відображенні, це виглядатиме приблизно як Сповнений емодзі коментар..
Не те щоб це дуже корисно, проте додає елемент розваги та емоцій до носія, в якому доволі важко передати емоції іншим чином.
|
Зауваження
|
Насправді доволі багато веб сервісів використовують символи емодзі. Чудова шпаргалка для пошуку емодзі, що виражає потрібну вам емоцію знаходиться за адресою: |
Зображення
Технічно це не є частиною Різновиду Markdown GitHUb, проте дуже корисно. На додаток до стандартного додавання посилань на зображення Markdown, що може бути доволі складним через необхідність шукати та вбудовувати URL, GitHub дозволяє вам просто перетягнути зображення до області вводу тексту, щоб вбудувати їх.
Якщо ви поглянете на Перетягування зображень щоб відвантажити та автоматично вбудувати їх., то побачите маленьку підказку “Parsed as Markdown” (оброблено як Markdown) над текстовим полем. Якщо ви натиснете на неї, вам нададуть повну шпаргалку всього, що ви можете робити за допомогою Markdown на GitHub.
