Співпраця

Огляд

Питання

• Як я можу використовувати контроль версій для співпраці з іншими?

Цілі

• Клонування віддаленого репозиторію.
• Співпраця шляхом надсилання змін до спільного репозиторію.
• Загальний вигляд процесу співпраці.

Для наступного кроку слухачам потрібно розбитися на пари. Одна людина буде “Власником”, а інша - “Співавтором”. Мета полягає в тому, щоб Співавтор додав зміни в репозиторій Власника. У подальшому слухачі поміняються ролями так, щоб обидві людини спробували грати ролі як Власника, так і Співавтора.

Практика без партнера

Якщо ви працюєте над цим уроком самостійно, ви можете імітувати подібний сценарій, відкривши ще одне вікно терміналу. Це вікно буде представляти вашого партнера, який працює на іншому комп’ютері. Вам не буде потрібно надавати нікому доступ до GitHub, тому що обидва “партнери” - це ви.

Власник репозиторію повинен надати Співавтору доступ. У GitHub, натисніть кнопку “Settings” праворуч, оберіть “Collaborators”, натисніть “Add people”, та потім введіть ім`я користувача GitHub, повідомлене вашим партнером.

Щоб отримати доступ до репозиторію Власника, Співавтору потрібно відкрити https://github.com/notifications або перевірити наявність повідомлення електронною поштою. Потім треба прийняти відповідне запрошення, яке ви там знайдете.

Далі, Співавтор повинен завантажити копію репозиторію Власника на свій комп`ютер. Це називається “клонування репозиторію”.

Співавтор не хоче втратити свою власну версію planets.git, і тому йому потрібно клонувати репозиторій Власника в інше місце, аніж у свій власний репозиторій з такою ж назвою.

Щоб клонувати репозиторій Власника у каталог Desktop, Співавтор вводить:

BASH

$ git clone git@github.com:vlad/planets.git ~/Desktop/vlad-planets

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

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

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

BASH

$ cd ~/Desktop/vlad-planets
$ nano pluto.txt
$ cat pluto.txt

ВИХІД

It is so a planet!

BASH

$ git add pluto.txt
$ git commit -m "Add notes about Pluto"

ВИХІД

 1 file changed, 1 insertion(+)
 create mode 100644 pluto.txt

Далі, відправте зміни до репозиторію Власника на 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/vlad/planets.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/vlad/planets
 * branch            main     -> FETCH_HEAD
   9272da5..29aba7c  main     -> origin/main
Updating 9272da5..29aba7c
Fast-forward
 pluto.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 pluto.txt

Тепер три репозиторії (локальний Власника, локальний Співавтора, і репозиторій Власника на 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.