Content from Автоматизований контроль версій
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 5 хвилин
Огляд
Питання
- Що таке контроль версій і навіщо його використовувати?
Цілі
- Зрозуміти переваги автоматизованої системи контролю версій.
- Зрозуміти основи функціонування автоматизованих систем контролю версій.
Ми почнемо з розгляду того, як контроль версій може бути використаний для відстеження того, що і коли зробив один користувач. Навіть якщо ви не співпрацюєте з іншими людьми, автоматизований контроль версій набагато краще, ніж ця ситуація:

Ми всі були в цій ситуації раніше: здається непотрібним мати кілька майже ідентичних версій одного документа. Деякі текстові процесори дозволяють нам впоратися з цим трохи краще, наприклад, Microsoft Word може відстежувати зміни, Google Docs підтримує історію версій, а LibreOffice - запис та відображення змін.
Системи управління версіями починають зі зберігання базової (тобто початкової) версії документа, а потім записують зміни, які ви робите на кожному етапі редагування. Ви можете думати про це як про запис вашого прогресу: ви можете перемотати його назад, щоб почати з базової версії документу та відтворити кожну внесену вами зміну, в кінцевому підсумку прийшовши до вашої більш пізньої версії.
Якщо ви будете розглядати зміни, як щось окреме від самого документу, ви можете уявити собі процес «відтворення» різних наборів змін на базовому документі, який, зрештою, призведе до різних версій цього документа. Наприклад, два користувачі можуть робити незалежні набори змін в одному документі.
Якщо немає конфліктів, тобто немає ситуації, коли декілька користувачів вносять зміни до одного й того ж розділу документа, то буде можливо включити два набори змін до одного базового документа.
Система управління версіями - це інструмент, який відстежує ці зміни для нас, по суті створюючи різні версії наших файлів. Це дозволяє нам вирішити, які зміни будуть внесені до наступної версії (кожен запис цих змін називається коміт (commit)), і зберігає корисні метадані про зміни. Повна історія комітів для конкретного проєкту та їх метадані складають репозиторій (repository). Репозиторії, які знаходяться на різних комп’ютерах, можуть бути синхронізовані, що сприяє співпраці між різними людьми.
Давня історія систем управління версіями
Автоматизовані системи управління версіями не є чимось новим. Інструменти, такі як RCS, CVS, або Subversion існують з початку 1980-х років і використовуються багатьма великими компаніями. Однак багато з них зараз вважаються застарілими системами через різні обмеження у своїх можливостях. Більш сучасні системи, такі як Git та Mercurial, є розподіленими , що означає, що їм не потрібен централізований сервер для розміщення репозиторію. Ці сучасні системи також включають потужні інструменти злиття змін (merging), які дозволяють багатьом авторам працювати над одними й тими ж файлами одночасно.
Написання статті
Уявіть, що ви склали чудовий абзац для статті, яку ви пишете, але пізніше ви зіпсували його. Як би ви відродили попередню чудову версію вашого висновку? Чи можливо це взагалі?
Уявіть, що у вас є 5 співавторів. Як би ви відстежували зміни та коментарі, які вони вносять до вашої статті? Якщо ви використовуєте LibreOffice Writer або Microsoft Word, що станеться, якщо ви приймете зміни, внесені за допомогою опції
Відстежувати зміни
(“Track Changes”)? Чи будете ви мати історію цих змін?
Відновити чудову версію можливо тільки якщо ви створили копію старої версії статті. Ризик втрати хороших версій часто призводить до проблемного робочого процесу, проілюстрованого у коміксі з PhD Comics на початку цієї сторінки.
Спільна робота над документами за допомогою традиційних текстових процесорів є громіздкою. Або кожен співробітник повинен працювати над документом послідовно (сповільнюючи процес написання), або ви повинні відправляти нову версію всім співробітникам і вручну додавати їх коментарі у документ. Режими ‘відстеження змін’ (‘track changes’) або ‘запису змін’ (‘record changes’) можуть зробити зміни більш помітними та спростити їх додавання, але як тільки ви погоджуєтесь прийняти зміни, ви втрачаєте їх історію. Після цього ви більше не будете знати хто запропонував цю зміну, чому вона була запропонована, або коли вона була додана до документа. Навіть текстові онлайн-процесори, такі як Google Docs або Microsoft Office Online, не вирішують повністю ці проблеми.
Ключові моменти
- Контроль версій схожий на необмежене «undo».
- Контроль версій також дозволяє багатьом людям працювати паралельно.
Content from Налаштування Git
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 5 хвилин
Огляд
Питання
- Як треба налаштувати Git для його використання?
Цілі
- Налаштувати
git
під час його першого використання на комп’ютері. - Зрозуміти значення опції конфігурації
--global
.
Коли ми користуємося Git на новому комп’ютері вперше, нам потрібно налаштувати декілька речей. Нижче наведено кілька прикладів з налаштувань, які ми зробимо, коли почнемо працювати з Git:
- ваше ім’я та адреса електронної пошти,
- ваш бажаний текстовий редактор,
- а також те, що ми хочемо використовувати ці параметри глобально (тобто для кожного проєкту).
В командному рядку (command line), команди Git виглядають як
git verb options
, де verb
- це те що ми
фактично хочемо зробити, та options
- це додаткова
інформація, яка може бути потрібна для verb
. Отже, ось як
Альфредо налаштовує свій новий ноутбук:
BASH
$ git config --global user.name "Alfredo Linguini"
$ git config --global user.email "a.linguini@ratatouille.fr"
Будь ласка, використовуйте своє власне ім’я та електронну пошту замість “Alfredo”. Ці ім’я користувача та електронна пошта будуть асоційовані з вашою подальшою діяльністю Git, а це означає, що будь-які зміни надіслані в GitHub, BitBucket, GitLab або інший хост-сервер Git після цього уроку будуть містити цю інформацію.
У цьому уроці ми будемо працювати з GitHub, тож використовувана електронна пошта повинна бути такою ж, як і та, яка використовується для налаштування вашого облікового запису GitHub. Якщо вас турбує конфіденційність, перегляньте інструкції GitHub щодо збереження вашої електронної адреси конфіденційною.
Збереження конфіденційності вашої електронної адреси
Якщо ви вирішили приховати власну електронну адресу на GitHub, то
використовуйте у user.email
свою “no-reply” електронну
адресу, яку GitHub повʼязує з вашим обліковим записом. Вона має вигляд,
схожий на ID+username@users.noreply.github.com
. Ви можете
знайти цю адресу у налаштуваннях електронної
пошти для вашого облікового запису GitHub.
Закінчення рядків
Як і з іншими клавішами, коли ви натискаєте на клавіатурі Enter або ↵ (або Return на комп’ютері Mac), ваш комп’ютер кодує це як символ. Різні операційні системи використовують різні символи для позначення кінця рядка. (Ви також можете почути, що їх називають новими рядками або розривами рядків.) Оскільки Git використовує ці символи для порівняння файлів, це може спричинити несподівані проблеми під час редагування файлу на різних машинах. Хоча це поза межами цього уроку, ви можете більше прочитати про це питання у книзі “Pro Git”.
Ви можете змінити спосіб, у який Git розпізнає та кодує закінчення
рядків, використовуючи git config
з аргументом
core.autocrlf
. Рекомендуються наступні налаштування:
Для macOS і Linux:
Для Windows:
Альфредо також повинен налаштувати для використання з Git свій улюблений текстовий редактор, як наведено в таблиці нижче:
Редактор | Команда конфігурації |
---|---|
Atom | $ git config --global core.editor "atom --wait" |
nano | $ git config --global core.editor "nano -w" |
BBEdit (Mac, з інструментами командного рядка) | $ git config --global core.editor "bbedit -w" |
Sublime Text (Mac) | $ git config --global core.editor "/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl -n -w" |
Sublime Text (Windows, 32-бітна інсталяція) | $ git config --global core.editor "'c:/program files (x86)/sublime text 3/sublime_text.exe' -w" |
Sublime Text (Windows, 64-бітна інсталяція) | $ git config --global core.editor "'c:/program files/sublime text 3/sublime_text.exe' -w" |
Notepad (Windows) | $ git config --global core.editor "c:/Windows/System32/notepad.exe" |
Notepad++ (Windows, 32-бітна інсталяція) | $ git config --global core.editor "'c:/program files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" |
Notepad++ (Windows, 64-бітна інсталяція) | $ git config --global core.editor "'c:/program files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" |
Kate (Linux) | $ git config --global core.editor "kate" |
Gedit (Linux) | $ git config --global core.editor "gedit --wait --new-window" |
Scratch (Linux) | $ git config --global core.editor "scratch-text-editor" |
Emacs | $ git config --global core.editor "emacs" |
Vim | $ git config --global core.editor "vim" |
VS Code | $ git config --global core.editor "code --wait" |
Ви зможете переналаштувати текстовий редактор для Git у будь-який момент, якщо забажаєте пізніше його змінити.
Вихід з Vim
Зауважте, що Vim є редактором за замовчуванням для багатьох програм.
Якщо ви раніше не користувалися Vim і бажаєте вийти із сеансу без
збереження змін, натисніть Esc, потім введіть
:q!
і натисніть Enter або ↵ (або
Return на Mac). Якщо ви хочете зберегти зміни та вийти,
натисніть Esc, потім введіть :wq
і натисніть
Enter або ↵ (або Return на Mac).
Git (2.28+) дозволяє конфігурувати назву гілки, яка створюється під
час ініціалізації будь-якого нового репозиторію. Альфредо вирішив
використати цю можливість і назвав її main
, щоб це
відповідало налаштуванням у хмарному сервісі, який він зрештою
використовуватиме.
Назва гілки Git за замовчуванням
Зміни у змісті репозиторію пов’язані з “гілкою”. Для початківців у
цьому уроці буде достатньо знати, що гілки існують, і що в цьому уроці
використовується тільки одна гілка.
За замовчуванням, коли ви створюєте новий репозиторій за допомогою
git init
, Git створить гілку під назвою master
(як пояснюється в наступному епізоді). Цей термін нагадує про расистську
практику людського рабства, і тому спільнота розробників програмного
забезпечення перейшла до
більш інклюзивної мови.
В 2020, більшість сервісів хостингу репозиторіїв Git перейшли до
використання main
як стандартної гілки. Наприклад,
будь-який новий репозиторій, створений у GitHub і GitLab, за
замовчуванням буде використовувати гілку main
. Проте Git ще
не зробив таких самих змін. Як наслідок, локальні репозиторії повинні
бути налаштовані вручну, щоб мати ту саму назву головної гілки, що й
більшість хмарних сервісів.
При використанні попередніх версій Git (до 2.28), зміни можуть бути
внесені на рівні окремого репозиторію. Команда для цього знаходиться в
наступному епізоді. Зауважте, що якщо це значення не встановлено у вашій
локальній конфігурації Git, то init.defaultBranch
за
замовчуванням має значення master
.
П’ять команд, які ми щойно запустили вище, потрібно виконати лише
один раз: параметр --global
повідомляє Git про налаштування
для кожного проєкту у вашому обліковому записі користувача на цьому
комп’ютері.
Погляньмо на ці налаштування і протестуємо core.editor
прямо зараз:
Закриймо відкритий файл без внесення додаткових змін. Пам’ятайте, оскільки помилки у файлі конфігурації спричинять проблеми, безпечніше переглядати конфігурацію за допомогою
Якщо необхідно, змініть свою конфігурацію за допомогою тих самих команд, щоб вибрати інший редактор або оновити адресу електронної пошти. Це можна робити скільки завгодно разів.
Проксі-сервер
У деяких мережах потрібно використовувати проксі-сервер. Якщо це так, вам також може знадобитися повідомити про це Git:
Щоб вимкнути проксі, використовуйте
Довідка про Git та посібник користувача
Завжди пам’ятайте, що якщо ви забули підкоманди чи параметри команди
git
, ви можете отримати відповідний список параметрів,
ввівши git <command> -h
або подивитись документацію
до Git, ввівши git <command> --help
, наприклад:
Під час перегляду посібника пам’ятайте, що :
— це
підказка, яка вказує на очікування команди, і ви можете натиснути
Q, щоб вийти з посібника.
Загалом, ви можете отримати список доступних команд git
і подальші ресурси за допомогою цієї команди:
Ключові моменти
- Використовуйте
git config
з опцією--global
, щоб налаштувати ім’я користувача, адресу електронної пошти, редактор та інші параметри. Це треба робити один раз для кожної машини.
Content from Створення репозиторію
Останнє оновлення 2025-01-28 | Редагувати цю сторінку
Приблизний час: 10 хвилин
Огляд
Питання
- Де Git зберігає інформацію?
Цілі
- Створити локальний репозиторій Git.
- Пояснити призначення каталогу
.git
.
Після налаштування Git ми можемо почати його використання.
Ми продовжимо нашу вигадану історію, у якій Альфредо досліджує, чи можливо відправити планетарний посадковий модуль на Марс.
Перш за все, створімо у каталозі Desktop
новий
підкаталог для нашої роботи, а потім змінимо поточний робочий каталог на
новостворений:
Далі ми кажемо Git зробити recipes
репозиторієм -- місцем, де Git може
зберігати версії наших файлів:
Майте на увазі, що git init
створює репозиторій, до
якого можна додавати підкаталоги та їх файли. Немає потреби створювати
окремі репозиторії вкладені в репозиторій recipes
,
незалежно від того чи були підкаталоги присутні від початку або були
додані пізніше. Крім того, зверніть увагу, що створення каталогу
recipes
та його ініціалізація як репозиторію є повністю
окремими процесами.
Якщо ми використаємо ls
, щоб передивитись зміст
каталогу, то здається, що нічого не змінилося:
Але якщо ми додамо опцію -a
, щоб показати всі файли, то
побачимо, що Git створив у каталозі recipes
прихований
каталог під назвою .git
:
ВИХІД
. .. .git
Git використовує цей спеціальний підкаталог для зберігання всієї
інформації про проєкт, у тому числі відстежувані файли і підкаталоги, що
розташовані в каталозі проєкту. Якщо ми коли-небудь видалимо підкаталог
.git
, то ми втратимо усю історію проєкту.
Тепер ми можемо почати використовувати одну з найважливіших команд
git, яка особливо корисна для початківців. git status
друкує інформацію про поточний стан нашого проєкту, та перелік зроблених
змін у проєкті з варіантами щодо подальших дій. Ми можемо
використовувати цю команду необмежену кількість разів, як тільки ми
хочемо зрозуміти, що відбувається.
ВИХІД
On branch main
No commits yet
nothing to commit (create/copy files and use "git add" to track)
Якщо ви користуєтеся іншою версією git
, вигляд
результату цієї команди може дещо відрізнятися.
Де створювати репозиторії Git
Відстежуючи інформацію про рецепти (проєкт, який ми вже створили),
Альфредо також хотів би особливо відстежувати інформацію, пов’язану саме
з десертами. Альфредо створює проєкт desserts
всередині
свого проєкту recipes
за допомогою наступної послідовності
команд:
BASH
$ cd ~/Desktop # повернутися до каталогу Desktop
$ cd recipes # перейти до каталогу recipes, який вже є репозиторієм Git
$ ls -a # перевірити, що підкаталог .git все ще присутній у каталозі recipes
$ mkdir desserts # створити підкаталог recipes/desserts
$ cd desserts # перейти у підкаталог desserts
$ git init # створити репозиторій Git у підкаталозі desserts
$ ls -a # перевірити наявність підкаталогу .git, що підтверджує створення нового репозиторію
Чи потрібно запускати команду git init
у підкаталозі
desserts
для відстеження файлів, розташованих у підкаталозі
desserts
?
Ні. Альфредо не потрібно робити окремий підкаталог
desserts
репозиторієм Git, оскільки репозиторій
recipes
відстежуватиме будь-які файли, підкаталоги, та
файли у підкаталогах в ньому. Таким чином, щоб відстежувати всю
інформацію про десерти, Альфредо повинен був лише додати підкаталог
desserts
до каталогу recipes
.
Крім того, репозиторії Git можуть заважати один одному, якщо вони
“вкладені”: зовнішній репозиторій намагатиметься відстежувати зміни у
внутрішньому репозиторії. Тому найкраще кожного разу створювати новий
репозиторій Git в окремому каталозі. Щоб переконатися, що каталог не є
репозиторієм, перевірте результат команди git status
. Якщо
він виглядає як показано нижче, ви можете створити новий репозиторій, як
було показано вище:
ВИХІД
fatal: Not a git repository (or any of the parent directories): .git
Виправлення помилок git init
Джиммі пояснив Альфредо, що вкладений репозиторій є зайвим і може
призвести до плутанини у майбутньому. Альфредо бажав би повернутися до
попередньої організації проєкту де необхідний тільки один репозиторій
Git. Як Альфредо може скасувати свою останню команду
git init
виконану у підкаталозі desserts
?
Контекст
Видаляти файли з репозиторію Git треба обережно. Проте, ми ще не навчилися вказувати Git як відстежувати певний файл; про це ми дізнаємося в наступному епізоді. Файли, які не відстежуються Git, можна легко видалити, як і будь-які інші “звичайні” файли:
Подібним чином можна видалити каталог за допомогою команди
rm -r dirname
. Якщо файли чи каталоги, які видаляються
таким чином, вже відстежуються Git, тоді їх видалення стає ще однією
зміною, яку нам потрібно буде відстежувати (ми побачимо як це робити в
наступному епізоді).
Відповідь
Git зберігає всі свої файли в каталозі .git
. Щоб
виправити цю маленьку помилку, Альфредо може просто видалити каталог
.git
у підкаталозі desserts
, виконавши
наступну команду всередині каталогу recipes
:
Проте, будьте обережні! Виконання цієї команди у неправильному
каталозі призведе до видалення всієї історії змін проєкту, яку ви хотіли
б зберегти. Загалом, видалення файлів і каталогів за допомогою
rm
з командного рядка не можна скасувати. Тому завжди
перевіряйте свій поточний каталог за допомогою команди
pwd
.
Ключові моменти
-
git init
ініціалізує репозиторій. - Git зберігає всі дані репозиторію в каталозі
.git
.
Content from Відстеження змін
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 20 хвилин
Огляд
Питання
- Як зберегти зміни в Git?
- Як перевірити стан свого репозиторію?
- Як зробити нотатки про те, які зміни було внесено і чому?
Цілі
- Пройти цикл зміни-додавання-коміту для одного або декількох файлів.
- Пояснити де зберігається інформація на кожному етапі цього циклу.
- Пояснити різницю між інформативними та неінформативними повідомленнями комітів.
Спочатку переконаймося, що ми все ще у правильному каталозі. Ви
повинні знаходитися у каталозі recipes
.
Тепер створимо файл під назвою guacamole.md
з нашим
рецептом. Ми будемо використовувати редактор nano
для
редагування файлу; ви можете використовувати будь-який редактор, який
вам подобається. Зокрема, це не обовʼязково повинен бути
core.editor
, який ви раніше вказали глобально. Але
пам’ятайте, що команда bash для створення або редагування нового файлу
буде залежати від обраного редактора (який не обов’язково буде
nano
). Для довідки щодо текстових редакторів, дивіться “Which
Editor?” в уроці The Unix
Shell.
Введіть наведений нижче текст у файл guacamole.md
:
ВИХІД
# Guacamole
## Ingredients
## Instructions
Збережіть файл і вийдіть з редактора. Далі переконайтеся, що файл був
створений належним чином, запустивши команду ls
:
ВИХІД
guacamole.md
guacamole.md
містить три рядки, які ми можемо побачити,
запустивши:
ВИХІД
# Guacamole
## Ingredients
## Instructions
Якщо ми знову перевіримо статус нашого проєкту, Git повідомляє нам, що він помітив новий файл:
ВИХІД
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
guacamole.md
nothing added to commit but untracked files present (use "git add" to track)
Повідомлення “untracked files” означає, що в каталозі існує файл,
який Git не відстежує. Ми можемо повідомити Git, що цей файл треба
відстежувати за допомогою команди git add
:
та згодом переконатися, що все виглядає правильно:
ВИХІД
On branch main
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: guacamole.md
Git тепер знає, що він повинен стежити за файлом
guacamole.md
, але він ще не записав ці зміни як коміт. Щоб
зробити це, нам потрібно виконати ще одну команду:
ВИХІД
[main (root-commit) f22b25e] Create a template for recipe
1 file changed, 1 insertion(+)
create mode 100644 guacamole.md
Коли ми запускаємо git commit
, Git бере все, що ми
раніше запросили його зберегти за допомогою git add
, та
зберігає постійну копію цих змін у спеціальному каталозі
.git
. Ця постійна копія називається commit (або revision). У цьому прикладі коміт має
скорочений ідентифікатор f22b25e
. У вашого коміту може бути
інший ідентифікатор.
Ми використовуємо команду -m
(від “message”) щоб надати
короткий, інформативний та конкретний коментар, який допоможе нам
згадати пізніше про те, що ми зробили та чому. Якщо ми просто запустимо
git commit
без опції -m
, Git запустить
nano
(або будь-який інший редактор, який ми вказали як
core.editor
), щоб ми могли написати довше повідомлення.
Гарні повідомлення
комітів починаються з короткого (< 50 символів) тексту про зміни,
внесені в коміт. Загалом, повідомлення має завершувати речення “If
applied, this commit will”
Якщо ми тепер запустимо git status
:
ВИХІД
On branch main
nothing to commit, working tree clean
Git говорить нам, що поточний стан файлів відповідає їх стану, який
збережений у репозиторії. Якщо ми хочемо знати, що саме ми зробили
нещодавно - ми можемо попросити Git показати нам історію проєкту,
використовуючи git log
:
ВИХІД
commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
Author: Alfredo Linguini <a.linguini@ratatouille.fr>
Date: Thu Aug 22 09:51:46 2013 -0400
Create a template for recipe
git log
виводить перелік усіх комітів, які були внесені
до репозиторію, у зворотному хронологічному порядку. Для кожного коміту
буде надруковано повний ідентифікатор коміту (який починається з тих же
символів, що і скорочений ідентифікатор, попередньо надрукований
командою git commit
), автор коміту, дата його створення, і
повідомлення Git, яке було додано під час запису коміту.
Де зберігаються мої зміни?
Якщо ми тепер запустимо ls
, ми все одно побачимо лише
один файл, який називається guacamole.md
. Це відбувається
тому, що Git зберігає інформацію про історію файлів у спеціальному
каталозі .git
, згаданому раніше, щоб наша файлова система
не засмічувалася (і щоб ми випадково не могли змінити або видалити стару
версію).
Тепер припустимо, що Альфредо додає нову інформацію до файлу. (Знову
ж таки, ми будемо редагувати його за допомогою nano
, і
потім перевіряти його зміст за допомогою cat
; ви можете
користуватися іншим редактором, та можете не використовувати
cat
.)
ВИХІД
# Guacamole
## Ingredients
* avocado
* lemon
* salt
## Instructions
Тепер, коли ми запускаємо git status
, Git повідомляє
нам, що файл, про який він вже знає, був змінений:
ВИХІД
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: guacamole.md
no changes added to commit (use "git add" and/or "git commit -a")
Ключова фраза - це останній рядок: “no changes added to commit”. Ми
змінили цей файл, але ми ще не зберегли їх (що ми робимо за допомогою
git commit
), та навіть не сказали Git, що ми маємо намір
зберегти ці зміни у майбутньому (що ми робимо за допомогою
git add
). Тож зробімо це зараз. Хорошою рекомендацією є
перегляд наших змін кожного разу перед їх збереженням. Це робиться за
допомогою git diff
. Результат показує нам відмінності між
поточним станом файлу та його останньою збереженою версією:
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index df0654a..315bf3a 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -1,3 +1,6 @@
# Guacamole
## Ingredients
+* avocado
+* lemon
+* salt
## Instructions
Результат цієї команди важко зрозуміти, тому що це насправді серія
команд для таких інструментів, як редактори або patch
, яка
повідомляє їм, як змінити один файл за допомогою іншого. Якщо розділити
цей результат на фрагменти:
- Перший рядок вказує на те, що результат цієї команди у Git подібний
до Unix команди
diff
, яка порівнює стару та нову версії файлу. - Другий рядок повідомляє які саме версії файлу Git порівнює;
df0654a
та315bf3a
є унікальними ідентифікаторами цих версій. - Третій та четвертий рядки ще раз показують назву файлу, що змінюється.
- Решта рядків найцікавіші, вони показують нам фактичні відмінності і
рядки, у яких вони відбуваються. Зокрема, значок
+
в першому стовпці вказує де ми додали рядок.
Після того, як ми переглянули наші зміни, прийшов час зберегти їх:
ВИХІД
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: guacamole.md
no changes added to commit (use "git add" and/or "git commit -a")
Але це не спрацює: Git не буде додавати зміни, тому що ми не
використали спочатку git add
. Давайте це виправимо:
ВИХІД
[main 34961b1] Add basic guacamole's ingredient
1 file changed, 3 insertions(+)
Git наполягає, щоб ми додали файли до набору змін, які ми хочемо записати, перед тим як ми зробимо коміт. Це дозволяє зберігати зміни поступово та обʼєднувати їх у логічні блоки, аніж у великі набори змін. Наприклад, припустимо, ми робимо коміт кількох цитат відповідних досліджень у нашій дисертації. Можливо, ми бажаємо зберегти ці зміни, та відповідні записи у бібліографії, але не зберігати деякі інші зміни в нашій роботі (наприклад, висновок, який ми ще не закінчили).
Щоб це було можливо зробити, Git має спеціальну зону стейджингу (staging area), де він відстежує речі, які були додані до поточного набору змін (changeset) проте, ще не були збережені.
Зона стейджингу (staging area)
Якщо ви будете уявляти, ніби Git робить знімки змін протягом життя
проєкту, то git add
вказує що буде на знімку (додаючи речі
в зоні стейджингу), а git commit
після того насправді
робить знімок, та назавжди зберігає його (як коміт). Якщо у зоні
стейджингу нічого немає, то коли ви введете git commit
, Git
запропонує вам використати git commit -a
або
git commit --all
, який ніби збирає разом всіх, щоб зробити
групове фото! Однак майже завжди краще явним чином додати речі до зони
стейджингу, тому що без цього ви можете випадково зберегти інші зміни,
про які ви забули. (Повертаючись до порівняння з груповим фото, якщо ви
використали команду “-а”, до вашої фотографії може потрапити зайва
людина!) Тому додавайте речі в зону стейджингу власноруч - > в іншому
випадку вам може знадобитися шукати як використовувати “git undo commit”
частіше, ніж вам хотілося б!
Подивімося, як наші зміни у файлі проходять шлях від текстового редактора до зони стейджингу і далі у довгострокове зберігання. По-перше, ми покращимо наш рецепт, змінивши лимон на лайм:
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index 315bf3a..b36abfd 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -1,6 +1,6 @@
# Guacamole
## Ingredients
* avocado
-* lemon
+* lime
* salt
## Instructions
Поки що все добре: ми замінили один рядок (позначений -
)
на новий рядок (позначений +
). Тепер помістімо цю зміну у
зону стейджингу та подивимося що після цього звітує
git diff
:
Результату немає: це виглядає ніби для Git немає різниці між тим, що вже було збережено назавжди та тим, що зараз міститься у робочій директорії. Проте, якщо ми зробимо наступне:
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index 315bf3a..b36abfd 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -1,6 +1,6 @@
# Guacamole
## Ingredients
* avocado
-* lemon
+* lime
* salt
## Instructions
то ми побачимо різницю між останніми збереженими змінами та тими, які знаходяться в зоні стейджингу. Збережімо наші зміни:
ВИХІД
[main 005937f] Modify guacamole to the traditional recipe
1 file changed, 1 insertion(+)
Перевіримо наш статус:
ВИХІД
On branch main
nothing to commit, working tree clean
і подивимося на історію попередніх змін:
ВИХІД
commit 005937fbe2a98fb83f0ade869025dc2636b4dad5 (HEAD -> main)
Author: Alfredo Linguini <a.linguini@ratatouille.fr>
Date: Thu Aug 22 10:14:07 2013 -0400
Modify guacamole to the traditional recipe
commit 34961b159c27df3b475cfe4415d94a6d1fcd064d
Author: Alfredo Linguini <a.linguini@ratatouille.fr>
Date: Thu Aug 22 10:07:21 2013 -0400
Add basic guacamole's ingredients
commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
Author: Alfredo Linguini <a.linguini@ratatouille.fr>
Date: Thu Aug 22 09:51:46 2013 -0400
Create a template for recipe
Порівняння з підсвіткою змінених слів у рядках
Інколи, наприклад, у випадку текстових документів, результат
diff
дуже важко зрозуміти. Саме тут
--color-words
опція для git diff
є надзвичайно
зручною, бо вона виділяє кольором змінені слова.
Перегляд історії змін за сторінками
Коли розмір результату git log
перевищує розмір вашого
екрану, git
використовує спеціальну програму “пейджер”, щоб
поділити результат на сторінки розміром з ваш екран. Після виклику
“пейджера”, ви помітите, що останній рядок на екрані - це
:
, замість звичайного запрошення командного рядка.
- Натисніть Q, щоб вийти з пейджеру.
- Натисніть пробіл, щоб перейти на наступну сторінку.
- Щоб шукати
some_word
на всіх сторінках, натисніть / і введітьsome_word
. Натисніть N для навігації між результатами пошуку.
Обмеження розміру зображуваної історії змін
Щоб запобігти випадку, коли git log
повністю займає ваш
термінал, ви можете обмежувати кількість комітів які відображує Git,
використовуючи опцію -N
, де N
- кількість
комітів які б ви бажали бачити на екрані. Наприклад, якщо ви бажаєте
побачити лише останній коміт, використовуйте команду
ВИХІД
commit 005937fbe2a98fb83f0ade869025dc2636b4dad5 (HEAD -> main)
Author: Alfredo Linguini <a.linguini@ratatouille.fr>
Date: Thu Aug 22 10:14:07 2013 -0400
Modify guacamole to the traditional recipe
Ви також можете зменшити кількість інформації, використовуючи опцію
--oneline
:
ВИХІД
005937f (HEAD -> main) Modify guacamole to the traditional recipe
34961b1 Add basic guacamole's ingredients
f22b25e Create a template for recipe
Ви також можете комбінувати опцію --oneline
з іншими
опціями. Наступна корисна комбінація використовує опцію
--graph
для графічного зображення історії комітів за
допомогою псевдографіки, вказуючи при цьому які коміти пов’язані з
поточним HEAD
, поточною гілкою main
, або іншими
обʼєктами у репозиторії’:
ВИХІД
* 005937f (HEAD -> main) Modify guacamole to the traditional recipe
* 34961b1 Add basic guacamole's ingredients
* f22b25e Create a template for recipe
Каталоги
Дві важливі речі, які ви повинні знати про каталоги в Git.
- Git не відстежує каталоги самостійно, тільки файли всередині них. Спробуйте власноруч:
Зауважте, наш новостворений порожній каталог cakes
не
зʼявляється в переліку невідстежуваних файлів, навіть якщо ми конкретно
додали його (через git add
) до нашого репозиторію.
Ось чому ви іноді бачите файли .gitkeep
в інших порожніх
каталогах. На відміну від .gitignore
, ці файли не є
особливими і їх єдиною метою є заповнити каталог, щоб Git додав його до
репозиторію. Насправді ви можете назвати такі файли до вашої
вподоби.
- Якщо ви створюєте каталог у вашому репозиторії Git і заповнюєте його файлами, ви можете додати всі файли в каталозі одразу:
Спробуйте власноруч:
Перш ніж рухатися далі, ми збережемо ці зміни.
Для повторення: коли ми хочемо додати зміни до нашого репозиторію,
спочатку нам потрібно додати змінені файли в зону стейджингу
(git add
) а потім зберегти заплановані зміни до репозиторію
(git commit
):
{alt=‘Два документи окремо
додаються до зони стейджингу за допомогою git add, а потім об’єднуються
в один коміт за допомогою git commit’}
Вибір повідомлення коміту
Яке з наступних повідомлень буде найдоречнішим для останнього коміту
до guacamole.md
?
- “Changes”
- “Changed lemon for lime”
- “Guacamole modified to the traditional recipe”
Відповідь 1 є недостатньо детальною, а мета коміту неясна; відповідь 2 дублює результат команди “git diff” яка покаже зміни, зроблені у цьому коміті; відповідь 3 - оптимальна: коротка, інформативна, та імперативна.
Збереження змін у Git
Яка(які) з наведених нижче команд збережуть зміни у файлі
myfile.txt
до мого локального Git репозиторію?
Створить коміт, лише якщо файли вже були у зоні стейджінгу.
Намагатиметься створити новий репозиторій.
Правильна відповідь: спочатку додайте файл до зони стейджингу, потім зробіть коміт.
Спробує записати коміт файлу з назвою “my recent changes” з повідомленням myfile.txt.
Коміт декількох файлів
Зона стейджингу може зберігати зміни в будь-якій кількості файлів, які ви хочете записати в один коміт.
- Додайте до
guacamole.md
текст про приблизну ціну інгредієнтів. - Створіть новий файл
groceries.md
зі списком товарів та їх цінами на різних ринках. - Додайте зміни в обох файлах до зони стейджінгу, та зробіть коміт цих змін.
Спочатку ми оновимо файли guacamole.md
та
groceries.md
:
ВИХІД
# Guacamole
## Ingredients
* avocado (1.35)
* lime (0.64)
* salt (2)
ВИХІД
# Market A
* avocado: 1.35 per unit.
* lime: 0.64 per unit
* salt: 2 per kg
Тепер ви можете додати обидва файли до зони стейджингу. Ми можемо зробити це однією командою:
Або кількома:
Тепер файли готові до коміту. Ви можете перевірити це за допомогою
git status
. Якщо ви готові зробити коміт, використайте:
ВИХІД
[main cc127c2]
Write prices for ingredients and their source
2 files changed, 7 insertions(+)
create mode 100644 groceries.md
Вправа: репозиторій з вашою автобіографією
- Створіть новий репозиторій Git на вашому компʼютері під назвою
bio
. - Напишіть три рядки своєї біографії у файлі під назвою
me.txt
, та зробіть коміт цих змін. - Змініть один з рядків та додайте четвертий рядок.
- Покажіть відмінності між оновленим файлом та його попередньою версією.
За потреби вийдіть з каталогу recipes
:
Створіть новий каталог bio
та перейдіть до нього:
Ініціалізуйте репозиторій Git:
Створіть файл me.txt
з вашою біографією, використовуючи
nano
або інший текстовий редактор. Коли будете готові,
додайте його до зони стейджингу та запишіть коміт до репозиторію:
Змініть файл як вказано (змініть один рядок, додайте четвертий
рядок). Для того, щоб показати зміни між оновленим файлом та його
попередньою версією, використайте git diff
:
Ключові моменти
-
git status
показує стан репозиторію. - Файли можуть зберігатися в робочому каталозі проєкту (де їх бачать користувачі), зоні стейджингу (де будується наступний коміт) і локальному репозиторії (де коміти зберігаються постійно).
-
git add
додає файли до зони стейджингу. -
git commit
зберігає все, що міститься у зоні стейджингу, як новий коміт у локальному репозиторії. - Повідомлення коміту треба складати так, щоб воно чітко описувало ваші зміни.
Content from Дослідження історії
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 25 хвилин
Огляд
Питання
- Як визначити старі версії файлів?
- Як переглянути свої зміни?
- Як відновити старі версії файлів?
Цілі
- Пояснення, що таке HEAD репозиторію та як його використовувати.
- Визначення та використання ідентифікаторів комітів Git.
- Порівняння різних версій відстежуваних файлів.
- Відновлення старих версій файлів.
Як ми побачили у попередньому епізоді, ми можемо посилатися на коміти
за їх ідентифікаторами. Ви можете звернутися до останнього
коміту робочого каталогу за допомогою ідентифікатора
HEAD
.
Оскільки кожного разу ми додавали невеликі зміни до
guacamole.md
, зараз нам буде легко відстежувати наш
прогрес. Зробімо це, використовуючи HEAD
. Перш ніж ми
почнемо, змінімо guacamole.md
, додавши ще один рядок.
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
An ill-considered change
Тепер подивимося на наш результат.
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index b36abfd..0848c8d 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -4,3 +4,4 @@
* lime
* salt
## Instructions
+An ill-considered change
Це те саме, що ви отримаєте, якщо пропустите HEAD
(спробуйте це).
Але справжня користь полягає у тому, що ви таким чином можете посилатися
на попередні коміти. Наприклад, додаючи ~1
(де “~” - це
тільда), ми посилаємось на коміт зроблений безпосередньо перед
HEAD
.
Якщо ми хочемо побачити різницю між старішими комітами, ми можемо
знову використовувати git diff
, використовуючи для послання
на них HEAD~1
, HEAD~2
тощо:
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index df0654a..b36abfd 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -1,3 +1,6 @@
# Guacamole
## Ingredients
+* avocado
+* lime
+* salt
## Instructions
Ми також можемо використати команду git show
, яка
показує які зміни ми внесли у будь-якому попередньо зробленому коміті, а
також і повідомлення коміту (на відміну від команди
git diff
яка покаже різницю між комітом та нашим
робочим каталогом).
ВИХІД
commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
Author: Alfredo Linguini <a.linguini@ratatouille.fr>
Date: Thu Aug 22 10:07:21 2013 -0400
Create a template for recipe
diff --git a/guacamole.md b/guacamole.md
new file mode 100644
index 0000000..df0654a
--- /dev/null
+++ b/guacamole.md
@@ -0,0 +1,3 @@
+# Guacamole
+## Ingredients
+## Instructions
Таким чином, ми можемо побудувати ланцюжок комітів. Останній кінець
ланцюжка називається HEAD
; ми можемо посилатися на
попередні коміти, використовуючи нотацію ~
, тому
HEAD~1
означає “попередній коміт”, тоді як
HEAD~123
повертається на 123 коміти назад від того місця,
де ми зараз знаходимось.
Ми також можемо посилатися на коміти, використовуючи їх
ідентифікатори (ці довгі рядки цифр і літер), які можна побачити за
допомогою git log
та git show
. Це унікальні
ідентифікатори змін, де “унікальний” насправді означає унікальний: кожна
зміна будь-якого набору файлів на будь-якому комп’ютері буде мати
унікальний 40-символьний ідентифікатор. Наш перший коміт отримав
ідентифікатор f22b25e3233b4645dabd0d81e651fe074bd8e73b
, тож
спробуймо наступне:
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index df0654a..93a3e13 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -1,3 +1,7 @@
# Guacamole
## Ingredients
+* avocado
+* lime
+* salt
## Instructions
+An ill-considered change
Це правильна відповідь, проте, введення випадкових рядків з 40 символів дуже незручно. Тож Git дозволяє нам використовувати тільки перші кілька символів (як правило, сім для проєктів нормального розміру):
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index df0654a..93a3e13 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -1,3 +1,7 @@
# Guacamole
## Ingredients
+* avocado
+* lime
+* salt
## Instructions
+An ill-considered change
Це чудово! Отже, ми можемо зберегти зміни у файлах і побачити, що ми
змінили. Наступне питання - а як ми можемо відновити їх старіші версії?
Припустимо, що ми передумали щодо останнього оновлення файлу
guacamole.md
(рядок “ill-considered change”).
git status
зараз каже нам, що файл був змінений, але ці
зміни не були додані до зони стейджингу:
ВИХІД
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: guacamole.md
no changes added to commit (use "git add" and/or "git commit -a")
Ми можемо повернути цей файл до його попереднього стану за допомогою
git restore
:
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
Як можна здогадатися з назви, ‘git restore’ відновлює стару версію
файлу. За замовчуванням git restore
відновлює версію файлу,
записану в HEAD
, який є останнім збереженим комітом. Якщо
ми хочемо повернутися ще раніше, замість цього ми можемо використовувати
ідентифікатор коміту з опцією -s
:
ВИХІД
# Guacamole
## Ingredients
## Instructions
ВИХІД
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: guacamole.md
no changes added to commit (use "git add" and/or "git commit -a")
Звернуть увагу, що зміни зараз знаходяться у зоні стейджінгу та не
були збережені у коміті. Знову ж таки, ми можемо повернути цей файл до
його попереднього стану за допомогою git restore
:
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
Важливо пам’ятати, що ми повинні використовувати номер коміту, який
ідентифікує стан репозиторію до зміни, яку ми намагаємося
скасувати. Поширеною помилкою є використання номеру коміту, в якому ми
зробили зміни, які намагаємося скасувати. У наведеному нижче прикладі
нам треба ‘дістати’ передостанній коміт (HEAD~1
), тобто
коміт f22b25e
. Ми використовуємо .
, щоб
позначити всі файли:
Отже, якщо скласти це все разом, то Git працює як зображено у цьому коміксі:
Той факт, що файли можна відновлювати окремо, сприяє змінам в організації роботи. Якщо все знаходиться в одному величезному документі, буде важко (але не неможливо) скасувати зміни у вступі без скасування також змін, внесених пізніше до висновку. З іншого боку, якщо вступ і висновок зберігаються в окремих файлах, рухатися вперед і назад в часі стає набагато легше.
Відновлення старих версій файлу
Дженніфер зробила цього ранку деякі зміни у скрипті Python, над яким вона до цього працювала тижнями, та “зламала” його - він більше не запускається. Вона витратила майже годину, намагаючись виправити його, але безрезультатно…
На щастя, вона використовує Git для відстеження змін у свому проєкті!
Які з наведених нижче команд допоможуть їй відновити останню збережену у
Git версію її скрипту, який називається
data_cruncher.py
?
$ git restore
$ git restore data_cruncher.py
$ git restore -s HEAD~1 data_cruncher.py
$ git restore -s <unique ID of last commit> data_cruncher.py
Як 2, так і 4
Відповідь (5) - як 2, так і 4.
Команда restore
відновлює файли з репозиторію,
перезаписуючи файли у вашому робочому каталозі. Обидві відповіді 2 та 4
відновлюють останню збережену в репозиторії версію файлу
data_cruncher.py
. Відповідь 2 використовує
HEAD
, щоб вказати останній коміт, тоді як
відповідь 4 використовує унікальний ідентифікатор останнього коміту, що
саме й означає HEAD
.
Відповідь 3 замінить data_cruncher.py
його версією з
коміту перед HEAD
, що НЕ є тим, що ми хотіли.
Відповідь 1 призведе до помилки. Вам потрібно вказати файл, який
треба відновити. Якщо вам треба відновити всі файли, скористайтеся
git restore .
Скасування коміту
Дженніфер співпрацює з колегами над її скриптом Python. Вона
зрозуміла, що її останній коміт до репозиторію проєкту містив помилку, і
хоче його скасувати. Дженніфер хоче скасувати його правильним чином, щоб
всі користувачі репозиторію цього проєкту отримали правильні зміни.
Команда git revert [erroneous commit ID]
створить новий
коміт, який скасує помилковий коміт.
Команда git revert
відрізняється від
git restore -s [commit ID] .
тим, що
git restore
повертає файли (де зміни ще не ввійшли до
нового коміту у локальному репозиторії) до їх попереднього стану. У той
час, як git revert
скасовує зміни, які вже внесені до
локального та віддаленого репозиторіїв.
Нижче наведені правильні кроки та пояснення для Дженніфер щодо
користування git revert
. Яка команда відсутня?
________ # Подивіться на історію змін, щоб знайти ідентифікатор коміту
Скопіюйте цей ID (перші кілька символів ID, наприклад 0b1d055).
git revert [commit ID]
Введіть повідомлення для нового коміту.
Збережіть його та закрийте редактор.
Команда git log
зображує історію проєкту з
ідентифікаторами комітів.
Команда git show HEAD
покаже зміни, зроблені в
останньому коміті, і покаже його ID; однак Дженніфер повинна перевірити,
що це правильний коміт, а не нові зміни, які зробив у спільному
репозиторії хтось інший.
Розуміння послідовності дій та історії
Який результат останньої команди в цій послідовності?
BASH
$ cd recipes
$ echo "I like tomatoes, therefore I like ketchup" > ketchup.md
$ git add ketchup.md
$ echo "ketchup enhances pasta dishes" >> ketchup.md
$ git commit -m "My opinions about the red sauce"
$ git restore ketchup.md
$ cat ketchup.md # this will print the content of ketchup.md on screen
ВИХІД
ketchup enhances pasta dishes
ВИХІД
I like tomatoes, therefore I like ketchup
ВИХІД
I like tomatoes, therefore I like ketchup ketchup enhances pasta dishes
ВИХІД
Помилка, оскільки ви змінили ketchup.md, але не виконали коміт
Правильною є відповідь 2.
Зміни, внесені другою командою echo
, будуть зроблені
лише у робочій копії цього файлу, залишаючи версію в зоні стейджингу без
змін. Команда git add ketchup.md
розміщує поточну версію
‘ketchup.md’ в зоні стейджингу.
Тож, коли виконується команда
git commit -m "My opinions about the red sauce"
,
зафіксованою версією ketchup.md
є та, яка знаходиться в
зони стейджингу та буде мати тільки один рядок.
На цьому етапі робоча копія все ще містить другий рядок (та
git status
покаже, що файл змінено). Однак
git restore ketchup.md
замінить робочу копію останньою
збереженою версією ketchup.md
. В результаті,
cat ketchup.md
покаже:
ВИХІД
I like tomatoes, therefore I like ketchup
Перевіримо розуміння
git diff
Розглянемо команду git diff HEAD~9 guacamole.md
. Що ви
очікуєте від цієї команди після виконання? Що насправді відбувається,
коли ви запускаєте її? Чому?
Спробуйте іншу команду, git diff [ID] guacamole.md
, де
[ID] замінено на унікальний ідентифікатор вашого останнього коміту. Що
ви очікуєте, і що насправді станеться?
Скасування змін у зоні стейджингу
Команда git restore
може бути використана для
відновлення попереднього коміту, коли зміни ще не додані до зони
стейджингу. Але чи спрацює вона зі змінами, які були додані до зони
стейджингу, але ще не збережені у коміті? Зробіть зміни у
guacamole.md
, додайте їх до зони стейджингу за допомогою
git add
, а потім використайте git restore
, щоб
перевірити чи можете ви скасувати свої зміни.
Після додавання зміни за допомогою git restore
, команду
git checkout
не можна використовувати безпосередньо.
Подивіться на результат git status
:
ВИХІД
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: guacamole.md
Зауважте, якщо ваш результат відрізняється, то можливо ви забули змінити файл, або вже додали його до зони стейджингу та зробили коміт.
Використання команди git restore guacamole.md
тепер не
викликає помилки, але також не відновлює файл. Git друкує корисне
повідомлення - нам потрібно спочатку використати
git restore --staged
, щоб видалити файл з зони
стейджингу:
Тепер git status
зображує наступне:
ВИХІД
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git git restore <file>..." to discard changes in working directory)
modified: guacamole.md
no changes added to commit (use "git add" and/or "git commit -a")
Це означає, що тепер ми можемо використовувати
git restore
для відновлення файлу до попереднього
коміту:
ВИХІД
On branch main
nothing to commit, working tree clean
Перегляд і пошук в історії
Перегляд історії є важливим аспектом роботи з Git, але зазвичай знайти правильний ідентифікатор коміту може бути важко, особливо якщо він був зроблений декілька місяців тому.
Уявіть, що проєкт recipes
містить понад 50 файлів. Вам
потрібно знайти коміт, який змінює певний текст у
guacamole.md
. Коли ви вводите git log
,
з’являється дуже довгий список. Як можна звузити коло пошуку?
Пам’ятайте, що команда git diff
дозволяє перевіряти
зміни в певному файлі, наприклад, git diff guacamole.md
. Ми
можемо застосувати подібну ідею тут.
На жаль, деякі повідомлення комітів дуже неоднозначні, наприклад,
update files
. Як же переглянути усі ці версії файлу?
Обидві команди git diff
та git log
дуже
корисні для отримання звітів про різні частини історії проєкту. Але чи
можна об’єднати їх результат в одну команду? Спробуймо наступне:
Ви повинні отримати довгий список, у якому ви побачите як повідомлення коміту, так і зроблені зміни.
Питання: Що робить наступна команда?
Ключові моменти
-
git diff
показує відмінності між комітами. -
git restore
відновлює старі версії файлів.
Content from Ігнорування файлів
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 5 хвилин
Огляд
Питання
- Як зробити так, щоб Git ігнорував файли, які я не хочу відстежувати?
Цілі
- Налаштувати Git для ігнорування певних файлів.
- Зрозуміти чому ігнорування файлів може бути корисним.
Що робити, якщо у нас є файли, які ми не хочемо відстежувати у Git, наприклад, резервні файли, створені нашим редактором або проміжні файли, створені під час аналізу даних? Створімо декілька фіктивних файлів:
і подивимося, що скаже Git:
ВИХІД
On branch main
Untracked files:
(use "git add <file>..." to include in what will be committed)
a.png
b.png
c.png
receipts/
nothing added to commit but untracked files present (use "git add" to track)
Відстеження цих файлів за допомогою контролю версій буде марною тратою місця на диску. Що гірше, висвітлення змін в них під час перегляду історії або статусу проєкту може відвернути нас від змін, які насправді важливі, Тож скажімо Git, що ці файли треба ігнорувати.
Ми можемо зробити це, створюючи у кореневому каталозі нашого проєкту
файл під назвою .gitignore
:
ВИХІД
*.png
receipts/
Ці шаблони наказують Git ігнорувати будь-який файл, ім’я якого
закінчується на .png
, і все в каталозі
receipts
. (Якщо будь-які з цих файлів вже відстежуються, то
Git продовжить їх відстежувати.)
Як тільки ми створили цей файл, результат команди
git status
стає набагато зрозумілішим:
ВИХІД
On branch main
Untracked files:
(use "git add <file>..." to include in what will be committed)
.gitignore
nothing added to commit but untracked files present (use "git add" to track)
Єдина річ, яку Git помічає зараз - це новостворений файл
.gitignore
. Ви можете подумати, що його не треба
відстежувати, але всі, з ким ми ділимося нашим репозиторієм, ймовірно,
захочуть ігнорувати ті самі речі, які ігноруємо ми. Додамо до
репозиторію та здійснимо коміт файлу .gitignore
:
ВИХІД
On branch main
nothing to commit, working tree clean
Як бонус, використання .gitignore
допомагає нам уникнути
випадкового додавання до репозиторію файлів, які ми не хочемо
відстежувати:
ВИХІД
The following paths are ignored by one of your .gitignore files:
a.png
Use -f if you really want to add them.
Якщо ми дійсно хочемо змінити наші налаштування ігнорування, ми
можемо використати git add -f
, щоб змусити Git щось додати.
Наприклад, git add -f a.csv
. Якщо потрібно, можна також
побачити статус ігнорованих файлів:
ВИХІД
On branch main
Ignored files:
(use "git add -f <file>..." to include in what will be committed)
a.png
b.png
c.png
receipts/
nothing to commit, working tree clean
Якщо ви хочете ігнорувати лише вміст receipts/plots
, ви
можете зробити це шляхом додавання наступного рядка до вашого
.gitignore
:
ВИХІД
receipts/plots/
Цей рядок забезпечить ігнорування лише вмісту
receipts/plots
, але не вмісту
receipts/data
.
Як і в більшості питань програмування, є ще кілька альтернативних способів, які можуть забезпечити виконання цього правила ігнорування. Вправа “Варіант ігнорування вкладених файлів” нижче має трохи іншу структуру каталогів, та пояснює альтернативну відповідь. Крім того, сторінка обговорення має більш детальну інформацію про правила ігнорування.
Додавання конкретних файлів
Як ігнорувати всі файли .png
у кореневому каталозі, за
винятком final.png
? Підказка: дізнайтеся, що робить
!
(оператор знаку оклику).
Треба додати наступні два рядки до вашого файлу
.gitignore
:
ВИХІД
*.png # ignore all png files
!final.png # except final.png
Знак оклику призведе до включення раніше виключеного запису.
Зауважте також, що оскільки ви вже зберегли файли .png
у
комітах у цьому уроці, вони не будуть проігноровані цим новим правилом.
Тільки майбутні додавання .png
файлів до кореневого
каталогу будуть проігноровані.
Варіант ігнорування вкладених файлів
Нехай ми маємо структуру каталогів, яка виглядає подібно до попередньої вправи “Ігнорування файлів у підкаталогах”, проте дещо відрізняється:
Як би ви проігнорували весь вміст у каталозі receipts
,
крім receipts/data
?
Підказка: подумайте про те, як ви раніше зробили виняток за допомогою
оператору !
.
Щоб проігнорувати все в каталозі receipts/
без
receipts/data/
, можна змінити ваш.gitignore
,
щоб ігнорувати вміст каталогу receipts
, але створити
виняток для вмісту підкаталогу receipts/data
. Ваш
.gitignore
буде виглядати так:
ВИХІД
receipts/* # ігнорувати все в каталозі receipts
!receipts/data/ # не ігнорувати вміст каталогу receipts/data/
Ігнорування всіх файлів з даними у каталозі
Припустимо, що у вас порожній файл .gitignore
, і ви
бачите структуру каталогів, яка виглядає так:
BASH
receipts/data/market_position/gps/a.dat
receipts/data/market_position/gps/b.dat
receipts/data/market_position/gps/c.dat
receipts/data/market_position/gps/info.txt
receipts/plots
Яке найкоротше правило ви можете додати до .gitignore
,
щоб ігнорувати всі файли з розширенням .dat
у каталозі
result/data/market_position/gps
? При цьому, не ігноруйте
info.txt
.
Додавання receipts/data/market_position/gps/*.dat
призведе до ігнорування усіх файлів у
receipts/data/market_position/gps
, які закінчуються на
.dat
. Файл
receipts/data/market_position/gps/info.txt
не буде
проігноровано.
Ігнорування всіх файлів з даними у репозиторії
Припустимо тепер, що у вас є багато файлів з розширенням
.csv
в різних підкаталогах вашого репозиторію. Наприклад,
ви можете мати:
BASH
results/a.csv
data/experiment_1/b.csv
data/experiment_2/c.csv
data/experiment_2/variation_1/d.csv
Як ігнорувати всі файли .csv
без явного переліку усіх
відповідних каталогів?
Додайте наступний рядок до файлу .gitignore
:
ВИХІД
**/*.csv
Це призведе до ігнорування усіх файлів .csv
, незалежно
від їх розташування у дереві каталогів. Ви все ще можете робити певні
винятки з цього правила за допомогою знаку оклику.
Оператор !
скасує запис з попередньо визначеного шаблону
ігнорування. Оскільки запис ! *.csv
скасовує всі попередні
файли .csv
в .gitignore
, жоден з них не буде
проігноровано, і всі файли .csv
будуть відстежуватися.
Log-файли
Ви написали скрипт, який створює багато проміжних log-файлів з
назвами log_01
, log_02
, log_03
тощо. Ви хочете зберегти їх, але не бажаєте відстежувати їх за допомогою
git
.
Додайте до
.gitignore
один рядок, який виключає файлиlog_01
,log_02
тощо.Перевірте свій “шаблон ігнорування”, створивши деякі фіктивні файли з назвами
log_01
,log_02
тощо.Уявіть тепер, що файл
log_01
дуже важливий, та додайте його до відстежуваних файлів, не змінюючи.gitignore
.Обговоріть з сусідом, які інші типи файлів можуть перебувати у вашому проєкті, які ви не бажаєте відстежувати і тому бажаєте проігнорувати за допомогою
.gitignore
.
додайте або
log_*
абоlog*
як новий рядок до вашого.gitignore
відстежуйте
log_01
за допомогоюgit add -f log_01
Ключові моменти
- Текстовий файл
.gitignore
інформує Git про те, які файли треба ігнорувати в репозиторії. - Ви можете вказати певні файли або каталоги, які Git буде ігнорувати, або вказати типи файлів, які зазвичай ігноруються.
Content from Віддалені репозиторії у GitHub
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 45 хвилин
Огляд
Питання
- Як я можу поділитися своїми змінами з іншими через Інтернет?
Цілі
- Зрозуміти, що таке віддалені репозиторії та чому вони корисні.
- Навчитися надсилати до та отримувати зміни з віддаленого репозиторію.
Контроль версій дійсно вступає у свою силу, коли ми починаємо співпрацювати з іншими людьми. У нас вже є більша частина механізму для цього; єдине, чого не вистачає - це знати, як копіювати зміни з одного репозиторію в інший.
Такі системи, як Git, дозволяють пересилати інформацію про зміни між будь-якими двома репозиторіями. Однак на практиці найпростіше використовувати одну копію як центральний вузол у мережі репозиторіїв, і зберігати його в мережі, аніж на чиємусь ноутбуці. Багато програмістів використовують послуги хостингу, такі як GitHub, Bitbucket або GitLab щоб зберігати основні копії; ми розглянемо плюси та мінуси цього в іншому епізоді.
Ми почнемо з того, що поділимося зі світом змінами, які ми внесли до нашого поточного проєкту. З цією метою ми збираємося створити віддалений репозиторій, який буде пов’язаний з нашим локальним репозиторієм.
1. Створіть віддалений репозиторій
Увійдіть до GitHub, потім натисніть
на значок у верхньому правому куті, щоб створити новий репозиторій під
назвою recipes
:

