Обговорення
Останнє оновлення 2025-02-15 | Редагувати цю сторінку
Поширені запитання
Зазвичай, у людей виникають питання щодо Git, що виходять за рамки основного матеріалу. Студентам, які завершили решту уроків, може бути корисно розглянути наступні теми.
Зауважте, що оскільки цей матеріал не є обов’язковим для базового використання Git, він не буде розглядатися інструктором.
Додаткові налаштування Git
Під час Налаштування Git, ми
використовували git config --global
, щоб встановити деякі
параметри за замовчуванням для Git. Отже, ці параметри конфігурації
зберігаються у вашому домашньому каталогу у звичайному текстовому файлі
під назвою .gitconfig
.
ВИХІД
[user]
name = Alfredo Linguini
email = a.linguini@ratatouille.fr
[color]
ui = true
[core]
editor = nano
Цей файл можна відкрити у вашому улюбленому текстовому редакторі.
(Але ми радимо продовжити використання команди git config
для змін у ньому, оскільки це допомагає уникнути синтаксичних
помилок.)
Зрештою, ви забажаєте почати налаштовувати поведінку Git, щоб зробити
її більш зручною. Це можна зробити, додавши більше записів до вашого
.gitconfig
. Наявні параметри описані в документації:
Зокрема, вам може знадобитися додати псевдоніми для деяких команд. Це
щось на кшталт скорочень для довших команд Git. Наприклад, якщо вам
набридло постійно вводити git checkout
, ви можете виконати
команду:
Тепер, якщо ми повернемося до прикладу з епізоду Досліджуючи історію, де ми виконували:
ми могли б тепер ввести:
Стилізація журналу Git
Вигляд журналу є чудовим кандидатом для налаштування. Типовий журнал є досить детальним, але йому бракує графічних підказок, таких як вказівок на те, які коміти були зроблені локально, а які були отримані з віддалених репозиторіїв.
Ви можете використовувати git log --help
та
git config --help
, щоб знайти різні способи для змін
вигляду журналу. Спробуйте наступні команди та подивіться, який ефект
вони матимуть:
BASH
$ git config --global alias.lg "log --graph"
$ git config --global log.abbrevCommit true
$ git config --global format.pretty oneline
$ git lg
Якщо вам не подобаються ці ефекти, ви можете скасувати їх за допомогою:
BASH
$ git config --global --unset alias.lg
$ git config --global --unset log.abbrevCommit
$ git config --global --unset format.pretty
Скасування змін конфігурації Git
Ви можете використовувати опцію --unset
для видалення
небажаних параметрів з .gitconfig
. Ще один спосіб скасувати
зміни — зберегти ваш .gitconfig
за допомогою Git.
Щоб отримати поради по те, що ще ви можете налаштувати, перейдіть до GitHub і у вікні пошуку введіть “gitconfig”. Ви знайдете сотні репозиторіїв, у яких люди зберегли свої власні файли конфігурації Git. Відсортуйте їх за кількістю зірок і розгляньте кілька найкращих. Якщо ви знайдете ті, які вам подобаються, будь ласка, переконайтеся, що вони є ліцензійними з відкритим вихідним кодом, перш ніж клонувати їх.
Нетекстові файли
Пригадайте, коли ми обговорювали Конфлікти було завдання, яке запитувало: “Що робить Git коли виникає конфлікт у зображенні або якомусь іншому нетекстовому файлі, який зберігається у системі контролю версій?”
Тепер ми розглянемо це питання більш детально.
Багато людей бажають відстежувати версії нетекстових файлів, таких як зображення, PDF-файли та документи Microsoft Office або LibreOffice. Насправді Git може обробляти ці типи файлів (які потрапляють у категорію “бінарних” файлів). Однак те, що це можна зробити, не означає, що це потрібно зробити.
Значна частина “магії” Git походить від його здатності порівнювати файли рядок за рядком (тобто, отримувати “diffs”). Загалом це легко для вихідного коду програм та розміченого тексту. Для нетекстових файлів, diff зазвичай може виявляти лише те, що файли змінилися але не можуть сказати, як і де.
Це по-різному впливає на продуктивність Git та ускладнює порівняння різних версій вашого проєкту.
Щоб показати різницю ми роздивимося базовий приклад: що б сталося, якби Альфредо спробував використати файл, створений у текстовому процесорі замість звичайного неформатованого тексту.
Створіть новий каталог і перейдіть до нього:
Використовуйте таку програму, як Microsoft Word або LibreOffice Writer, щоб створити новий документ. Введіть той самий текст, з якого ми починали раніше:
ВИХІД
# Ingredients
# Instructions
Збережіть документ із назвою guacamole.doc
у каталозі
recipes-nontext
. Поверніться в термінал та запустіть
звичайні команди для налаштування нового репозиторію Git:
Потім внесіть в guacamole.doc
ті ж зміни, які ми (або
Альфредо) зробили раніше в guacamole.md
.
ВИХІД
# Ingredients
- avocado
- lemon
- salt
# Instructions
Збережіть зміни та закрийте текстовий процесор. Тепер подивіться, що Git думає про них:
ВИХІД
diff --git a/guacamole.doc b/guacamole.doc
index 53a66fd..6e988e9 100644
Binary files a/guacamole.doc and b/guacamole.doc differ
Порівняйте це з попереднім git diff
, який ми бачили коли
використовували текстові файли:
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index df0654a..315bf3a 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -1,2 +1,5 @@
# Ingredients
+- avocado
+- lemon
+- salt
# Instructions
Зверніть увагу, що звичайні текстові файли дають набагато інформативніший diff. Ви можете побачити, які саме лінії змінилися і які були зміни.
Неінформативний git diff
не є єдиним наслідком
використання Git на бінарних файлах. Однак більшість інших питань
зводяться до того, чи можливий інформативний diff взагалі.
Це не означає, що ви ніколи не повинні використовувати Git на бінарних файлах. Суть полягає в тому, що якщо ви маєте бінарний файл, який не змінюється часто (а навіть коли змінюється, то злиття дрібних відмінностей між його різними версіями не потрібне), то у такому випадку його цілком можливо зберігати у репозиторії.
Ми вже бачили, що згідно з цим правилом звіт, написаний у текстовому
процесорі, неефективно зберігати у Git. Прикладом, який проходить
перевірку, є логотип вашої організації або проєкту. Попри те, що логотип
зберігається у бінарному форматі, такому як jpg
або
png
, ви можете розраховувати, що він залишиться відносно
незмінним протягом усього терміну життя вашого репозиторію. У тих
рідкісних випадках, коли брендинг змінюється, ви, ймовірно, просто
захочете повністю замінити логотип, а не зливати невеликі
відмінності.
Видалення файлу
Додавання та зміна файлів - це не єдині дії, які можна виконати під час роботи над проєктом. Також може знадобитись видалити файл з репозиторію.
Створіть новий файл для невидимих чорнил:
Тепер додайте його до репозиторію, як ви навчилися раніше:
ВИХІД
On branch main
nothing to commit, working directory clean
Невидиме чорнило не є справжньою їжею. Це була погана ідея. Видалімо файл із проєкту та повідомимо про це Git:
ВИХІД
On branch main
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: invisible.md
Зміна була перенесена у зону стейджингу. Тепер збережіть ваш коміт та видаліть файл із самого репозиторію. Зауважте, що файл буде вилучено у новому коміті. Попередній коміт все одно матиме файл, якщо ви хочете отримати цей конкретний коміт.
Видалення файлу за допомогою Unix
Іноді ми можемо забути видалити файл через Git. Якщо ви видалили файл
за допомогою команди Unix rm
замість git rm
,
не хвилюйтеся — Git досить розумний і помітить відсутній файл.
Відтворімо файл і зробимо його коміт знову.
BASH
$ echo "This is another way to make invisible ink" > secret.md
$ git add secret.md
$ git commit -m 'Add invisible ink again'
Тепер видалимо файл за допомогою команди rm
:
ВИХІД
On branch main
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: secret.md
no changes added to commit (use "git add" and/or "git commit -a")
Дивіться, як Git помітив, що файл secret.md
був
видалений з диска. Наступним кроком є “стейджинг” видалення файлу з
репозиторію. Це робиться за допомогою команди git rm
так
само як і раніше.
ВИХІД
On branch main
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
deleted: secret.md
Зміна, яка була зроблена в Unix, тепер була перенесена в зону стейджингу, де її треба зберегти у коміті.
Перейменування файлу
Іншою поширеною зміною під час роботи над проєктом є перейменування файлу.
Створіть файл для рецепта білого соусу:
Додайте його до репозиторію:
Всі ми знаємо, що білий соус має більш витончене ім’я.
Змініть назву файлу з whitesauce.md
на
bechamel.md
за допомогою Git:
ВИХІД
On branch main
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: whitesauce.md -> bechamel.md
Останнім кроком є внесення змін до репозиторію:
Перейменування файлу за допомогою Unix
Якщо ви замість Git команди git mv
використовували Unix
mv
, то у вас буде трохи більше роботи, але Git все одно
зможе з цим впоратися. Спробуймо ще раз перейменувати файл, але цього
разу за допомогою команди Unix mv
. По-перше, нам потрібно
відтворити файл whitesauce.md
:
BASH
$ echo "Very fun recipe to do" > whitesauce.md
$ git add whitesauce.md
$ git commit -m 'Add white sauce recipe'
Тепер перейменуємо файл і подивимося, що Git може з’ясувати самостійно:
ВИХІД
On branch main
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: whitesauce.md
Untracked files:
(use "git add <file>..." to include in what will be committed)
bechamel.md
no changes added to commit (use "git add" and/or "git commit -a")
Git помітив, що файл whitesauce.md
зник з файлової
системи та з’явився новий файл bechamel.md
.
Додайте ці зміни в зону стейджингу:
ВИХІД
On branch main
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: whitesauce.md -> bechamel.md
Зверніть увагу, що тепер Git зрозумів, що whitesauce.md
не зник - його просто перейменували.
Останнім кроком, як і раніше, є внесення змін до репозиторію:
Додаткові тонкощі використання .gitignore
Для отримання додаткової документації щодо .gitignore, будь ласка, зверніться до офіційної документації git.
У вправі на ігнорування, слухачам було запропоновано два варіанти ігнорування вкладених файлів. Залежно від організації вашого репозиторію, одне рішення може підійти вам ліпше ніж інше. Майте на увазі, що методи Git для навігації в структурі каталогів проєкту іноді може бути важко зрозуміти.
Іноді також може знадобитись шаблон ‘**’, оскільки він відповідає
будь-якій кількості рівнів підкаталогів. Наприклад, шаблон
**/results/plots/*
вкаже git ігнорувати каталог
results/plots
будь-де у дереві підкаталогів.
Ігнорування вкладених файлів: завдання
Для цього ваш .gitignore буде виглядати так:
ВИХІД
*.csv # ігноруйте файли .csv
results/* # ігноруйте файли в директорії
!results/data/ # не ігноруйте файли в results/data
!results/data/* # не ігноруйте файли .dat в results/data