У моїй конфігурації запрошення командного рядка рознесене на кілька рядків, тому воно буде відрізнятися. Головне, зверніть увагу, що з’являється додаткова інформація при переході в репозиторій.
Для керування Git використовуються різні команди, зміст яких пояснюється далі.
git status
При роботі з Git важливо розуміти поточний статус репозиторію. Для цього у Git є команда git status:
Git повідомляє, що ми знаходимося в гілці master (ця гілка створюється сама і використовується за замовчуванням), і що йому нема чого додавати в коміт. Крім цього, Git пропонує створити або скопіювати файли і після цього скористатися командою git add, щоб Git почав стежити за ними.
Створення файлу README та додавання до нього рядка «test»:
$ vi README
$ echo "test" >> README
Після цього запрошення виглядає таким чином:
У запрошенні показано, що є два файли, за якими Git ще не стежить:
Два файли вийшло через те, що я налаштований undo-файли для Vim. Це спеціальні файли, завдяки яким можна скасовувати зміни не тільки в поточній сесії файлу, а й у минулі. Зауважте, що Git повідомляє, що є файли, за якими він не стежить і підказує, якою командою це зробити.
Файл .gitignore
Undo-файл .README.un~ – службовий файл, який не потрібно додавати до репозиторію. Git має можливість вказати, які файли або каталоги потрібно ігнорувати. Для цього потрібно створити відповідні шаблони у файлі .gitignore у каталозі репозиторію.
Для того, щоб Git ігнорував undo-файли Vim, можна додати, наприклад, такий рядок у файл .gitignore:
*.un~
Це означає, що Git повинен ігнорувати всі файли, які закінчуються на .un ~.
Після цього, git status показує:
Зверніть увагу, що тепер у виводі немає файлу .README.un~. Як тільки до репозиторію було додано файл .gitignore, файли, які вказані в ньому, стали ігноруватися.
git add
Для того щоб Git почав стежити за файлами, використовується команда git add.
Можна вказати що слід стежити за конкретним файлом:
Або за всіма файлами:
Висновок git status:
Тепер файли знаходяться у секції під назвою Changes to be committed.
git commit
Після того, як всі потрібні файли були додані в staging, можна змінити зміни. Staging – це сукупність файлів, які будуть додані до наступного коміту. Команда git commit має лише один обов’язковий параметр – прапор «-m». Він дає змогу вказати повідомлення для цього комміту.
Після цього git status відображає:
Фраза “nothing to commit, working directory clean” означає, що немає змін, які потрібно додати до Git або закоммітити.
Додаткові можливості
git diff
Команда git diff дозволяє переглянути різницю між різними станами. Наприклад, на даний момент, в репозиторії внесено зміни до файлу README та .gitignore.
Команда git status показує, що обидва файли змінені:
Команда git diff показує, які зміни було внесено з моменту останнього комміту:
Якщо додати зміни, внесені до файлів, в staging командою і ще раз виконати команду , то вона нічого не покажеgit addgit diff:
Щоб показати відмінності між staging та останнім коммітом, треба додати параметр--staged:
Закомітити зміни:
git log
Команда git log показує, коли було виконано останні зміни:
За замовчуванням команда показує всі комміти, починаючи з найближчого часу. За допомогою додаткових параметрів можна не тільки переглянути інформацію про коміти, але й те, які зміни були внесені.
Прапор -pдозволяє відобразити відмінності, внесені кожним коммітом:
Коротший варіант виведення можна вивести з прапором--stat:
Аутентифікація на GitHub
Для того щоб почати працювати з GitHub, треба на ньому зареєструватися . Для безпечної роботи з GitHub краще використовувати аутентифікацію ключів SSH.
Генерація нового SSH-ключа (використовуйте e-mail, який прив’язаний до GitHub):
На всіх питаннях достатньо натиснути Enter (безпечніше використовувати ключ з passphrase, але можна і без, якщо натиснути Enter при питанні, тоді passphrase не буде запитуватися у вас постійно при операціях з репозиторієм).
SSH-агент використовується для зберігання ключів у пам’яті та зручний тим, що немає необхідності вводити пароль passphrase щоразу при взаємодії з віддаленим хостом (в даному випадку – github.com).
Запуск SSH-агента (пропускаємо на Windows):
Додати ключ до SSH-агент (пропускаємо на Windows):
$ ssh-add ~/.ssh/id_rsa
Додавання SSH-ключа на GitHub
Для додавання ключа його потрібно скопіювати.
Наприклад, таким чином можна відобразити ключ для копіювання:
$ cat ~/.ssh/id_rsa.pub
Після копіювання потрібно перейти на GitHub. Перебуваючи на будь-якій сторінці GitHub, у правому верхньому кутку натисніть на картинку вашого профілю і в списку виберіть «Settings». У списку зліва треба вибрати поле “SSH and GPG keys”. Після цього потрібно натиснути New SSH key і в полі Title написати назву ключа (наприклад Home), а в поле Key вставити вміст, який було скопійовано з файлу ~/.ssh/id_rsa.pub.
Щоб перевірити, чи все пройшло успішно, спробуйте виконати команду .ssh -T [email protected]
Висновок має бути таким:
$ ssh -T [email protected]
Hi username! You've successfully authenticated, but GitHub does not provide shell access.
Тепер ви готові працювати з Git та GitHub.
Створення репозиторію на GitHub
Для створення свого репозиторію на основі шаблону потрібно:
-
залогінитися на GitHub
-
відкрити репозиторій із завданнями
-
натиснути «Use this template» та створити новий репозиторій на основі цього шаблону
-
у вікні треба ввести назву репозиторію
-
після цього готовий новий репозиторій із копією всіх файлів із вихідного репозиторію із завданнями
Клонування репозиторію з GitHub
Для локальної роботи з репозиторієм його необхідно клонувати.
Для цього використовується команда git clone:
$ git clone ssh://[email protected]/natenka/my_pyneng_tasks.git
Cloning into 'my_pyneng_tasks'...
remote: Counting objects: 241, done.
remote: Compressing objects: 100% (191/191), done.
remote: Total 241 (delta 43), reused 239 (delta 41), pack-reused 0
Receiving objects: 100% (241/241), 119.60 KiB | 0 bytes/s, done.
Resolving deltas: 100% (43/43), done.
Checking connectivity... done.
Порівняно з наведеною в цьому лістингу командою вам потрібно змінити:
-
ім’я користувача natenka на ім’я користувача на GitHub;
-
ім’я репозиторію my_pyneng_tasks на ім’я свого репозиторію на GitHub.
У результаті, в поточному каталозі, в якому було виконано команду git clone, з’явиться каталог з ім’ям репозиторію, в моєму випадку – «my_pyneng_tasks». У цьому каталозі тепер міститься вміст репозиторію на GitHub.
Робота з репозиторієм
Попередня команда не просто скопіювала репозиторій, щоб використовувати його локально, але й налаштувала відповідним чином Git:
-
створено каталог .git
-
завантажено всі дані репозиторію
-
завантажено всі зміни, які були в репозиторії
-
репозиторій на GitHub налаштований як remote для локального репозиторію
Тепер готовий повноцінний локальний репозиторій Git, у якому ви можете працювати. Зазвичай послідовність роботи буде такою:
-
перед початком роботи, синхронізація локального вмісту з GitHub командою git pull
-
зміна файлів репозиторію
-
додавання змінених файлів до staging командою git add
-
фіксація змін через коміт командою git commit
-
передача локальних змін у репозиторії на GitHub командою git push
При роботі із завданнями на роботі та вдома, треба звернути особливу увагу на перший та останній крок:
-
перший крок – оновлення локального репозиторію
-
останній крок – завантаження змін на GitHub
Синхронізація локального репозиторію з віддаленим
Усі команди виконуються всередині каталогу репозиторію (у прикладі вище – my_pyneng_tasks).
Якщо вміст локального репозиторію однаково з віддаленим, висновок буде таким:
$ git pull
Already up-to-date.
Якщо були зміни, висновок буде приблизно таким:
$ git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 5 (delta 4), reused 5 (delta 4), pack-reused 0
Unpacking objects: 100% (5/5), done.
From ssh://github.com/natenka/my_pyneng_tasks
89c04b6..fc4c721 master -> origin/master
Updating 89c04b6..fc4c721
Fast-forward
exercises/03_data_structures/task_3_3.py | 2 ++
1 file changed, 2 insertions(+)
Додавання нових файлів або змін до існуючих
Якщо потрібно додати конкретний файл (у даному випадку – README.md), потрібно дати команду . Додавання всіх файлів поточної директорії здійснюється командою .git add README.mdgit add .
Коміт
Під час виконання комміту обов’язково треба вказати повідомлення. Краще, якщо повідомлення буде зі змістом, а не просто «update» чи подібне. Коміт робиться командою, подібною до .git commit -m "Сделаны задания 4.1-4.3"
Push на GitHub
Для завантаження всіх локальних змін на GitHub використовується команда git push:
$ git push origin master
Counting objects: 5, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 426 bytes | 0 bytes/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
To ssh://[email protected]/natenka/my_pyneng_tasks.git
fc4c721..edcf417 master -> master
Перед виконанням git push можна виконати команду – вона покаже, які зміни ви збираєтесь додавати до свого репозиторію на GitHub.git log -p origin/master..
Копіювання репозиторію з GitHub
Приклади та завдання іноді оновлюються, тому зручніше буде клонувати цей репозиторій на свою машину та періодично оновлювати його.
Для копіювання репозиторію з GitHub виконайте команду git clone:
$ git clone https://github.com/natenka/pyneng-examples-exercises
Cloning into 'pyneng-examples-exercises'...
remote: Counting objects: 1263, done.
remote: Compressing objects: 100% (504/504), done.
remote: Total 1263 (delta 735), reused 1263 (delta 735), pack-reused 0
Receiving objects: 100% (1263/1263), 267.10 KiB | 444.00 KiB/s, done.
Resolving deltas: 100% (735/735), done.
Checking connectivity... done.
Оновлення локальної копії репозиторію
При необхідності оновити локальний репозиторій, щоб синхронізувати його з версією на GitHub, потрібно виконати git pull, перебуваючи всередині створеного каталогу pyneng-examples-exercises.
Якщо оновлень не було, висновок буде таким:
$ git pull
Already up-to-date.
Якщо оновлення були, висновок буде приблизно таким:
$ git pull
remote: Counting objects: 3, 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/natenka/pyneng-examples-exercises
49e9f1b..1eb82ad master -> origin/master
Updating 49e9f1b..1eb82ad
Fast-forward
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Зверніть увагу на інформацію про те, що змінився лише файл README.md.
Перегляд змін
Якщо ви хочете подивитись, які саме зміни були внесені, можна скористатися командою git log:
$ git log -p -1
commit 98e393c27e7aae4b41878d9d979c7587bfeb24b4
Author: Наташа Самойленко <[email protected]>
Date: Fri Aug 18 17:32:07 2017 +0300
Update task_24_4.md
diff --git a/exercises/24_ansible_for_network/task_24_4.md b/exercises/24_ansible_for_network/task_24_4.md
index c4307fa..137a221 100644
--- a/exercises/24_ansible_for_network/task_24_4.md
+++ b/exercises/24_ansible_for_network/task_24_4.md
@@ -13,11 +13,12 @@
* применить ACL к интерфейсу
ACL должен быть таким:
+
ip access-list extended INET-to-LAN
permit tcp 10.0.1.0 0.0.0.255 any eq www
permit tcp 10.0.1.0 0.0.0.255 any eq 22
permit icmp any any
-
+
Проверьте работу playbook на маршрутизаторе R1.
У цій команді прапор -pвказує, що треба відобразити висновок утиліти Linux diff для змін, а не тільки повідомлення комміту. У свою чергу, -1вказує, що треба показати лише один найсвіжіший коміт.
Перегляд змін, які будуть синхронізовані
Попередній варіант git log спирається на кількість коммітів, але це не завжди зручно. До виконання команди git pull можна переглянути, які зміни були виконані з моменту останньої синхронізації.
Для цього використовується наступна команда:
$ git log -p ..origin/master
commit 4c1821030d20b3682b67caf362fd777d098d9126
Author: Наташа Самойленко <[email protected]>
Date: Mon May 29 07:53:45 2017 +0300
Update README.md
diff --git a/tools/README.md b/tools/README.md
index 2b6f380..4f8d4af 100644
--- a/tools/README.md
+++ b/tools/README.md
@@ -1 +1,4 @@
+
+Тут находятся PDF версии руководств по настройке инструментов, которые используются на курсе.
У цьому випадку зміни були лише в одному файлі. Ця команда буде дуже корисною для того, щоб подивитися, які зміни були внесені до формулювання завдань та яких саме завдань. Так буде легше орієнтуватися і розуміти, чи це стосується завдань, які ви вже зробили, і якщо стосується, то чи треба їх змінювати.
Якщо зміни були в тих завданнях, які ви ще не робили, цей висновок підкаже, які файли потрібно скопіювати з репозиторію курсу у ваш особистий репозиторій (а можливо весь розділ, якщо ви ще не робили завдання з цього розділу).
Висновок
Знання Git і GitHub — це не просто технічна навичка, а необхідність для будь-якого, хто працює з кодом або документацією. Цей розділ допоможе вам закласти міцну основу для подальшої роботи з системами контролю версій. Ви навчитеся зберігати свої проєкти у безпечному та зручному форматі, аналізувати зміни та організовано виконувати завдання. Після проходження цього матеріалу ви зможете впевнено працювати з репозиторіями, вести історію змін і не боятись втратити прогрес у своїй роботі. Це перший, але дуже важливий крок на шляху до професійної розробки.