Назвіть ваш репозиторій “recipes” і потім натисніть на “Create Repository”.
Зауважте: оскільки цей репозиторій буде підʼєднано до локального репозиторію, він має бути порожнім. Залиште “Initialize this repository with a README” непозначеним, та оберіть “None” як опції для обох “Add .gitignore” та “Add a license”. Дивіться вправу “Файли ліцензії та README” нижче для повного пояснення того, чому репозиторій повинен бути порожнім.

Як тільки репозиторій створено, GitHub відображає сторінку з URL і певною інформацією про те, як налаштувати локальний репозиторій:

Насправді це робить наступне на сервері GitHub:
Якщо ви пам’ятаєте, в одному з попередніх
епізодів, де ми додавали та зберігали нашу попередню роботу над
guacamole.md
, в нас була діаграма, яка зображувала
локальний репозиторій, та виглядала так:
Тепер, коли ми маємо два репозиторії, нам потрібна така діаграма:
Зауважте, що наш локальний репозиторій все ще містить нашу попередню
роботу над guacamole.md
, але віддалений репозиторій на
GitHub виглядає порожнім, оскільки він ще не містить файлів.
2. Підʼєднання локального репозиторію до віддаленого
Тепер підключаємо два сховища одне до одного. Ми робимо це вказуючи GitHub репозиторій у якості віддаленого для локального репозиторію. Домашня сторінка репозиторію на GitHub містить URL, який нам потрібен, щоб його ідентифікувати:

