Content from Автоматизований контроль версій

---

Останнє оновлення 2025-01-24 | Редагувати цю сторінку

Приблизний час: 5 хвилин

Огляд

Питання

• Що таке контроль версій і навіщо його використовувати?

Цілі

• Зрозуміти переваги автоматизованої системи контролю версій.
• Зрозуміти основи функціонування автоматизованих систем контролю версій.

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

“notFinal.doc” Хорхе Чам, https://www.phdcomics.com

Ми всі були в цій ситуації раніше: здається непотрібним мати кілька майже ідентичних версій одного документа. Деякі текстові процесори дозволяють нам впоратися з цим трохи краще, наприклад, 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:

BASH

$ git config --global core.autocrlf input

Для Windows:

BASH

$ git config --global core.autocrlf true

Альфредо також повинен налаштувати для використання з 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, щоб це відповідало налаштуванням у хмарному сервісі, який він зрештою використовуватиме.

BASH

$ git config --global init.defaultBranch main

Назва гілки Git за замовчуванням

Зміни у змісті репозиторію пов’язані з “гілкою”. Для початківців у цьому уроці буде достатньо знати, що гілки існують, і що в цьому уроці використовується тільки одна гілка.
За замовчуванням, коли ви створюєте новий репозиторій за допомогою git init, Git створить гілку під назвою master (як пояснюється в наступному епізоді). Цей термін нагадує про расистську практику людського рабства, і тому спільнота розробників програмного забезпечення перейшла до більш інклюзивної мови.

В 2020, більшість сервісів хостингу репозиторіїв Git перейшли до використання main як стандартної гілки. Наприклад, будь-який новий репозиторій, створений у GitHub і GitLab, за замовчуванням буде використовувати гілку main. Проте Git ще не зробив таких самих змін. Як наслідок, локальні репозиторії повинні бути налаштовані вручну, щоб мати ту саму назву головної гілки, що й більшість хмарних сервісів.

При використанні попередніх версій Git (до 2.28), зміни можуть бути внесені на рівні окремого репозиторію. Команда для цього знаходиться в наступному епізоді. Зауважте, що якщо це значення не встановлено у вашій локальній конфігурації Git, то init.defaultBranch за замовчуванням має значення master.

П’ять команд, які ми щойно запустили вище, потрібно виконати лише один раз: параметр --global повідомляє Git про налаштування для кожного проєкту у вашому обліковому записі користувача на цьому комп’ютері.

Погляньмо на ці налаштування і протестуємо core.editor прямо зараз:

BASH

$ git config --global --edit

Закриймо відкритий файл без внесення додаткових змін. Пам’ятайте, оскільки помилки у файлі конфігурації спричинять проблеми, безпечніше переглядати конфігурацію за допомогою

BASH

$ git config --list

Якщо необхідно, змініть свою конфігурацію за допомогою тих самих команд, щоб вибрати інший редактор або оновити адресу електронної пошти. Це можна робити скільки завгодно разів.

Проксі-сервер

У деяких мережах потрібно використовувати проксі-сервер. Якщо це так, вам також може знадобитися повідомити про це Git:

BASH

$ git config --global http.proxy proxy-url
$ git config --global https.proxy proxy-url

Щоб вимкнути проксі, використовуйте

BASH

$ git config --global --unset http.proxy
$ git config --global --unset https.proxy

Довідка про Git та посібник користувача

Завжди пам’ятайте, що якщо ви забули підкоманди чи параметри команди git, ви можете отримати відповідний список параметрів, ввівши git <command> -h або подивитись документацію до Git, ввівши git <command> --help, наприклад:

BASH

$ git config -h
$ git config --help

Під час перегляду посібника пам’ятайте, що : — це підказка, яка вказує на очікування команди, і ви можете натиснути Q, щоб вийти з посібника.

Загалом, ви можете отримати список доступних команд git і подальші ресурси за допомогою цієї команди:

BASH

$ git help

Ключові моменти

• Використовуйте git config з опцією --global, щоб налаштувати ім’я користувача, адресу електронної пошти, редактор та інші параметри. Це треба робити один раз для кожної машини.

Content from Створення репозиторію

---

Останнє оновлення 2025-01-28 | Редагувати цю сторінку

Приблизний час: 10 хвилин

Огляд

Питання

• Де Git зберігає інформацію?

Цілі

• Створити локальний репозиторій Git.
• Пояснити призначення каталогу .git.

Після налаштування Git ми можемо почати його використання.

Ми продовжимо нашу вигадану історію, у якій Альфредо досліджує, чи можливо відправити планетарний посадковий модуль на Марс.

Перш за все, створімо у каталозі Desktop новий підкаталог для нашої роботи, а потім змінимо поточний робочий каталог на новостворений:

BASH

$ cd ~/Desktop
$ mkdir recipes
$ cd recipes

Далі ми кажемо Git зробити recipes репозиторієм -- місцем, де Git може зберігати версії наших файлів:

BASH

$ git init

Майте на увазі, що git init створює репозиторій, до якого можна додавати підкаталоги та їх файли. Немає потреби створювати окремі репозиторії вкладені в репозиторій recipes, незалежно від того чи були підкаталоги присутні від початку або були додані пізніше. Крім того, зверніть увагу, що створення каталогу recipes та його ініціалізація як репозиторію є повністю окремими процесами.