Натисніть на кнопку ‘SSH’, щоб змінити протокол з HTTPS на SSH.
HTTPS в порівнянні з SSH
Ми використовуємо тут SSH тому що, хоча він і вимагає додаткову конфігурацію, це є протокол безпеки, який широко використовується багатьма програмами. Наведені нижче кроки описують SSH на мінімальному рівні, необхідному рівні для роботи з GitHub.

Скопіюйте цю URL-адресу з браузера, перейдіть до локального
репозиторію recipes
, та виконайте цю команду:
Make sure to use the URL for your repository rather than Alfredo’s:
the only difference should be your username instead of
alflin
.
origin
- імʼя, яке використовується локально для
позначення віддаленого репозиторію. Його можна було б назвати як
завгодно, але origin
- це домовленість, яка часто
використовується за замовчуванням в git та GitHub, так що корисно
дотримуватися її, якщо немає особливої причини це не робити.
Ми можемо перевірити, що команда спрацювала за допомогою
git remote -v
:
ВИХІД
origin git@github.com:alflin/recipes.git (fetch)
origin git@github.com:alflin/recipes.git (push)
Детальніше віддалені репозиторії ми розглянемо у наступному епізоді, а поки поговоримо про те, як вони можуть бути використані для співпраці.
3. Необхідна інформація про SSH протокол та його налаштування
Перш ніж Альфредо зможе підʼєднатися до віддаленого репозиторію, він має налаштувати спосіб автентифікації свого комп’ютера у GitHub. Це потрібно для того, щоб GitHub міг розпізнати його, коли він намагається підʼєднатися до свого віддаленого репозиторію.
Ми збираємось налаштувати метод, який зазвичай використовується багатьма різними службами для автентифікації доступу з командного рядка. Цей метод називається Secure Shell Protocol (SSH). SSH - це кріптографічний мережевий протокол, який дозволяє безпечний зв’язок між комп’ютерами через ненадійну комунікаційну мережу.
SSH використовує так звану пару ключів. Ці два ключі працюють разом для надання доступу. Один ключ публічно відомий - він називається відкритим ключем, інший ключ називається приватним ключем, та має бути доступним тільки його власнику. Дуже логічні назви!
Ви можете уявити відкритий ключ як навісний замок, від якого тільки у вас є ключ (тобто ваш приватний ключ), щоб відчинити його. Ви використовуєте свій відкритий ключ тоді, коли вам потрібно мати безпечний спосіб зв’язку, наприклад, щоб використовувати ваш обліковий запис на GitHub. Тоді ви даєте GitHub цей замок (відкритий ключ) та кажете: “Заблокувати доступ до мого облікового запису таким чином, щоб тільки комп’ютери, які мають мій закритий ключ, могли розблокувати зв’язок та виконувати команди git від імені мого облікового запису на GitHub.”
Те, що ми зараз зробимо - це мінімум, необхідний для налаштування SSH-ключів та додання відкритого ключа до вашого акаунту на GitHub.
Подальша інформація про SSH
Тепер ми розглянемо SSH та пари ключів більш глибоко і детально.
Перше, що ми зробимо - це перевіримо, чи необхідні налаштування вже були зроблені на комп’ютері, на якому ви працюєте зараз. Тому що, зазвичай, ці налаштування треба зробити тільки один раз для кожного комп’ютера, а після цього про них можна забути.
Тримайте ваші ключі у надійному місці
Насправді, ви не повинні забувати про ваші SSH ключі, оскільки вони відповідають за безпеку вашого облікового запису. Корисно періодично перевіряти ваші приватні ключі. Це особливо важливо, якщо ви використовуєте декілька комп’ютерів для доступу до вашого облікового запису.
Ми запустимо команду ls
(список), щоб перевірити, які
пари ключів вже існують на вашому комп’ютері.
Ваш результат буде виглядати трохи інакше в залежності від того, чи був коли-небудь SSH налаштований на комп’ютері, який ви використовуєте, чи ні.
Альфредо ще не налаштував SSH на його комп`ютері, тож його результат виглядає так
ВИХІД
ls: cannot access '/c/Users/Alfredo/.ssh': No such file or directory
Якщо SSH вже налаштований на комп’ютері, який ви використовуєте, то
ви побачите перелік пар відкритих та приватних ключів. Назви файлів
будуть або id_ed25519
/id_ed25519.pub
, або
id_rsa
/id_rsa.pub
у залежності від того, як ці
пари ключів були створені. Оскільки Альфредо не має цих файлів на його
комп`ютері, він використовує цю команду для їх створення.
3.1 Створення пари ключів SSH
Для створення пари SSH ключів Альфредо використовує наступну команду,
де параметр -t
визначає який тип алгоритму використовувати,
а параметр -C
додає до ключа коментар (який у цьому випадку
є електронною поштою Альфредо):
Якщо ви використовуєте старішу систему, яка не підтримує алгоритм
Ed25519, то використовуйте:
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
ВИХІД
Generating public/private ed25519 key pair.
Enter file in which to save the key (/c/Users/Alfredo/.ssh/id_ed25519):
Ми бажаємо використовувати імʼя та розташування файлу за замовчуванням, тому просто натисніть Enter.
ВИХІД
Created directory '/c/Users/Alfredo/.ssh'.
Enter passphrase (empty for no passphrase):
Тепер Альфредо має обрати пароль. Оскільки він використовує свій ноутбук на кухні, де до нього мають доступ інші люди, він хоче створити пароль. Обов’язково використовуйте пароль, який можна запам’ятати, або збережіть пароль десь у надійному місці, оскільки тут немає опції «змінити мій пароль». Зверніть увагу на те, що під час введення пароля в терміналі нічого не зображується. Це нормально: ваш пароль буде збережено, навіть якщо ви нічого не побачите на екрані.
ВИХІД
Enter same passphrase again:
Після введення того ж самого пароля вдруге ми отримуємо підтвердження
ВИХІД
Your identification has been saved in /c/Users/Alfredo/.ssh/id_ed25519
Your public key has been saved in /c/Users/Alfredo/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:SMSPIStNyA00KPxuYu94KpZgRAYjgt9g4BA4kFy3g1o a.linguini@ratatouille.fr
The key's randomart image is:
+--[ED25519 256]--+
|^B== o. |
|%*=.*.+ |
|+=.E =.+ |
| .=.+.o.. |
|.... . S |
|.+ o |
|+ = |
|.o.o |
|oo+. |
+----[SHA256]-----+
Насправді під “identification” тут мається на увазі приватний ключ. Ви ніколи не повинні ділитися ним з іншими. На відміну від приватного ключа, відкритий ключ у цьому повідомленні так і називається - “public key”. Щодо “key fingerprint”, він є коротшою версією відкритого ключа.
Тепер, коли ми створили ключі SSH, відповідні файли будуть знайдені:
ВИХІД
drwxr-xr-x 1 Alfredo 197121 0 Jul 16 14:48 ./
drwxr-xr-x 1 Alfredo 197121 0 Jul 16 14:48 ../
-rw-r--r-- 1 Alfredo 197121 419 Jul 16 14:48 id_ed25519
-rw-r--r-- 1 Alfredo 197121 106 Jul 16 14:48 id_ed25519.pub
3.2 Копіювання відкритого ключа у GitHub
Тепер ми маємо пару ключів SSH, та можемо запустити наступну команду, щоб перевірити, чи може GitHub дозволити нашу автентифікацію.
ВИХІД
The authenticity of host 'github.com (192.30.255.112)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? y
Please type 'yes', 'no' or the fingerprint: yes
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
git@github.com: Permission denied (publickey).
Отже, ми забули, що нам спочатку потрібно надати GitHub наш відкритий ключ!
По-перше, нам потрібно скопіювати відкритий ключ. Не забудьте додати
.pub
в кінці цієї команди - в іншому випадку ви будете
дивитись на приватний ключ.
ВИХІД
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDmRA3d51X0uu9wXek559gfn6UFNF69yZjChyBIU2qKI a.linguini@ratatouille.fr
Тепер, перейшовши до GitHub.com, натисніть на іконку свого облікового запису у верхньому правому куті, щоб відкрити відповідне меню. Далі натисніть “Settings,” а потім на сторінці налаштувань ліворуч знайдіть та натисніть “SSH and GPG keys”. Далі натисніть “New SSH key” кнопку праворуч. Тепер ви можете додати назву ключа (Альфредо використовує назву “Alfredo’s Kitchen Laptop” щоб запамʼятати, де розташовані оригінальні пари ключів), скопіювати свій SSH ключ та вставити його у відповідне поле, а потім натиснути кнопку “Add SSH key”, щоб завершити налаштування.
Тепер, коли ми усе налаштували, ми знову перевіримо нашу автентифікацію з командного рядка.
ВИХІД
Hi Alfredo! You've successfully authenticated, but GitHub does not provide shell access.
Добре! Цей результат підтверджує, що ключ SSH працює як очікується. Тепер ми готові завантажити нашу роботу до віддаленого репозиторію.
4. Завантаження локальних змін до віддаленого репозиторію
Тепер, коли аутентифікація налаштована, ми можемо повернутися до віддаленого репозиторію. Наступна команда завантажить зміни з нашого локального репозиторію до репозиторію на GitHub:
Оскільки Альфредо встановив пароль для свого ключа, то йому буде потрібно його ввести після відповідного запитання. Якщо ви не встановили пароль для свого ключа, то команда не буде його запитувати.
ВИХІД
Enumerating objects: 16, done.
Counting objects: 100% (16/16), done.
Delta compression using up to 8 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (16/16), 1.45 KiB | 372.00 KiB/s, done.
Total 16 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), done.
To https://github.com/alflin/recipes.git
* [new branch] main -> main
Проксі-сервер
Якщо мережа, до якої ви підключені, використовує проксі-сервер, то можливо, що ваша остання команда зазнала невдачі з повідомленням про помилку “Could not resolve hostname”. Щоб розвʼязати цю проблему, потрібно проінформувати Git про проксі-сервер:
BASH
$ git config --global http.proxy http://user:password@proxy.url
$ git config --global https.proxy https://user:password@proxy.url
Коли ви підключаєтеся до іншої мережі, яка не використовує проксі-сервер, вам буде потрібно відключити використання проксі у Git за допомогою наступних команд:
Менеджери паролів
Якщо у вашій операційній системі налаштовано менеджер паролів,
git push
спробує використати його, коли йому знадобляться
ваші імʼя користувача і пароль. Наприклад, це є стандартною поведінкою
Git Bash у Windows. Якщо ви бажаєте вводити своє ім`я користувача та
пароль в терміналі замість використання менеджеру паролів, то
введіть:
у терміналі, перед тим як виконати git push
. Незважаючи
на імʼя змінної SSH_ASKPASS
, Git
використовує значення SSH_ASKPASS
для усіх методів
автентифікації записів, тож ви можете відмінити
SSH_ASKPASS
незалежно від того, чи ви використовуєте Git
через SSH або автентифікацію через https-протокол.
Ви також можете додати unset SSH_ASKPASS
в кінці вашого
файлу ~/.bashrc
, щоб зробити запит імен користувачів та
паролів стандартною поведінкою Git.
Тепер наші локальний та віддалений репозиторії перебувають у такому стані:
Опція ‘-u’
У документації ви можете іноді побачити використання
git push
з опцією -u
. Це є синонімом опції
--set-upstream-to
для команди git branch
і
використовується для
звязку поточної гілки з віддаленою гілкою таким чином, щоб команда
git
pullмогла надалі бути використана без будь-яких аргументів. Щоб зробити це, просто використайте
git
push -u origin main` один раз після налаштування віддаленого
репозиторію.
Ми також можемо завантажувати зміни з віддаленого репозиторію до локального:
ВИХІД
From https://github.com/alflin/recipes
* branch main -> FETCH_HEAD
Already up-to-date.
У цьому випадку ця команда не має ніякого ефекту, оскільки два репозиторії вже синхронізовані. Але якщо хтось ще вніс якісь зміни до репозиторію на GitHub, то ця команда завантажить їх у наш локальний репозиторій.
Користування вебінтерфейсом GitHub
Перейдіть до вашого репозиторію recipes
на GitHub. Під
кнопкою “Code”, знайдіть та натисніть на текст “XX commits” (де “XX” -
якесь число). Наведіть курсор та натисніть на три кнопки праворуч від
кожного коміту. Яку інформацію ви можете отримати/вивчити за допомогою
цих кнопок? Як би ви отримали ту саму інформацію в shell?
Ліва кнопка (з зображенням буфера обміну) копіює повний ідентифікатор
коміту до буфера обміну. В shell, git log
покаже вам для
кожного коміту його повний ідентифікатор.
Коли ви натиснете на середню кнопку, ви побачите всі зміни, які були
зроблені в цьому конкретному коміті. Зелені затінені лінії вказують на
додавання, а червоні - видалення. В shell ми можемо зробити те ж саме за
допомогою git diff
. А саме, git diff ID1..ID2
,
де ID1 та ID2 - ідентифікатори комітів (наприклад,
git diff a3bf1e5..041e637
) покаже відмінності між цими
двома комітами.
Найправіша кнопка дозволяє переглянути всі файли в репозиторії під
час цього коміту. Для того, щоб зробити це в shell, нам потрібно було б
змінити стан файлів у репозиторії на їх стан під час відповідного
коміту. Ми можемо зробити це за допомогою git checkout ID
,
де ID - ідентифікатор коміту, на який ми хочемо подивитися. Якщо ми це
зробимо, нам потрібно пам’ятати про те, що після цього репозиторій
потрібно повернути до попереднього стану!
Завантаження файлів до GitHub у браузері
Github також дозволяє нам уникнути використання командного рядка і завантажити файли безпосередньо до вашого репозиторію без необхідності залишати браузер. Для цього є два варіанти. Перший - ви можете натиснути кнопку “Upload files” на панелі інструментів у верхній частині переліку файлів. Другий - ви можете перетягнути файли з робочого столу до переліку файлів. Ви можете більше прочитати про це на цій сторінці у GitHub.
Показ дати у GitHub
Створіть віддалений репозиторій на GitHub. Завантажте вміст вашого локального репозиторію до віддаленого. Зробіть нові зміни у вашому локальному репозиторії та завантажте їх теж. Перейдіть до щойно створеного на GitHub репозиторію і перевірте дати модифікацїї файлів. Як GitHub їх відображає, і чому?
GitHub відображає дати у відносному форматі, який легко читається людиною (наприклад, “22 години тому” або “три тижні тому”). Однак, якщо ви наведете курсор на дату, ви можете побачити точний час, коли відбулася остання зміна файлу.
Завантаження змін чи коміт змін?
В цьому епізоді ми познайомилися з командою git push
. Як
git push
відрізняється від git commit
?
Коли ми завантажуємо зміни, ми взаємодіємо з віддаленим репозиторієм,
щоб додати до нього зміни, які ми зробили локально (часто для того, щоб
поділитися змінами, які ми зробили, з іншими). Команда
git commit
оновлює лише локальний репозиторій.
Файли ліцензії та README
У цьому епізоді ми дізналися про створення віддаленого репозиторію на
GitHub, але коли ми ініціалізували наш GitHub репозиторій, ми не додали
README.md
або файл ліцензії. Якби ми це зробили, що, на
вашу думку, сталося, якби ми намагалися зв`язати локальний та віддалений
репозиторії?
У цьому випадку ми побачимо конфлікт злиття через неспоріднені
історії. Коли GitHub створює файл README.md
, він виконує
коміт у віддаленому репозиторії. Коли ви намагаєтеся отримати зміни з
віддаленого репозиторію до вашого локального, Git виявить, що вони мають
історії, які не мають спільного походження, та відмовиться від
злиття.
ВИХІД
warning: no common commits
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/alflin/recipes
* branch main -> FETCH_HEAD
* [new branch] main -> origin/main
fatal: refusing to merge unrelated histories
Ви можете змусити git об’єднати два сховища, використав опцію
--allow-unrelated-histories
. Будьте обережні, коли ви
використовуєте цей параметр і уважно перевірте вміст локального і
віддаленого репозиторіїв перед об’єднанням.
ВИХІД
From https://github.com/alflin/recipes
* branch main -> FETCH_HEAD
Merge made by the 'recursive' strategy.
README.md | 1 +
1 file changed, 1 insertion(+)
create mode 100644 README.md
Ключові моменти
- Локальний репозиторій Git можна під’єднати до одного або декількох віддалених репозиторіїв.
- Для підключення до віддалених репозиторіїв використовується протокол SSH.
-
git push
копіює зміни з локального репозиторію до віддаленого репозиторію. -
git pull
копіює зміни з віддаленого репозиторію в локальний репозиторій.
Content from Співпраця
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 25 хвилин
Огляд
Питання
- Як я можу використовувати контроль версій для співпраці з іншими?
Цілі
- Клонування віддаленого репозиторію.
- Співпраця шляхом надсилання змін до спільного репозиторію.
- Загальний вигляд процесу співпраці.
Для наступного кроку слухачам потрібно розбитися на пари. Одна людина буде “Власником”, а інша - “Співавтором”. Мета полягає в тому, щоб Співавтор додав зміни в репозиторій Власника. У подальшому слухачі поміняються ролями так, щоб обидві людини спробували грати ролі як Власника, так і Співавтора.
Практика без партнера
Якщо ви працюєте над цим уроком самостійно, ви можете імітувати подібний сценарій, відкривши ще одне вікно терміналу. Це вікно буде представляти вашого партнера, який працює на іншому комп’ютері. Вам не буде потрібно надавати нікому доступ до GitHub, тому що обидва “партнери” - це ви.
Власник репозиторію повинен надати Співавтору доступ. У GitHub, натисніть кнопку “Settings” праворуч, оберіть “Collaborators”, натисніть “Add people”, та потім введіть ім`я користувача GitHub, повідомлене вашим партнером.