Якщо ми використаємо ls, щоб передивитись зміст каталогу, то здається, що нічого не змінилося:

BASH

$ ls

Але якщо ми додамо опцію -a, щоб показати всі файли, то побачимо, що Git створив у каталозі recipes прихований каталог під назвою .git:

BASH

$ ls -a

ВИХІД

.	..	.git

Git використовує цей спеціальний підкаталог для зберігання всієї інформації про проєкт, у тому числі відстежувані файли і підкаталоги, що розташовані в каталозі проєкту. Якщо ми коли-небудь видалимо підкаталог .git, то ми втратимо усю історію проєкту.

Тепер ми можемо почати використовувати одну з найважливіших команд git, яка особливо корисна для початківців. git status друкує інформацію про поточний стан нашого проєкту, та перелік зроблених змін у проєкті з варіантами щодо подальших дій. Ми можемо використовувати цю команду необмежену кількість разів, як тільки ми хочемо зрозуміти, що відбувається.

BASH

$ 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. Якщо він виглядає як показано нижче, ви можете створити новий репозиторій, як було показано вище:

BASH

$ git status

ВИХІД

fatal: Not a git repository (or any of the parent directories): .git

Виправлення помилок git init

Джиммі пояснив Альфредо, що вкладений репозиторій є зайвим і може призвести до плутанини у майбутньому. Альфредо бажав би повернутися до попередньої організації проєкту де необхідний тільки один репозиторій Git. Як Альфредо може скасувати свою останню команду git init виконану у підкаталозі desserts?

Відповідь (ВИКОРИСТОВУЙТЕ ОБЕРЕЖНО!)

Контекст

Видаляти файли з репозиторію Git треба обережно. Проте, ми ще не навчилися вказувати Git як відстежувати певний файл; про це ми дізнаємося в наступному епізоді. Файли, які не відстежуються Git, можна легко видалити, як і будь-які інші “звичайні” файли:

BASH

$ rm filename

Подібним чином можна видалити каталог за допомогою команди rm -r dirname. Якщо файли чи каталоги, які видаляються таким чином, вже відстежуються Git, тоді їх видалення стає ще однією зміною, яку нам потрібно буде відстежувати (ми побачимо як це робити в наступному епізоді).

Відповідь

Git зберігає всі свої файли в каталозі .git. Щоб виправити цю маленьку помилку, Альфредо може просто видалити каталог .git у підкаталозі desserts, виконавши наступну команду всередині каталогу recipes:

BASH

$ rm -rf desserts/.git

Проте, будьте обережні! Виконання цієї команди у неправильному каталозі призведе до видалення всієї історії змін проєкту, яку ви хотіли б зберегти. Загалом, видалення файлів і каталогів за допомогою rm з командного рядка не можна скасувати. Тому завжди перевіряйте свій поточний каталог за допомогою команди pwd.

Ключові моменти

• git init ініціалізує репозиторій.
• Git зберігає всі дані репозиторію в каталозі .git.

Content from Відстеження змін

---

Останнє оновлення 2025-01-24 | Редагувати цю сторінку

Приблизний час: 20 хвилин

Огляд

Питання

• Як зберегти зміни в Git?
• Як перевірити стан свого репозиторію?
• Як зробити нотатки про те, які зміни було внесено і чому?

Цілі

• Пройти цикл зміни-додавання-коміту для одного або декількох файлів.
• Пояснити де зберігається інформація на кожному етапі цього циклу.
• Пояснити різницю між інформативними та неінформативними повідомленнями комітів.

Спочатку переконаймося, що ми все ще у правильному каталозі. Ви повинні знаходитися у каталозі recipes.

BASH

$ cd ~/Desktop/recipes

Тепер створимо файл під назвою guacamole.md з нашим рецептом. Ми будемо використовувати редактор nano для редагування файлу; ви можете використовувати будь-який редактор, який вам подобається. Зокрема, це не обовʼязково повинен бути core.editor, який ви раніше вказали глобально. Але пам’ятайте, що команда bash для створення або редагування нового файлу буде залежати від обраного редактора (який не обов’язково буде nano). Для довідки щодо текстових редакторів, дивіться “Which Editor?” в уроці The Unix Shell.

BASH

$ nano guacamole.md

Введіть наведений нижче текст у файл guacamole.md:

ВИХІД

# Guacamole
## Ingredients
## Instructions

Збережіть файл і вийдіть з редактора. Далі переконайтеся, що файл був створений належним чином, запустивши команду ls:

BASH

$ ls

ВИХІД

guacamole.md

guacamole.md містить три рядки, які ми можемо побачити, запустивши:

BASH

$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
## Instructions

Якщо ми знову перевіримо статус нашого проєкту, Git повідомляє нам, що він помітив новий файл:

BASH

$ git status

ВИХІД

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:

BASH

$ git add guacamole.md

та згодом переконатися, що все виглядає правильно:

BASH

$ git status

ВИХІД

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

	new file:   guacamole.md

Git тепер знає, що він повинен стежити за файлом guacamole.md, але він ще не записав ці зміни як коміт. Щоб зробити це, нам потрібно виконати ще одну команду:

BASH

$ git commit -m "Create a template for recipe"

ВИХІД

[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” (“Якщо застосовано, цей коміт буде” <0>). Якщо ви хочете детальніше перейти до подробиць, додайте порожній рядок між першим рядком та вашими додатковими примітками. Використовуйте додаткові примітки, щоб пояснити, чому ви внесли зміни та/або яким буде їх вплив.

Якщо ми тепер запустимо git status:

BASH

$ git status

ВИХІД

On branch main
nothing to commit, working tree clean

Git говорить нам, що поточний стан файлів відповідає їх стану, який збережений у репозиторії. Якщо ми хочемо знати, що саме ми зробили нещодавно - ми можемо попросити Git показати нам історію проєкту, використовуючи git log:

BASH

$ 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.)

BASH

$ nano guacamole.md
$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
* avocado
* lemon
* salt
## Instructions

Тепер, коли ми запускаємо git status, Git повідомляє нам, що файл, про який він вже знає, був змінений:

BASH

$ 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")

Ключова фраза - це останній рядок: “no changes added to commit”. Ми змінили цей файл, але ми ще не зберегли їх (що ми робимо за допомогою git commit), та навіть не сказали Git, що ми маємо намір зберегти ці зміни у майбутньому (що ми робимо за допомогою git add). Тож зробімо це зараз. Хорошою рекомендацією є перегляд наших змін кожного разу перед їх збереженням. Це робиться за допомогою git diff. Результат показує нам відмінності між поточним станом файлу та його останньою збереженою версією:

BASH

$ 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, яка повідомляє їм, як змінити один файл за допомогою іншого. Якщо розділити цей результат на фрагменти:

1. Перший рядок вказує на те, що результат цієї команди у Git подібний до Unix команди diff, яка порівнює стару та нову версії файлу.
2. Другий рядок повідомляє які саме версії файлу Git порівнює; df0654a та 315bf3a є унікальними ідентифікаторами цих версій.
3. Третій та четвертий рядки ще раз показують назву файлу, що змінюється.
4. Решта рядків найцікавіші, вони показують нам фактичні відмінності і рядки, у яких вони відбуваються. Зокрема, значок + в першому стовпці вказує де ми додали рядок.

Після того, як ми переглянули наші зміни, прийшов час зберегти їх:

BASH

$ git commit -m "Add basic guacamole's ingredients"
$ 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 не буде додавати зміни, тому що ми не використали спочатку git add. Давайте це виправимо:

BASH

$ git add guacamole.md
$ git commit -m "Add basic guacamole's ingredients"

ВИХІД