Щоб отримати доступ до репозиторію Власника, Співавтору потрібно відкрити https://github.com/notifications або перевірити наявність повідомлення електронною поштою. Потім треба прийняти відповідне запрошення, яке ви там знайдете.
Далі, Співавтор повинен завантажити копію репозиторію Власника на свій комп`ютер. Це називається “клонування репозиторію”.
Співавтор не хоче втратити свою власну версію
recipes.git
, і тому йому потрібно клонувати репозиторій
Власника в інше місце, аніж у свій власний репозиторій з такою ж
назвою.
Щоб клонувати репозиторій Власника у каталог Desktop
,
Співавтор вводить:
(обовʼязково замініть ‘alflin’ на ім`я користувача GitHub Власника).
Якщо ви вирішите клонувати без додавання шляху клонування
(~/Desktop/alflin-recipes
) вказаного в кінці команди, ви
будете клонувати всередину вашого власного каталогу
recipes
! Переконайтеся, що спочатку ви перейшли до каталогу
Desktop
.
Співавтор тепер може зробити зміни у своєму клоні репозиторію Власника так само, як ми робили раніше:
ВИХІД
# Hummus
## Ingredients
* chickpeas
* lemon
* olive oil
* salt
ВИХІД
1 file changed, 6 insertion(+)
create mode 100644 hummus.md
Далі, відправте зміни до репозиторію Власника на GitHub:
ВИХІД
Enumerating objects: 4, done.
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 306 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/alflin/recipes.git
9272da5..29aba7c main -> main
Зауважте, що нам не потрібно було вказувати віддалений репозиторій
під назвою origin
: Git визначає його за замовчуванням, коли
ми клонуємо репозиторій. (Ось чому origin
був розумним
вибором раніше, коли ми налаштовували віддалені репозиторії вручну.)
Подивіться знову на репозиторій Власника на GitHub, і ви маєте побачити новий коміт, зроблений Співавтором. Можливо, вам доведеться оновити ваш браузер, щоб побачити новий коміт.
Деякі інші відомості про віддалені репозиторії
У цьому і попередньому епізодах, наш локальний репозиторій мав єдиний
“віддалений” репозиторій, під назвою origin
. Віддалений -
це копія репозиторію, яка знаходиться в іншому місці, з якою ми можемо
обмінюватися комітами через git pull
та
git push
, і немає жодних причин працювати тільки з одним
віддаленим репозиторієм. Наприклад, у деяких великих проєктах у вас може
бути власна копія у вашому власному обліковому записі GitHub (ви,
ймовірно, назвете її origin
), а також так званий “upstream”
- головний репозиторій проєкту (ми назвемо його upstream
для прикладу). Час від часу ви будете за допомогою git pull
отримувати зміни з upstream
, щоб отримати останні
оновлення, які зробили інші.
Пам’ятайте, що ім’я, яке ви надаєте віддаленому репозиторію, існує
лише локально. Це псевдонім, який ви обираєте - будь то
origin
, чи upstream
, чи fred
, а
не щось притаманне віддаленому репозиторію.
Сімейство команд git remote
використовується для
налаштування та зміни віддалених репозиторіїв, пов’язаних з локальним
репозиторієм. Ось деякі з найбільш корисних:
-
git remote -v
друкує всі віддалені репозиторії, які налаштовані (ми вже використовували це в останньому епізоді) -
git remote add [name] [url]
використовується для додавання нового віддаленого репозиторію -
git remote remove [name]
видаляє віддалений репозиторій. Зауважте, що це взагалі не впливає на віддалений репозиторій - він просто видаляє посилання на нього з локального репозиторію. -
git remote set-url [name] [newurl]
змінює URL, який пов`язаний з віддаленим репозиторієм. Це корисно, якщо він перейшов, наприклад, на інший обліковий запис GitHub або з GitHub на іншу платформу хостингу. Або, якщо ми зробили помилку при його додаванні! -
git remote rename [oldname] [newname]
змінює локальний псевдонім, під яким відомий віддалений репозиторій - тобто його назву. Наприклад, це можна використовувати, щоб змінитиupstream
наfred
.
Тепер, щоб завантажити з GitHub зміни, які зробив Співавтор, Власник вводить:
ВИХІД
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/alflin/recipes
* branch main -> FETCH_HEAD
9272da5..29aba7c main -> origin/main
Updating 9272da5..29aba7c
Fast-forward
hummus.md | 5 +
1 file changed, 5 insertion(+)
create mode 100644 hummus.md
Тепер три репозиторії (локальний Власника, локальний Співавтора, і репозиторій Власника на GitHub) знову синхронізуються.
Загальний вигляд процесу співпраці
На практиці добре бути впевненим, що у вас є оновлена версія
репозиторію, над яким ви співпрацюєте, тому перед внесенням наших змін
слід зробити git pull
. Основним робочим процесом буде
наступне:
- оновити локальний репозиторій за допомогою
git pull origin main
, - робити свої зміни і додати їх до зони стейджингу за допомогою
git add
, - зберегти зміни за допомогою
git commit -m
, та - завантажити зміни на GitHub за допомогою
git push origin main
Краще зробити багато комітів з меншими змінами, ніж один коміт з масивними змінами: маленькі коміти легше читати та перевіряти.
Обмін ролями та повторення
Тепер поміняйтеся ролями та повторіть увесь процес.
Перегляд Змін
Власник надіслав коміти до репозиторію, не надаючи жодної інформації Співавтору. Як Співавтор може дізнатися, що змінилося, за допомогою командного рядка? А як дізнатися про це на GitHub?
В командному рядку, Співавтор може використати
git fetch origin main
, щоб завантажити віддалені зміни до
локального репозиторію, але без їх об’єднання із версією Співавтора.
Потім запустивши git diff main origin/main
, Співавтор може
побачити зміни у терміналі.
На GitHub, Співавтор може перейти у репозиторій і натиснути на “commits”, щоб переглянути найновіші коміти, що були надіслані до репозиторію.
Коментування змін в GitHub
Співавтор має деякі питання про зміни в одному з рядків, зроблені Власником, та має деякі пропозиції.
У GitHub можна залишити коментар у вікні перегляду змін, зроблених у коміті. Наведіть курсор миші на рядок, який ви бажаєте прокоментувати, і тоді зліва з’явиться синій значок коментаря, який відкриє, якщо його натиснути, вікно для введення коментаря.
Таким чином, Співавтор публікує свої коментарі та пропозиції за допомогою інтерфейсу GitHub.
Історія версій, Резервне Копіювання та Контроль Версій
Деякі програми резервного копіювання можуть зберігати історію версій ваших файлів. Вони також дозволяють відновити певні версії. Чим їх функціональність відрізняється від контролю версій? Які переваги має використання контролю версій, Git та GitHub?
Ключові моменти
-
git clone
копіює віддалений репозиторій у локальний репозиторій та автоматично налаштовує віддалений репозиторій якorigin
.
Content from Конфлікти
Останнє оновлення 2025-01-28 | Редагувати цю сторінку
Приблизний час: 15 хвилин
Огляд
Питання
- Що робити, коли мої зміни конфліктують зі змінами інших?
Цілі
- Що таке конфлікти і коли вони можуть виникати.
- Вирішення конфліктів, що виникають внаслідок злиття змін.
Як тільки люди починають працювати паралельно, вони, швидше за все, “наступають один одному на ноги”. Це навіть може статися з однією людиною: якщо ми працюємо над програмою на нашому ноутбуці і на сервері в лабораторії водночас, ми можемо внести різні зміни в кожну копію. Контроль версій допомагає нам вирішувати ці конфлікти, надаючи інструменти для узгодження змін, які накладаються одна на одну.
Щоб побачити, як ми можемо розвʼязувати конфлікти, спочатку ми
повинні їх створити. Наразі файл guacamole.md
виглядає
однаково у клонах обох партнерів нашого репозиторію
recipes
:
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
Тепер додамо один рядок до копії співавтора:
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
* put one avocado into a bowl.
а потім відправимо наші зміни на GitHub:
ВИХІД
[main 5ae9631] First step on the instructions
1 file changed, 1 insertion(+)
ВИХІД
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 331 bytes | 331.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/alflin/recipes.git
29aba7c..dabb4c8 main -> main
Тепер нехай власник зробить іншу зміну у своїй копії без отримання нових змін з GitHub:
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
* peel the avocados
Ми можемо зробити коміт наших змін локально:
ВИХІД
[main 07ebc69] Add first step
1 file changed, 1 insertion(+)
але Git не дозволить нам відправити зміни на GitHub:
ВИХІД
To https://github.com/alflin/recipes.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/alflin/recipes.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Git не дозволяє цю операцію, оскільки виявляє, що віддалений репозиторій має нові оновлення, які не були включені до локальної гілки. Що ми повинні зробити - це отримати зміни з GitHub, обʼєднати їх з копією репозиторію, у якій ми зараз працюємо, а тільки потім надіслати їх на GitHub. Давайте почнемо з отримання змін:
ВИХІД
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 3 (delta 2), reused 3 (delta 2), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/alflin/recipes
* branch main -> FETCH_HEAD
29aba7c..dabb4c8 main -> origin/main
Auto-merging guacamole.md
CONFLICT (content): Merge conflict in guacamole.md
Automatic merge failed; fix conflicts and then commit the result.
Можливо, вам доведеться надати Git додаткові інструкції
Якщо у виведених даних з’являється наступне, Git запитує вас про вказівки.
ВИХІД
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint: git config pull.rebase false # merge (the default strategy)
hint: git config pull.rebase true # rebase
hint: git config pull.ff only # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
У новіших версіях Git ви можете обрати різні стратегії поведінки у
випадку, коли git pull
призводить до злиття розбіжних
гілок. У нашому випадку нам потрібна стандартна стратегія. Щоб
використовувати її, виконайте наступну команду, яка встановить її як дію
за замовчуванням.
Потім спробуйте отримати зміни ще раз.
Команда git pull
оновлює локальний репозиторій, щоб
додати до нього ті зміни, які вже містяться у віддаленому репозиторії.
Після отримання змін із віддаленої гілки Git визначає, що зміни, внесені
до локальної копії, конфліктують зі змінами, зробленими у віддаленому
репозиторії. Тому, щоб запобігти перезапису нашої роботи, Git
відмовляється об’єднувати дві версії. У файлі, де є конфлікт, він
позначається наступним чином:
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
<<<<<<< HEAD
* peel the avocados
=======
* put one avocado into a bowl.
>>>>>>> dabb4c8c450e8475aee9b14b4383acc99f42af1d
Нашим змінам передує <<<<<<< HEAD
.
Потім Git вставив =======
як роздільник між суперечливими
змінами, та позначив кінець вмісту, завантаженого з GitHub, за допомогою
>>>>>>>
. (Рядок літер і цифр після
цього маркера ідентифікує щойно завантажений коміт.)
Тепер ми маємо відредагувати цей файл, щоб видалити ці маркери та узгодити зміни. Ми можемо зробити все, що бажаємо: зберегти зміни з локального чи віддаленого репозиторію, написати щось нове та замінити обидві версії, або позбутися змін повністю. Замінимо обидві версії так, щоб файл виглядав наступним чином:
BASH
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 645 bytes | 645.00 KiB/s, done.
Total 6 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 2 local objects.
To https://github.com/vlad/planets.git
dabb4c8..2abf2b1 main -> main
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
* peel the avocados and put them into a bowl.
Щоб закінчити злиття, додамо guacamole.md
до зони
стейджингу, а потім зробимо коміт:
BASH
remote: Enumerating objects: 10, done.
remote: Counting objects: 100% (10/10), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 4), reused 6 (delta 4), pack-reused 0
Unpacking objects: 100% (6/6), done.
From https://github.com/vlad/planets
* branch main -> FETCH_HEAD
dabb4c8..2abf2b1 main -> origin/main
Updating dabb4c8..2abf2b1
Fast-forward
mars.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
ВИХІД
On branch main
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Changes to be committed:
modified: guacamole.md
ВИХІД
[main 2abf2b1] Merge changes from GitHub
Тепер ми можемо відправити наші зміни на GitHub:
ВИХІД
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 8 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 645 bytes | 645.00 KiB/s, done.
Total 6 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 2 local objects.
To https://github.com/alflin/recipes.git
dabb4c8..2abf2b1 main -> main
Git відстежує, що з чим було об’єднано, тому нам не потрібно знову
виправляти конфлікти вручну коли співавтор, який зробив першу зміну,
знову виконує git pull
:
ВИХІД
remote: Enumerating objects: 10, done.
remote: Counting objects: 100% (10/10), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 6 (delta 4), reused 6 (delta 4), pack-reused 0
Unpacking objects: 100% (6/6), done.
From https://github.com/alflin/recipes
* branch main -> FETCH_HEAD
dabb4c8..2abf2b1 main -> origin/main
Updating dabb4c8..2abf2b1
Fast-forward
guacamole.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Ми отримуємо файл з об’єднаними змінами:
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
* peel the avocados and put them into a bowl.
Нам не потрібно знову робити злиття змін, оскільки Git знає, об’єднання вже завершено.
Здатність Git вирішувати конфлікти є дуже корисною, але вона вимагає часу та зусиль, і може призвести до помилок, якщо конфлікти не вирішуються належним чином. Якщо ви часто стикаєтеся з конфліктами в вашому проекті, розгляньте ці технічні підходи щоб мінімізувати їх:
- Частіше “витягуйте” (за допомогою
git pull
) зміни, особливо перед початком нової роботи - Використовуйте тематичні гілки (feature branches) для розділення
роботи, з їх подальшим об’єднанням до гілки
main
після завершення роботи - Створюйте менші, більш цілеспрямовані (атомарні) коміти
- Надсилайте (за допомогою
git push
) свою роботу після її завершення до спільного репозиторію та заохочуйте свою команду робити те саме. Це зменшує обсяг незавершеної роботи та, відповідно, ймовірність конфліктів - Там, де логічно доречно, розбивайте великі файли на менші, щоб зменшити ймовірність того, що кілька авторів редагуватимуть один і той самий файл одночасно
Конфлікти також можна мінімізувати за допомогою дотримання деяких стратегій управління проєктами:
- Чітко визначте обов’язки кожного співавтора, хто відповідає за які аспекти проєкту
- Обговоріть зі своїми співавторами порядок виконання задач, щоб уникнути одночасної роботи над тими самими рядками
- Якщо конфлікти є стилістичними (наприклад, табуляції або пробіли),
домовтеся про стиль коду, яким ви будете керуватися, та використовуйте
за необхідністю інструменти форматування (наприклад,
htmltidy
,perltidy
,rubocop
, та ін.) для забезпечення єдиного стилю
Вправа: створення та вирішення конфліктів
Клонуйте репозиторій, створений вашим інструктором. Додайте до нього новий файл та змініть наявний файл (ваш інструктор скаже, який саме). Потім, на запит вашого інструктора, отримайте нові зміни з цього репозиторію, щоб створити конфлікт, а потім вирішіть його.
Конфлікти у бінарних файлах
Як Git вирішує конфлікти в зображеннях або інших бінарних файлах, що зберігаються в системі контролю версій?
Спробуймо це дослідити. Припустимо, Альфредо сфотографував свій гуакамоле та зберіг фото у файлі `guacamole.jpg’.
Якщо у вас немає файлу із зображенням гуакамоле, ви можете створити фіктивний бінарний файл наступним чином:
ВИХІД
-rw-r--r-- 1 alflin 57095 1.0K Mar 8 20:24 guacamole.jpg
ls
показує, що було створено файл розміром 1 кілобайт.
Він містить випадкові байти, які були зчитані зі спеціального файлу
/dev/urandom
.
Тепер припустимо, що Альфредо додає guacamole.jpg
до
свого репозиторію:
ВИХІД
[main 8e4115c] Add picture of guacamole
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 guacamole.jpg
Припустимо, що Джиммі тим часом додав схожу фотографію. На його фотографії зображено гуакамоле з начос, але воно також називається guacamole.jpg. Коли Альфредо намагається відправити зміни до віддаленого репозиторію, він отримує вже знайоме повідомлення:
ВИХІД
To https://github.com/alflin/recipes.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/alflin/recipes.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Як ми вже дізналися раніше, ми спочатку маємо отримати зміни та вирішити усі конфлікти:
Коли конфлікт виникає у зображенні або іншому бінарному файлі, git друкує таке повідомлення:
ВИХІД
$ git pull origin main
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From https://github.com/alflin/recipes.git
* branch main -> FETCH_HEAD
6a67967..439dc8c main -> origin/main
warning: Cannot merge binary files: guacamole.jpg (HEAD vs. 439dc8c08869c342438f6dc4a2b615b05b93c76e)
Auto-merging guacamole.jpg
CONFLICT (add/add): Merge conflict in guacamole.jpg
Automatic merge failed; fix conflicts and then commit the result.
Повідомлення про конфлікт здебільшого ідентичне повідомленням для
guacamole.md
, але містить один додатковий рядок:
ВИХІД
warning: Cannot merge binary files: guacamole.jpg (HEAD vs. 439dc8c08869c342438f6dc4a2b615b05b93c76e)
Git не може автоматично вставляти маркери конфлікту у зображення, як
він це робить для текстових файлів. Тому замість того, щоб редагувати
файл зображення, нам потрібно викликати з історії змін ту його версію,
яку ми хочемо зберегти. Після цього ми можемо виконати відповідні
команди git add
та git commit
, щоб зберегти цю
версію.
В додатковому рядку вище, Git зручно надав нам ідентифікатори коміту
для обох версій guacamole.jpg
. Наша версія -
HEAD
, а Джиммі зберіг версію 439dc8c0...
. Якщо
ми хочемо використовувати нашу версію, ми можемо застосувати
git checkout
:
BASH
$ git checkout HEAD guacamole.jpg
$ git add guacamole.jpg
$ git commit -m "Use image of just guacamole instead of with nachos"
ВИХІД
[main 21032c3] Use image of just guacamole instead of with nachos
Якщо замість цього ми хочемо використовувати версію Джиммі, ми можемо
застосувати git checkout
з його ідентифікатором коміту,
тобто 439dc8c0
:
BASH
$ git checkout 439dc8c0 guacamole.jpg
$ git add guacamole.jpg
$ git commit -m "Use image of guacamole with nachos instead of just guacamole"
ВИХІД
[main da21b34] Use image of guacamole with nachos instead of just guacamole
Ми також можемо зберегти обидва зображення. Але ж проблема
полягає в тому, що ми не зможемо зберегти їх з однаковими назвами. Проте
ми можемо викликати з історії кожну версію послідовно та
перейменувати її, а потім додати перейменовані версії до
репозиторію за допомогою git add
. Спочатку “дістаньте” з
історії змін кожне зображення та перейменуйте його:
BASH
$ git checkout HEAD guacamole.jpg
$ git mv guacamole.jpg guacamole-only.jpg
$ git checkout 439dc8c0 guacamole.jpg
$ mv guacamole.jpg guacamole-nachos.jpg
Потім видаліть стару версію файлу guacamole.jpg
та
додайте два нових файли:
BASH
$ git rm guacamole.jpg
$ git add guacamole-only.jpg
$ git add guacamole-nachos.jpg
$ git commit -m "Use two images: just guacamole and with nachos"
ВИХІД
[main 94ae08c] Use two images: just guacamole and with nachos
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 guacamole-nachos.jpg
rename guacamole.jpg => guacamole-only.jpg (100%)
Тепер обидва зображення гуакамоле містяться у репозиторії, а файл
guacamole.jpg
більше не існує.
Звичайна робоча сесія
Ви сідаєте за комп’ютер, щоб працювати над спільним проєктом, який відстежується у віддаленому репозиторії Git. Під час робочого сеансу ви виконуєте наступні дії, хоча не обов’язково в такому порядку:
-
Зробити зміни, додавши число ‘100’ до текстового файлу
numbers.txt
- Оновити віддалений репозиторій, щоб він відповідав локальному репозиторію
- Відсвяткувати свій успіх
- Оновити локальний репозиторій, щоб він відповідав віддаленому репозиторію
- Додати зміни до зони стейджингу
- Зробити коміт у локальному репозиторії
В якому порядку слід виконувати ці дії, щоб мінімізувати ймовірність конфліктів? Розташуйте їх у порядку виконання в стовпці “дія” в таблиці нижче. Коли ви розташуєте їх у відповідному порядку, спробуйте написати відповідні команди в стовпці “команда”. Кілька кроків вже заповнені, щоб допомогти вам розпочати.
крок | дія . . . . . . . . . . | команда . . . . . . . . . . |
---|---|---|
1 | ||
2 | echo 100 >> numbers.txt |
|
3 | ||
4 | ||
5 | ||
6 | Відсвяткувати! |
крок | дія . . . . . . | команда . . . . . . . . . . . . . . . . . . . |
---|---|---|
1 | Оновити локальний репозиторій | git pull origin main |
2 | Зробити зміни | echo 100 >> numbers.txt |
3 | Додати зміни до зони стейджингу | git add numbers.txt |
4 | Зробити коміт | git commit -m "Add 100 to numbers.txt" |
5 | Оновити віддалений репозиторій | git push origin main |
6 | Відсвяткувати! |
Ключові моменти
- Конфлікти виникають, коли двоє або більше людей змінюють ті самі рядки в одному файлі.
- Система контролю версій не дозволяє користувачам перезаписувати зміни один одного наосліп, але виділяє конфлікти, щоб їх можна було вирішити.
Content from Відкрита наука
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 10 хвилин
Огляд
Питання
- Як контроль версій допоможе мені зробити мою роботу більш відкритою?
Цілі
- Пояснити, як систему контролю версій можна використовувати як електронний лабораторний журнал для обчислювальної роботи.
Протилежність “відкритої” не є “закрита”. Протилежність “відкритої” є “зламана”.
-– John Wilbanks
Мати вільний обмін інформацією було б ідеальним для науки, але реальність часто набагато складніша. Звичайна практика сьогодні виглядає приблизно так:
- Вчений збирає деякі дані і зберігає їх у машині, резервна копія якої іноді робиться його відділом.
- Потім він пише або змінює кілька невеликих програм (які також знаходяться на його машині), щоб аналізувати ці дані.
- Отримавши певні результати, він описує їх і подає свою статтю для публікації. Вчений може надати свої дані - все більша кількість журналів вимагає цього - але він, ймовірно, не надасть свій код.
- Проходить час.
- Журнал надсилає йому відгуки рецензентів, написані анонімно кількома іншими фахівцями в його галузі. Він переглядає свою статтю, щоб задовольнити їх (протягом цього часу він також може змінити скрипти, які він написав раніше), та повторно подає статтю.
- Проходить ще більше часу.
- Зрештою стаття опублікована. Вона може містити посилання на онлайн-копію його даних, але сама стаття буде платною: тільки люди, які мають особистий або інституційний доступ зможуть її прочитати.
Хоча для все більшої кількості вчених процес виглядає так:
- Дані, які збирає вчений, зберігаються у сховищі відкритого доступу на кшталт figshare або Zenodo (можливо, як тільки ці дані були зібрані), та отримують свій Цифровий ідентифікатор об’єкта (DOI). Або дані вже були опубліковані і зберігаються в Dryad.
- Вчений створює новий репозиторій на GitHub для зберігання своєї роботи.
- Під час аналізу він надсилає зміни до своїх скриптів (і, можливо, деякі вихідні файли) до цього репозиторію. Він також використовує його для своєї статті; цей репозиторій тепер стає платформою для співпраці з його колегами.
- Коли вчений задоволений станом своєї статті, він публікує версію на arXiv або на іншому сервері препринтів, щоб отримати відгуки від колег.
- На основі цих відгуків, він може опублікувати ще кілька редакцій перед тим, як нарешті подати свою статтю до журналу.
- Опублікована стаття містить посилання на препринт, а також на місця зберігання коду та даних, що значно полегшує іншим вченим використання його роботи як відправної точки для власних досліджень.
Ця відкрита модель прискорює дослідження: чим більш відкрита робота, тим частіше її цитують і повторно використовують. Однак людям, які хочуть працювати таким чином, потрібно прийняти певні рішення щодо того, що саме означає “відкрито”, і як це зробити. Ви можете знайти більше інформації про різні аспекти відкритої науки в цій книзі.
Це одна з (багатьох) причин чому ми викладаємо контроль версій. Коли він використовується старанно, то він відповідає на питання “як?”, діючи як спільний електронний лабораторний блокнот для обчислювальної роботи:
- Концептуальні етапи вашої роботи фіксуються, зокрема, хто зробив що і коли. Кожен крок позначається унікальним ідентифікатором (а саме, ідентифікатором коміту).
- Ви можете прив’язати документацію з обґрунтуваннями, ідеями та іншою інтелектуальною роботою безпосередньо до змін, які випливають з них.
- Ви можете перевірити, що ви використовували у своїх попередніх дослідженнях для того, щоб отримати результати обчислень однозначним та відновлюваним способом.
- За допомогою системи контролю версій, такої як Git, всю історію репозиторію легко зберегти на необмежений термін.
Робіть код можливим для цитування
Все, що зберігається у репозиторії системи контролю версій (дані, код, статті тощо) можна перетворити на об’єкт для цитування. Ви дізнаєтеся, як це зробити в пізнішому епізоді “Цитування”.
Наскільки відтворюваною є моя робота?
Попросіть когось із ваших колег відтворити результат, який ви нещодавно отримали, використовуючи лише те, що вони можуть знайти в ваших статтях або в Інтернеті. Спробуйте зробити те ж саме для одного з їхніх результатів, а потім спробуйте зробити це для результату з іншої лабораторії, з якою ви співпрацюєте.
Як знайти відповідне сховище для даних?
Протягом декількох хвилин перегляньте сховища даних, згадані вище:: Figshare, Zenodo, Dryad. Залежно від вашої галузі досліджень, ви можете знайти сховища, визнані спільнотою, які добре відомі у вашій області. Вам також можуть бути корисні ці сховища даних, які рекомендовані Nature. Обговоріть зі своїм сусідом, яке сховище даних може підійти для вашого поточного проєкту, і поясніть, чому.
Як відстежувати великі файли з даними або зображеннями за допомогою Git?
Великі файли даних або зображень, такі як файли .md5
або
.psd
можуть бути відстежені в репозиторії github,
використовуючи розширення Git Large
File Storage. Це розширення (до речі, з відкритим кодом) автоматично
завантажує вміст великого файлу на віддалений сервер і замінює цей файл
текстовим вказівником у репозиторії GitHub.
Спробуйте завантажити та встановити розширення Git Large File Storage, а потім додати великий файл до репозиторію GitHub. Попросіть колегу клонувати ваш репозиторій та перевірте, що вони бачать, коли відкривають цей великий файл.
Ключові моменти
- Відкрита наукова робота є більш корисною та частіше цитованою, ніж закрита.
Content from Ліцензування
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 5 хвилин
Огляд
Питання
- Яку інформацію про ліцензію має містити моя робота?
Цілі
- Пояснити, чому важливо додавати інформацію про ліцензування до репозиторію.
- Як обрати відповідну ліцензію?
- Пояснити відмінності в ліцензуванні та соціальних очікуваннях.
Коли репозиторій з вихідним кодом, рукописом або іншими творчими
роботами стає публічним, він повинен містити у головному каталозі
репозиторію файл під назвою LICENSE
або
LICENSE.txt
, у якому чітко вказано, під якою ліцензією
надається контент. Це пояснюється тим, що творчі роботи автоматично
мають право на захист інтелектуальної власності (і, отже, авторських
прав). Повторне використання творчих робіт без ліцензії є небезпечним,
оскільки правовласники можуть подати на вас до суду за порушення
авторських прав.
Ліцензія вирішує цю проблему, надаючи іншим особам (ліцензіатам) права, яких вони в іншому випадку не мали б. Те, які права надаються, і за яких умов, може відрізнятися, але часто не дуже, у різних ліцензіях. На практиці, деякі ліцензії на сьогодні є найпопулярнішими, і choosealicense.com може допомогти вам знайти поширену ліцензію, яка відповідає вашим потребам. Важливими міркуваннями є:
- Чи хочете ви вказати патентні права.
- Чи потрібно вам, щоб люди, які будуть поширювати похідні роботи, також розповсюджували свій вихідний код.
- Чи є вміст, який ви ліцензуєте, вихідним кодом.
- Чи хочете ви взагалі ліцензувати код.
Вибір ліцензії, яка є загальновживаною, полегшує життя для учасників і користувачів, тому що вони, швидше за все, вже знайомі з ліцензією, і їм не доведеться продиратися через купу жаргону, щоб вирішити, чи згодні вони з нею. Ініціатива відкритого коду та Фонд вільного програмного забезпечення підтримують списки ліцензій, які є гарним вибором.
Ця стаття пропонує відмінний огляд ліцензування та його варіантів з точки зору вчених, які також пишуть код.
Зрештою, важливо те, що є чітке твердження про те, яка ліцензія використовується. Також, ліцензію краще вибирати з самого початку, навіть для репозиторію, який не є загальнодоступним. Відкладання цієї справи лише ускладнить ваше становище у майбутньому, тому що кожного разу, коли нові співавтори зроблять свій внесок, вони також володітимуть авторським правом. Таким чином, будь-який вибір ліцензії пізніше також буде потрібно узгоджувати з ними.
Чи можу я використовувати відкриту ліцензію?
Дізнайтеся, чи дозволено вам застосовувати відкриту ліцензію до вашого програмного забезпечення. Чи можете ви зробити це в односторонньому порядку, або вам потрібен дозвіл від когось у вашому закладі? Якщо так, то від кого?
З якими ліцензіями ми вже погодились?
Багато програм, якими ми користуємося щодня (у тому числі і на цьому
семінарі) доступні як програмне забезпечення з відкритим вихідним кодом.
Виберіть на GitHub проєкт зі списку нижче, або інший проєкт на ваш
вибір. Знайдіть його ліцензію (зазвичай у файлі під назвою
LICENSE
або COPYING
) і подивіться як вона
обмежує використання програмного забезпечення. Чи це одна з ліцензій
обговорювана у цьому епізоді? Якщо ні, то чим вона відрізняється?
Ключові моменти
- Файли з імʼям
LICENSE
,LICENSE.md
, абоLICENSE.txt
часто використовуються у репозиторіях, щоб вказати, як їх вміст може застосовуватися іншими. - Розробники, які інтегрують програмне забезпечення з ліцензією General Public License (GPL) у своє власне, також повинні зробити своє програмне забезпечення відкритим під ліцензією GPL. Більшість інших відкритих ліцензій цього не вимагають.
- Сімейство ліцензій Creative Commons дозволяє авторам гнучко комбінувати вимоги та обмеження щодо зазначення авторства, створення похідних творів, подальшого поширення та комерціалізації.
- Люди, які не є юристами, не повинні намагатися писати ліцензії з нуля.
Content from Цитування
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 2 хвилин
Огляд
Питання
- Як полегшити цитування моєї роботи?
Цілі
- Зробити вашу роботу легкою для цитування
Ви можете додати файл під назвою CITATION
або
CITATION.txt
, який описує, як цитувати ваш проєкт;
наприклад, для Software Carpentry цей
файл зазначає:
To reference Software Carpentry in publications, please cite:
Greg Wilson: "Software Carpentry: Lessons Learned". F1000Research,
2016, 3:62 (doi: 10.12688/f1000research.3-62.v2).
@online{wilson-software-carpentry-2016,
author = {Greg Wilson},
title = {Software Carpentry: Lessons Learned},
version = {2},
date = {2016-01-28},
url = {http://f1000research.com/articles/3-62/v2},
doi = {10.12688/f1000research.3-62.v2}
}
Більш детальні поради та інші способи зробити ваш код цитованим можна знайти у блозі Software Sustainability Institute, а також у:
Smith AM, Katz DS, Niemeyer KE, FORCE11 Software Citation Working Group. (2016) Software citation
principles. [PeerJ Computer Science 2:e86](https://peerj.com/articles/cs-86/)
https://doi.org/10.7717/peerj-cs.8
Існує також тип запису @software{...
для BibTeX на випадок,
якщо для проєкту, який ви хочете процитувати, немає «джерела-парасольки»
для цитування, такого як стаття або книга.
Ключові моменти
- Додайте файл
CITATION
до репозиторію, щоб пояснити у ньому, як ви хочете бачити посилання на свою роботу.
Content from Хостинг
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 10 хвилин
Огляд
Питання
- Де я можу розміщувати репозиторії контролю версій?
Цілі
- Пояснити різні варіанти хостингу наукової роботи.
Після вибору ліцензії, наступне важливе питання для дослідницьких груп, які бажають зробити свою роботу відкритою, полягає у тому, де розміщувати свій код та дані. Один із варіантів полягає в тому, щоб лабораторія, кафедра чи університет надали сервер, керували обліковими записами та резервними копіями тощо. Основна перевага цього полягає в тому, що при цьому зʼясується кому що належить. Це особливо важливо, коли будь-який матеріал є чутливим (тобто стосується експериментів за участю людей або може бути використаний у патентній заявці). Основними недоліками цього є вартість надання послуги та її довговічність: вчений, який витратив десять років на збір даних, бажав би бути впевненим, що дані все ще будуть існувати через десять років. Але це значно перевищує термін більшості грантів, які фінансують академічну інфраструктуру.
Інший варіант - придбати домен і заплатити інтернет-провайдеру (ISP) за його підтримку. Це дає індивіду або групі більше контролю, і обходить проблеми, які можуть виникнути при переході з однієї установи в іншу. Але це вимагає більше часу і зусиль для налаштування, ніж попередній варіант або наступний варіант.
Третім варіантом є використання публічного хостингу, як GitHub, GitLab, або BitBucket. Кожна з цих платформ надає вебінтерфейс, який дозволяє людям створювати, переглядати та редагувати свої репозиторії. Ці платформи також надають засоби комунікації та управління проєктами, такі як: відстеження проблем, вікі-сторінки, автоматичні сповіщення електронною поштою, та перегляд коду. Вони отримують перевагу від того, що легше добре підтримувати одну велику платформу, ніж запустити багато менших сервісів з тим самим рівнем якості. Також, на великих платформах легше співпрацювати. Їх використання може допомогти звʼязати ваш проєкт зі спільнотами, які вже використовують ту ж саму платформу.
Наприклад, Software Carpentry знаходиться на GitHub, де ви можете знайти джерело для цієї сторінки. Будь-хто з обліковим записом GitHub може запропонувати зміни до цього тексту.
Репозиторіям GitHub також можуть бути присвоєні DOI, шляхом
підключення їх релізів до Zenodo. Наприклад, 10.5281/zenodo.57467
- це DOI, який був “викарбуваний” для цього введення до Git.
Використання великих, добре налагоджених сервісів також може допомогти вам швидко скористатися перевагами потужних інструментів. Один з таких інструментів, безперервна інтеграція (БI), може автоматично запускати програмні збірки та тести щоразу, коли виконується код або надходять запити на отримання змін. Пряма інтеграція БI з онлайн-хостингом означає, що ця інформація присутня в будь-якому запиті на отримання змін, і допомагає підтримувати цілісність коду та стандарти якості. Хоча БI може бути доступна у варіантах із самостійним хостингом, використання онлайн-сервісу вимагає набагато менше зусиль з налаштування та обслуговування. Крім того, такі інструменти часто надаються безкоштовно для проєктів з відкритим вихідним кодом, а також доступні для приватних репозиторіїв за окрему плату.
Інституційні бар’єри
Відкритий доступ - ідеальна ситуація для науки, але багато установ накладають обмеження на розповсюдження інформації, наприклад, для захисту потенційно патентованої інтелектуальної власності. Якщо ви стикаєтеся з такими обмеженнями, може бути доречно запитати про джерела їх мотивації. Можна запросити зробити виняток для конкретного проєкту чи галузі, або наполягати ширше на необхідності інституційної реформи для підтримки більшої відкритості у науці.
Чи може моя робота бути у відкритому доступі?
Дізнайтеся, чи дозволено вам відкрито розміщувати свою роботу в публічному репозиторії. Чи можете ви зробити це в односторонньому порядку, або вам потрібен дозвіл від когось у вашому закладі? Якщо так, то від кого?
Ключові моменти
- Проєкти можуть бути розміщені на серверах університетів, в особистих доменах або на публічному сервісі хостингу.
- Правила щодо інтелектуальної власності та зберігання конфіденційної інформації застосовуються незалежно від місця розміщення коду та даних.
Content from Додатково: Використання Git з RStudio
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 10 хвилин
Огляд
Питання
- Як я можу використовувати Git з RStudio?
Цілі
- Зрозуміти, як використовувати Git з RStudio.
Контроль версій може бути дуже корисним під час розробки скриптів для аналізу даних. Для цього популярне середовище розробки для мови програмування R, яке називається RStudio, має вбудовану інтеграцію з Git. Хоча для деяких розширених функцій Git все ще потрібен командний рядок, RStudio має зручний інтерфейс для найбільш поширених операцій Git.
RStudio дозволяє створити проєкт, пов’язаний з вказаним каталогом, для відстеження відповідних файлів. Використання Git для контролю версій у проєкті Rstudio надасть нам можливість відстежувати розвиток проєкту з часом, повертатися до попередніх версій, та співпрацювати з іншими. Для того, щоб почати використовувати Git в RStudio, ми створимо новий проєкт:

Цей крок відкриває діалогове вікно із запитанням про те, як саме ми
хочемо створити проєкт. Тут ми маємо кілька варіантів. Припустимо, що ми
хочемо використовувати RStudio з репозиторієм recipes
, який
ми вже створили раніше. Оскільки цей репозиторій міститься в каталозі на
нашому комп’ютері, ми обираємо опцію “Existing Directory”:

Перевірте, чи бачите ви опцію “Version Control”
Хоча ми не збираємося використовувати її тут, в цьому меню повинна бути опція “version control”. Це те, що ви б обрали, якщо захочете створити проєкт на своєму комп’ютері шляхом клонування репозиторію з GitHub. Якщо ця опція відсутня, це, ймовірно, означає, що RStudio не знає, де знаходиться ваш виконуваний файл Git, і ви не зможете просуватися далі в цьому уроці, поки ви не скажете RStudio, де він.
Знайдіть виконуваний файл Git
Спочатку переконаймося, що Git встановлено на вашому комп’ютері. Відкрийте термінал у Mac або Linux, або відкрийте командний рядок у Windows, і введіть:
-
which git
(macOS, Linux) -
where git
(Windows)
Якщо на вашому комп’ютері немає ніякої версії Git, будь ласка,
дотримуйтесь інструкцій зі
встановлення Git з цього ж самого уроку, щоб встановити Git зараз.
Далі відкрийте термінал або командний рядок і знов введіть
which git
(macOS, Linux), або where git
(Windows). Скопіюйте шлях до виконуваного файлу git.
Наприклад, на деякому комп’ютері Windows, на якому встановлено GitHub
Desktop, шлях може бути таким:
C:/Users/UserName/AppData/Local/GitHubDesktop/app-1.1.1/resources/app/git/cmd/git.exe
ПРИМІТКА: Шлях на вашому комп’ютері буде дещо іншим.
Повідомте RStudio, де знайти Git
У RStudio перейдіть до меню Tools
>
Global Options
> Git/SVN
, а потім перейдіть
до виконуваного файлу Git, який ви знайшли в командному рядку або
терміналі. Тепер перезапустіть RStudio. Примітка: Навіть якщо у вас
встановлений Git, якщо ви використовуєте macOS, то вам може знадобитися
прийняти ліцензію Xcode.
Далі RStudio запитає, який наявний каталог ми хочемо використовувати. Натисніть “Browse…” і перейдіть до відповідного каталогу, потім натисніть”Create Project”:

Чудово! Ми створили новий проєкт у RStudio в межах наявного
репозиторію recipes
. Зверніть увагу на вертикальне меню
“Git” у панелі меню. RStudio визнав, що поточний каталог є репозиторієм
Git, і пропонує нам ряд інструментів для використання Git:

Щоб редагувати наявні файли в репозиторії, ми можемо натискати на них у панелі “Files” у правому нижньому куті. Тепер додамо деяку інформацію про хумус:

Після того, як ми зберегли наші відредаговані файли, ми можемо використати RStudio для збереження змін, натиснувши на “Commit…” в меню Git:

Це відкриє діалогове вікно, де ми можемо вказати, які файли зберігати
у коміті (обираючи відповідні поля у стовпці “Staged”), та ввести
повідомлення коміту (у верхній правій панелі). Піктограми у стовпці
“Status” вказують поточний стан кожного файлу. Натискання на файлі
показує інформацію про зміни у нижній панелі (використовуючи результат
команди git diff
). Як тільки все виглядає так, як ми
хочемо, ми натискаємо “Commit”:

Зміни можна відправити до віддаленого репозиторію, обравши “Push Branch” з меню Git. Існують також опції меню для отримання змін з віддаленого репозиторію та для перегляду історії комітів:

Що робити, якщо команди Push/Pull виділені сірим кольором?
Якщо команди Push/Pull не активні, це зазвичай означає, що RStudio не
знає місце знаходження вашого віддаленого репозиторію (наприклад, на
GitHub). Щоб виправити це, відкрийте термінал у репозиторії і введіть
команду git push -u origin main
. Потім перезавантажте
RStudio.
Якщо натиснути на “History”, ми побачимо графічну версію того, що нам
сказав би git log
:

RStudio створює ряд файлів, які використовуються для відстеження
проєкту. Зазвичай ми не хочемо відстежувати їх у Git; в цьому випадку ми
додаємо їх до нашого файлу .gitignore
:

Порада: як виключити файли з контролю версій
Як правило, ви не хочете відстежувати версії похідних файлів, які
можуть бути видалені та потім відтворені (наприклад, результатів
аналізу), або даних, які використовуються лише для читання. У такому
разі ви повинні змінити файл .gitignore
, щоб повідомити
Git, що треба ігнорувати ці файли та директорії.
Завдання
- Створіть у вашому проєкті новий каталог під назвою
graphs
. - Змініть
.gitignore
, щобgraphs
не відстежувався контролем версій.
Це можна зробити в Rstudio наступним чином:
R
dir.create("./graphs")
Потім відкрийте файл .gitignore
з правої панелі Rstudio
та додайте graphs/
до списку файлів, які слід
ігнорувати.
У меню Git у RStudio є ще багато інших функцій, але цих має бути достатньо, щоб почати!
Ключові моменти
- Використання інтеграції Git із RStudio дозволяє відстежувати еволюцію проєкту.