[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” частіше, ніж вам хотілося б!

Подивімося, як наші зміни у файлі проходять шлях від текстового редактора до зони стейджингу і далі у довгострокове зберігання. По-перше, ми покращимо наш рецепт, змінивши лимон на лайм:

BASH

$ nano guacamole.md
$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions

BASH

$ git diff

ВИХІД

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:

BASH

$ git add guacamole.md
$ git diff

Результату немає: це виглядає ніби для Git немає різниці між тим, що вже було збережено назавжди та тим, що зараз міститься у робочій директорії. Проте, якщо ми зробимо наступне:

BASH

$ git diff --staged

ВИХІД

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

то ми побачимо різницю між останніми збереженими змінами та тими, які знаходяться в зоні стейджингу. Збережімо наші зміни:

BASH

$ git commit -m "Modify guacamole to the traditional recipe"

ВИХІД

[main 005937f] Modify guacamole to the traditional recipe
 1 file changed, 1 insertion(+)

Перевіримо наш статус:

BASH

$ git status

ВИХІД

On branch main
nothing to commit, working tree clean

і подивимося на історію попередніх змін:

BASH

$ git log

ВИХІД

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 - кількість комітів які б ви бажали бачити на екрані. Наприклад, якщо ви бажаєте побачити лише останній коміт, використовуйте команду

BASH

$ git log -1

ВИХІД

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:

BASH

$ git log --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, або іншими обʼєктами у репозиторії’:

BASH

$ git log --oneline --graph

ВИХІД

* 005937f (HEAD -> main) Modify guacamole to the traditional recipe
* 34961b1 Add basic guacamole's ingredients
* f22b25e Create a template for recipe

Каталоги

Дві важливі речі, які ви повинні знати про каталоги в Git.

1. Git не відстежує каталоги самостійно, тільки файли всередині них. Спробуйте власноруч:

BASH

$ mkdir cakes
$ git status
$ git add cakes
$ git status

Зауважте, наш новостворений порожній каталог cakes не зʼявляється в переліку невідстежуваних файлів, навіть якщо ми конкретно додали його (через git add) до нашого репозиторію. Ось чому ви іноді бачите файли .gitkeep в інших порожніх каталогах. На відміну від .gitignore, ці файли не є особливими і їх єдиною метою є заповнити каталог, щоб Git додав його до репозиторію. Насправді ви можете назвати такі файли до вашої вподоби.

2. Якщо ви створюєте каталог у вашому репозиторії Git і заповнюєте його файлами, ви можете додати всі файли в каталозі одразу:

BASH

$ git add <directory-with-files>

Спробуйте власноруч:

BASH

$ touch cakes/brownie_cakes/lemon_drizzle
$ git status
$ git add cakes
$ git status

Перш ніж рухатися далі, ми збережемо ці зміни.

BASH

$ git commit -m "Add some initial cakes"

Для повторення: коли ми хочемо додати зміни до нашого репозиторію, спочатку нам потрібно додати змінені файли в зону стейджингу (git add) а потім зберегти заплановані зміни до репозиторію (git commit):

{alt=‘Два документи окремо додаються до зони стейджингу за допомогою git add, а потім об’єднуються в один коміт за допомогою git commit’}

Вибір повідомлення коміту

Яке з наступних повідомлень буде найдоречнішим для останнього коміту до guacamole.md?

1. “Changes”
2. “Changed lemon for lime”
3. “Guacamole modified to the traditional recipe”

Рішення

Відповідь 1 є недостатньо детальною, а мета коміту неясна; відповідь 2 дублює результат команди “git diff” яка покаже зміни, зроблені у цьому коміті; відповідь 3 - оптимальна: коротка, інформативна, та імперативна.

Збереження змін у Git

Яка(які) з наведених нижче команд збережуть зміни у файлі myfile.txt до мого локального Git репозиторію?

1. BASH

      $ git commit -m "my recent changes"

2. BASH

      $ git init myfile.txt
      $ git commit -m "my recent changes"

3. BASH

      $ git add myfile.txt
      $ git commit -m "my recent changes"

4. BASH

      $ git commit -m myfile.txt "my recent changes"

Рішення

1. Створить коміт, лише якщо файли вже були у зоні стейджінгу.

2. Намагатиметься створити новий репозиторій.

3. Правильна відповідь: спочатку додайте файл до зони стейджингу, потім зробіть коміт.

4. Спробує записати коміт файлу з назвою “my recent changes” з повідомленням myfile.txt.

Коміт декількох файлів

Зона стейджингу може зберігати зміни в будь-якій кількості файлів, які ви хочете записати в один коміт.

1. Додайте до guacamole.md текст про приблизну ціну інгредієнтів.
2. Створіть новий файл groceries.md зі списком товарів та їх цінами на різних ринках.
3. Додайте зміни в обох файлах до зони стейджінгу, та зробіть коміт цих змін.

Рішення

Спочатку ми оновимо файли guacamole.md та groceries.md:

BASH

$ nano guacamole.md
$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
* avocado (1.35)
* lime (0.64)
* salt (2)

BASH

$ nano groceries.md
$ cat groceries.md

ВИХІД

# Market A
* avocado: 1.35 per unit.
* lime: 0.64 per unit
* salt: 2 per kg

Тепер ви можете додати обидва файли до зони стейджингу. Ми можемо зробити це однією командою:

BASH

$ git add guacamole.md groceries.md

Або кількома:

BASH

$ git add guacamole.md
$ git add groceries.md

Тепер файли готові до коміту. Ви можете перевірити це за допомогою git status. Якщо ви готові зробити коміт, використайте:

BASH

$ git commit -m "Write prices for ingredients and their source"

ВИХІД

[main cc127c2]
 Write prices for ingredients and their source
 2 files changed, 7 insertions(+)
 create mode 100644 groceries.md

Вправа: репозиторій з вашою автобіографією

• Створіть новий репозиторій Git на вашому компʼютері під назвою bio.
• Напишіть три рядки своєї біографії у файлі під назвою me.txt, та зробіть коміт цих змін.
• Змініть один з рядків та додайте четвертий рядок.
• Покажіть відмінності між оновленим файлом та його попередньою версією.

Відповідь

За потреби вийдіть з каталогу recipes:

BASH

$ cd ..

Створіть новий каталог bio та перейдіть до нього:

BASH

$ mkdir bio
$ cd bio

Ініціалізуйте репозиторій Git:

BASH

$ git init

Створіть файл me.txt з вашою біографією, використовуючи nano або інший текстовий редактор. Коли будете готові, додайте його до зони стейджингу та запишіть коміт до репозиторію:

BASH

$ git add me.txt
$ git commit -m "Add biography file"

Змініть файл як вказано (змініть один рядок, додайте четвертий рядок). Для того, щоб показати зміни між оновленим файлом та його попередньою версією, використайте git diff:

BASH

$ git diff me.txt

Ключові моменти

• git status показує стан репозиторію.
• Файли можуть зберігатися в робочому каталозі проєкту (де їх бачать користувачі), зоні стейджингу (де будується наступний коміт) і локальному репозиторії (де коміти зберігаються постійно).
• git add додає файли до зони стейджингу.
• git commit зберігає все, що міститься у зоні стейджингу, як новий коміт у локальному репозиторії.
• Повідомлення коміту треба складати так, щоб воно чітко описувало ваші зміни.

Content from Дослідження історії

---

Останнє оновлення 2025-01-24 | Редагувати цю сторінку

Приблизний час: 25 хвилин

Огляд

Питання

• Як визначити старі версії файлів?
• Як переглянути свої зміни?
• Як відновити старі версії файлів?

Цілі

• Пояснення, що таке HEAD репозиторію та як його використовувати.
• Визначення та використання ідентифікаторів комітів Git.
• Порівняння різних версій відстежуваних файлів.
• Відновлення старих версій файлів.

Як ми побачили у попередньому епізоді, ми можемо посилатися на коміти за їх ідентифікаторами. Ви можете звернутися до останнього коміту робочого каталогу за допомогою ідентифікатора HEAD.

Оскільки кожного разу ми додавали невеликі зміни до guacamole.md, зараз нам буде легко відстежувати наш прогрес. Зробімо це, використовуючи HEAD. Перш ніж ми почнемо, змінімо guacamole.md, додавши ще один рядок.

BASH

$ nano guacamole.md
$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
An ill-considered change

Тепер подивимося на наш результат.

BASH

$ git diff HEAD guacamole.md

ВИХІД

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.

BASH

$ git diff HEAD~1 guacamole.md

Якщо ми хочемо побачити різницю між старішими комітами, ми можемо знову використовувати git diff, використовуючи для послання на них HEAD~1, HEAD~2 тощо:

BASH

$ git diff HEAD~2 guacamole.md

ВИХІД

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 яка покаже різницю між комітом та нашим робочим каталогом).

BASH

$ git show HEAD~2 guacamole.md

ВИХІД

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, тож спробуймо наступне:

BASH

$ git diff f22b25e3233b4645dabd0d81e651fe074bd8e73b guacamole.md

ВИХІД

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 дозволяє нам використовувати тільки перші кілька символів (як правило, сім для проєктів нормального розміру):

BASH

$ git diff f22b25e guacamole.md

ВИХІД

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 зараз каже нам, що файл був змінений, але ці зміни не були додані до зони стейджингу:

BASH

$ 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:

BASH

$ git restore guacamole.md
$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions

Як можна здогадатися з назви, ‘git restore’ відновлює стару версію файлу. За замовчуванням git restore відновлює версію файлу, записану в HEAD, який є останнім збереженим комітом. Якщо ми хочемо повернутися ще раніше, замість цього ми можемо використовувати ідентифікатор коміту з опцією -s:

BASH

$ git restore -s f22b25e guacamole.md

BASH

$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
## Instructions

BASH

$ 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:

BASH

$ git restore guacamole.md
$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions

Важливо пам’ятати, що ми повинні використовувати номер коміту, який ідентифікує стан репозиторію до зміни, яку ми намагаємося скасувати. Поширеною помилкою є використання номеру коміту, в якому ми зробили зміни, які намагаємося скасувати. У наведеному нижче прикладі нам треба ‘дістати’ передостанній коміт (HEAD~1), тобто коміт f22b25e. Ми використовуємо ., щоб позначити всі файли:

Отже, якщо скласти це все разом, то Git працює як зображено у цьому коміксі:

https://figshare.com/articles/How\_Git\_works\_a\_cartoon/1328266

Той факт, що файли можна відновлювати окремо, сприяє змінам в організації роботи. Якщо все знаходиться в одному величезному документі, буде важко (але не неможливо) скасувати зміни у вступі без скасування також змін, внесених пізніше до висновку. З іншого боку, якщо вступ і висновок зберігаються в окремих файлах, рухатися вперед і назад в часі стає набагато легше.

Відновлення старих версій файлу

Дженніфер зробила цього ранку деякі зміни у скрипті Python, над яким вона до цього працювала тижнями, та “зламала” його - він більше не запускається. Вона витратила майже годину, намагаючись виправити його, але безрезультатно…

На щастя, вона використовує Git для відстеження змін у свому проєкті! Які з наведених нижче команд допоможуть їй відновити останню збережену у Git версію її скрипту, який називається data_cruncher.py?

1. $ git restore

2. $ git restore data_cruncher.py

3. $ git restore -s HEAD~1 data_cruncher.py

4. $ git restore -s <unique ID of last commit> data_cruncher.py

5. Як 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. Яка команда відсутня?

1. ________ # Подивіться на історію змін, щоб знайти ідентифікатор коміту

2. Скопіюйте цей ID (перші кілька символів ID, наприклад 0b1d055).

3. git revert [commit ID]

4. Введіть повідомлення для нового коміту.

5. Збережіть його та закрийте редактор.

Рішення

Команда 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

1. ВИХІД

      ketchup enhances pasta dishes

2. ВИХІД

      I like tomatoes, therefore I like ketchup

3. ВИХІД

      I like tomatoes, therefore I like ketchup
      ketchup enhances pasta dishes

4. ВИХІД

      Помилка, оскільки ви змінили 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, щоб видалити файл з зони стейджингу:

BASH

$ git restore --staged guacamole.md

Тепер git status зображує наступне:

BASH

$ 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 для відновлення файлу до попереднього коміту:

BASH

$ git restore guacamole.md
$ git status

ВИХІД

On branch main
nothing to commit, working tree clean

Перегляд і пошук в історії

Перегляд історії є важливим аспектом роботи з Git, але зазвичай знайти правильний ідентифікатор коміту може бути важко, особливо якщо він був зроблений декілька місяців тому.

Уявіть, що проєкт recipes містить понад 50 файлів. Вам потрібно знайти коміт, який змінює певний текст у guacamole.md. Коли ви вводите git log, з’являється дуже довгий список. Як можна звузити коло пошуку?

Пам’ятайте, що команда git diff дозволяє перевіряти зміни в певному файлі, наприклад, git diff guacamole.md. Ми можемо застосувати подібну ідею тут.

BASH

$ git log guacamole.md

На жаль, деякі повідомлення комітів дуже неоднозначні, наприклад, update files. Як же переглянути усі ці версії файлу?

Обидві команди git diff та git log дуже корисні для отримання звітів про різні частини історії проєкту. Але чи можна об’єднати їх результат в одну команду? Спробуймо наступне:

BASH

$ git log --patch guacamole.md

Ви повинні отримати довгий список, у якому ви побачите як повідомлення коміту, так і зроблені зміни.

Питання: Що робить наступна команда?

BASH

$ git log --patch HEAD~9 *.md

Ключові моменти

• git diff показує відмінності між комітами.
• git restore відновлює старі версії файлів.

Content from Ігнорування файлів

---

Останнє оновлення 2025-01-24 | Редагувати цю сторінку

Приблизний час: 5 хвилин

Огляд

Питання

• Як зробити так, щоб Git ігнорував файли, які я не хочу відстежувати?

Цілі

• Налаштувати Git для ігнорування певних файлів.
• Зрозуміти чому ігнорування файлів може бути корисним.

Що робити, якщо у нас є файли, які ми не хочемо відстежувати у Git, наприклад, резервні файли, створені нашим редактором або проміжні файли, створені під час аналізу даних? Створімо декілька фіктивних файлів:

BASH

$ mkdir receipts
$ touch a.png b.png c.png receipts/a.jpg receipts/b.jpg

і подивимося, що скаже Git:

BASH

$ git status

ВИХІД

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:

BASH

$ nano .gitignore
$ cat .gitignore

ВИХІД

*.png
receipts/

Ці шаблони наказують Git ігнорувати будь-який файл, ім’я якого закінчується на .png, і все в каталозі receipts. (Якщо будь-які з цих файлів вже відстежуються, то Git продовжить їх відстежувати.)

Як тільки ми створили цей файл, результат команди git status стає набагато зрозумілішим:

BASH

$ 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:

BASH

$ git add .gitignore
$ git commit -m "Ignore png files and the receipts folder."
$ git status

ВИХІД

On branch main
nothing to commit, working tree clean

Як бонус, використання .gitignore допомагає нам уникнути випадкового додавання до репозиторію файлів, які ми не хочемо відстежувати:

BASH

$ git add a.png

ВИХІД

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. Якщо потрібно, можна також побачити статус ігнорованих файлів:

BASH

$ git status --ignored

ВИХІД

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

Ігнорування вкладених файлів

Враховуючи структуру каталогу, яка виглядає так:

BASH

receipts/data
receipts/plots

Як зробити так, щоб Git ігнорував тільки receipts/plots, а не receipts/data?

Рішення

Якщо ви хочете ігнорувати лише вміст 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 файлів до кореневого каталогу будуть проігноровані.

Варіант ігнорування вкладених файлів

Нехай ми маємо структуру каталогів, яка виглядає подібно до попередньої вправи “Ігнорування файлів у підкаталогах”, проте дещо відрізняється:

BASH

receipts/data
receipts/images
receipts/plots
receipts/analysis

Як би ви проігнорували весь вміст у каталозі 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, незалежно від їх розташування у дереві каталогів. Ви все ще можете робити певні винятки з цього правила за допомогою знаку оклику.

Порядок застосування правил

Нехай нам дано файл .gitignore з наступним вмістом:

BASH

*.csv
!*.csv

Який вплив це буде мати на ігнорування файлів?

Рішення

Оператор ! скасує запис з попередньо визначеного шаблону ігнорування. Оскільки запис ! *.csv скасовує всі попередні файли .csv в .gitignore, жоден з них не буде проігноровано, і всі файли .csv будуть відстежуватися.

Log-файли

Ви написали скрипт, який створює багато проміжних log-файлів з назвами log_01, log_02, log_03 тощо. Ви хочете зберегти їх, але не бажаєте відстежувати їх за допомогою git.

1. Додайте до .gitignore один рядок, який виключає файли log_01, log_02 тощо.

2. Перевірте свій “шаблон ігнорування”, створивши деякі фіктивні файли з назвами log_01, log_02 тощо.

3. Уявіть тепер, що файл log_01 дуже важливий, та додайте його до відстежуваних файлів, не змінюючи .gitignore.

4. Обговоріть з сусідом, які інші типи файлів можуть перебувати у вашому проєкті, які ви не бажаєте відстежувати і тому бажаєте проігнорувати за допомогою .gitignore.

Рішення

1. додайте або log_* або log* як новий рядок до вашого .gitignore

2. відстежуйте 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:

BASH

$ mkdir recipes
$ cd recipes
$ git init

Якщо ви пам’ятаєте, в одному з попередніх епізодів, де ми додавали та зберігали нашу попередню роботу над guacamole.md, в нас була діаграма, яка зображувала локальний репозиторій, та виглядала так:

Тепер, коли ми маємо два репозиторії, нам потрібна така діаграма:

Зауважте, що наш локальний репозиторій все ще містить нашу попередню роботу над guacamole.md, але віддалений репозиторій на GitHub виглядає порожнім, оскільки він ще не містить файлів.

2. Підʼєднання локального репозиторію до віддаленого

---

Тепер підключаємо два сховища одне до одного. Ми робимо це вказуючи GitHub репозиторій у якості віддаленого для локального репозиторію. Домашня сторінка репозиторію на GitHub містить URL, який нам потрібен, щоб його ідентифікувати:

Натисніть на кнопку ‘SSH’, щоб змінити протокол з HTTPS на SSH.

HTTPS в порівнянні з SSH

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

Скопіюйте цю URL-адресу з браузера, перейдіть до локального репозиторію recipes, та виконайте цю команду:

BASH

$ git remote add origin git@github.com:alflin/recipes.git

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:

BASH

$ 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 (список), щоб перевірити, які пари ключів вже існують на вашому комп’ютері.

BASH

$ ls -al ~/.ssh

Ваш результат буде виглядати трохи інакше в залежності від того, чи був коли-небудь 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 додає до ключа коментар (який у цьому випадку є електронною поштою Альфредо):

BASH

$ ssh-keygen -t ed25519 -C "a.linguini@ratatouille.fr"

Якщо ви використовуєте старішу систему, яка не підтримує алгоритм 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, відповідні файли будуть знайдені:

BASH

ls -al ~/.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 дозволити нашу автентифікацію.

BASH

ssh -T git@github.com

ВИХІД

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 в кінці цієї команди - в іншому випадку ви будете дивитись на приватний ключ.

BASH

cat ~/.ssh/id_ed25519.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”, щоб завершити налаштування.

Тепер, коли ми усе налаштували, ми знову перевіримо нашу автентифікацію з командного рядка.

BASH

$ ssh -T git@github.com

ВИХІД

Hi Alfredo! You've successfully authenticated, but GitHub does not provide shell access.

Добре! Цей результат підтверджує, що ключ SSH працює як очікується. Тепер ми готові завантажити нашу роботу до віддаленого репозиторію.

4. Завантаження локальних змін до віддаленого репозиторію

---

Тепер, коли аутентифікація налаштована, ми можемо повернутися до віддаленого репозиторію. Наступна команда завантажить зміни з нашого локального репозиторію до репозиторію на GitHub:

BASH

$ git push origin main

Оскільки Альфредо встановив пароль для свого ключа, то йому буде потрібно його ввести після відповідного запитання. Якщо ви не встановили пароль для свого ключа, то команда не буде його запитувати.

ВИХІД

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 за допомогою наступних команд:

BASH

$ git config --global --unset http.proxy
$ git config --global --unset https.proxy

Менеджери паролів

Якщо у вашій операційній системі налаштовано менеджер паролів, git push спробує використати його, коли йому знадобляться ваші імʼя користувача і пароль. Наприклад, це є стандартною поведінкою Git Bash у Windows. Якщо ви бажаєте вводити своє ім`я користувача та пароль в терміналі замість використання менеджеру паролів, то введіть:

BASH

$ unset SSH_ASKPASS

у терміналі, перед тим як виконати 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` один раз після налаштування віддаленого репозиторію.

Ми також можемо завантажувати зміни з віддаленого репозиторію до локального:

BASH

$ git pull 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 виявить, що вони мають історії, які не мають спільного походження, та відмовиться від злиття.

BASH

$ git pull origin main

ВИХІД

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. Будьте обережні, коли ви використовуєте цей параметр і уважно перевірте вміст локального і віддаленого репозиторіїв перед об’єднанням.

BASH

$ git pull --allow-unrelated-histories origin main

ВИХІД

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, Співавтор вводить:

BASH

$ git clone git@github.com:alflin/recipes.git ~/Desktop/alflin-recipes

(обовʼязково замініть ‘alflin’ на ім`я користувача GitHub Власника).

Якщо ви вирішите клонувати без додавання шляху клонування (~/Desktop/alflin-recipes) вказаного в кінці команди, ви будете клонувати всередину вашого власного каталогу recipes! Переконайтеся, що спочатку ви перейшли до каталогу Desktop.

Співавтор тепер може зробити зміни у своєму клоні репозиторію Власника так само, як ми робили раніше:

BASH

$ cd ~/Desktop/alflin-recipes
$ nano hummus.md
$ cat hummus.md

ВИХІД

# Hummus
## Ingredients
* chickpeas
* lemon
* olive oil
* salt

BASH

$ git add hummus.md
$ git commit -m "Add ingredients for hummus"

ВИХІД

 1 file changed, 6 insertion(+)
 create mode 100644 hummus.md

Далі, відправте зміни до репозиторію Власника на GitHub:

BASH

$ git push origin main

ВИХІД

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 зміни, які зробив Співавтор, Власник вводить:

BASH

$ git pull origin main

ВИХІД

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:

BASH

$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions

Тепер додамо один рядок до копії співавтора:

BASH

$ nano guacamole.md
$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
* put one avocado into a bowl.

а потім відправимо наші зміни на GitHub:

BASH

$ git add guacamole.md
$ git commit -m "First step on the instructions"

ВИХІД

[main 5ae9631] First step on the instructions
 1 file changed, 1 insertion(+)

BASH

$ git push origin main

ВИХІД

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:

BASH

$ nano guacamole.md
$ cat guacamole.md

ВИХІД

# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
* peel the avocados

Ми можемо зробити коміт наших змін локально:

BASH

$ git add guacamole.md
$ git commit -m "Add first step"

ВИХІД

[main 07ebc69] Add first step
 1 file changed, 1 insertion(+)

але Git не дозволить нам відправити зміни на GitHub:

BASH

$ git push origin main

ВИХІД

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. Давайте почнемо з отримання змін:

BASH

$ git pull origin main

ВИХІД

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 призводить до злиття розбіжних гілок. У нашому випадку нам потрібна стандартна стратегія. Щоб використовувати її, виконайте наступну команду, яка встановить її як дію за замовчуванням.

BASH

$ git config pull.rebase false

Потім спробуйте отримати зміни ще раз.

BASH

$ git pull origin main

Команда git pull оновлює локальний репозиторій, щоб додати до нього ті зміни, які вже містяться у віддаленому репозиторії. Після отримання змін із віддаленої гілки Git визначає, що зміни, внесені до локальної копії, конфліктують зі змінами, зробленими у віддаленому репозиторії. Тому, щоб запобігти перезапису нашої роботи, Git відмовляється об’єднувати дві версії. У файлі, де є конфлікт, він позначається наступним чином:

BASH

$ cat guacamole.md

ВИХІД

# 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

BASH

$ git commit -m "Merge changes from GitHub"

ВИХІД

[main 2abf2b1] Merge changes from GitHub

Тепер ми можемо відправити наші зміни на GitHub:

BASH

$ git push origin main

ВИХІД

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:

BASH

$ git pull origin main

ВИХІД

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

Ми отримуємо файл з об’єднаними змінами:

BASH

$ cat guacamole.md

ВИХІД

# 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’.

Якщо у вас немає файлу із зображенням гуакамоле, ви можете створити фіктивний бінарний файл наступним чином:

BASH

$ head --bytes 1024 /dev/urandom > guacamole.jpg
$ ls -lh guacamole.jpg

ВИХІД

-rw-r--r-- 1 alflin 57095 1.0K Mar  8 20:24 guacamole.jpg

ls показує, що було створено файл розміром 1 кілобайт. Він містить випадкові байти, які були зчитані зі спеціального файлу /dev/urandom.

Тепер припустимо, що Альфредо додає guacamole.jpg до свого репозиторію:

BASH

$ git add guacamole.jpg
$ git commit -m "Add picture of guacamole"

ВИХІД

[main 8e4115c] Add picture of guacamole
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 guacamole.jpg

Припустимо, що Джиммі тим часом додав схожу фотографію. На його фотографії зображено гуакамоле з начос, але воно також називається guacamole.jpg. Коли Альфредо намагається відправити зміни до віддаленого репозиторію, він отримує вже знайоме повідомлення:

BASH

$ git push origin main

ВИХІД

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.

Як ми вже дізналися раніше, ми спочатку маємо отримати зміни та вирішити усі конфлікти:

BASH

$ git pull origin main

Коли конфлікт виникає у зображенні або іншому бінарному файлі, 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) і подивіться як вона обмежує використання програмного забезпечення. Чи це одна з ліцензій обговорювана у цьому епізоді? Якщо ні, то чим вона відрізняється?

• Git - інструмент для управління вихідним кодом
• CPython - стандартна реалізація мови Python
• Jupyter - проєкт, який стоїть за вебноутбуками Python, які ми будемо використовувати
• EtherPad - редактор для спільної роботи в реальному часі

Ключові моменти

• Файли з імʼям 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 може бути доступна у варіантах із самостійним хостингом, використання онлайн-сервісу вимагає набагато менше зусиль з налаштування та обслуговування. Крім того, такі інструменти часто надаються безкоштовно для проєктів з відкритим вихідним кодом, а також доступні для приватних репозиторіїв за окрему плату.

Інституційні бар’єри

Відкритий доступ - ідеальна ситуація для науки, але багато установ накладають обмеження на розповсюдження інформації, наприклад, для захисту потенційно патентованої інтелектуальної власності. Якщо ви стикаєтеся з такими обмеженнями, може бути доречно запитати про джерела їх мотивації. Можна запросити зробити виняток для конкретного проєкту чи галузі, або наполягати ширше на необхідності інституційної реформи для підтримки більшої відкритості у науці.

Чи може моя робота бути у відкритому доступі?

Дізнайтеся, чи дозволено вам відкрито розміщувати свою роботу в публічному репозиторії. Чи можете ви зробити це в односторонньому порядку, або вам потрібен дозвіл від когось у вашому закладі? Якщо так, то від кого?

Де я можу розмістити свою роботу у відкритому доступі?

Чи є у вашій установі репозиторій або репозиторії, які ви можете використовувати для обміну документами, даними та програмним забезпеченням? Чим інституційні репозиторії відрізняються від таких сервісів, як arXiV, figshare, GitHub або GitLab?

Ключові моменти

• Проєкти можуть бути розміщені на серверах університетів, в особистих доменах або на публічному сервісі хостингу.
• Правила щодо інтелектуальної власності та зберігання конфіденційної інформації застосовуються незалежно від місця розміщення коду та даних.

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, що треба ігнорувати ці файли та директорії.

Завдання

1. Створіть у вашому проєкті новий каталог під назвою graphs.
2. Змініть .gitignore, щоб graphs не відстежувався контролем версій.

Відповідь

Це можна зробити в Rstudio наступним чином:

R

dir.create("./graphs")

Потім відкрийте файл .gitignore з правої панелі Rstudio та додайте graphs/ до списку файлів, які слід ігнорувати.

У меню Git у RStudio є ще багато інших функцій, але цих має бути достатньо, щоб почати!

Ключові моменти

• Використання інтеграції Git із RStudio дозволяє відстежувати еволюцію проєкту.