Обговорення

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

Поширені запитання

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

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

Додаткові налаштування Git

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

BASH

$ cat ~/.gitconfig

ВИХІД

[user]
	name = Alfredo Linguini
	email = a.linguini@ratatouille.fr
[color]
	ui = true
[core]
	editor = nano

Цей файл можна відкрити у вашому улюбленому текстовому редакторі. (Але ми радимо продовжити використання команди git config для змін у ньому, оскільки це допомагає уникнути синтаксичних помилок.)

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

BASH

$ git config --help

Зокрема, вам може знадобитися додати псевдоніми для деяких команд. Це щось на кшталт скорочень для довших команд Git. Наприклад, якщо вам набридло постійно вводити git checkout, ви можете виконати команду:

BASH

$ git config --global alias.co checkout

Тепер, якщо ми повернемося до прикладу з епізоду Досліджуючи історію, де ми виконували:

BASH

$ git checkout f22b25e guacamole.md

ми могли б тепер ввести:

BASH

$ git co f22b25e guacamole.md

Стилізація журналу 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 та ускладнює порівняння різних версій вашого проєкту.

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

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

BASH

$ mkdir recipes-nontext
$ cd recipes-nontext

Використовуйте таку програму, як Microsoft Word або LibreOffice Writer, щоб створити новий документ. Введіть той самий текст, з якого ми починали раніше:

ВИХІД

# Ingredients
# Instructions

Збережіть документ із назвою guacamole.doc у каталозі recipes-nontext. Поверніться в термінал та запустіть звичайні команди для налаштування нового репозиторію Git:

BASH

$ git init
$ git add guacamole.doc
$ git commit -m "Create a template for recipe"

Потім внесіть в guacamole.doc ті ж зміни, які ми (або Альфредо) зробили раніше в guacamole.md.

ВИХІД

# Ingredients
- avocado
- lemon
- salt
# Instructions

Збережіть зміни та закрийте текстовий процесор. Тепер подивіться, що Git думає про них:

BASH

$ git diff

ВИХІД

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

Видалення файлу

Додавання та зміна файлів - це не єдині дії, які можна виконати під час роботи над проєктом. Також може знадобитись видалити файл з репозиторію.

Створіть новий файл для невидимих чорнил:

BASH

$ echo "This is where we keep the secret sauce" > invisible.md

Тепер додайте його до репозиторію, як ви навчилися раніше:

BASH

$ git add invisible.md
$ git commit -m 'Add secret sauce'
$ git status

ВИХІД

On branch main
nothing to commit, working directory clean

Невидиме чорнило не є справжньою їжею. Це була погана ідея. Видалімо файл із проєкту та повідомимо про це Git:

BASH

$ git rm invisible.md
$ git status

ВИХІД

On branch main
Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)

   deleted:    invisible.md

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

BASH

$ git commit -m 'Remove info on Invisible ink.  It is not an edible sauce!'

Видалення файлу за допомогою 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:

BASH

$ rm secret.md
$ git status

ВИХІД

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 так само як і раніше.

BASH

$ git rm secret.md
$ git status

ВИХІД

On branch main
Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)

   deleted:    secret.md

Зміна, яка була зроблена в Unix, тепер була перенесена в зону стейджингу, де її треба зберегти у коміті.

BASH

$ git commit -m 'Remove info on invisible ink, again!'

Перейменування файлу

Іншою поширеною зміною під час роботи над проєктом є перейменування файлу.

Створіть файл для рецепта білого соусу:

BASH

$ echo "Very fun recipe to do" > whitesauce.md

Додайте його до репозиторію:

BASH

$ git add whitesauce.md
$ git commit -m 'Add white sauce recipe'

Всі ми знаємо, що білий соус має більш витончене ім’я.

Змініть назву файлу з whitesauce.md на bechamel.md за допомогою Git:

BASH

$ git mv whitesauce.md bechamel.md
$ git status

ВИХІД

On branch main
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	renamed:    whitesauce.md ->  bechamel.md

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

BASH

$ git commit -m 'Use the French name for the whitesauce'

Перейменування файлу за допомогою 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 може з’ясувати самостійно:

BASH

$ mv whitesauce.md bechamel.md
$ git status

ВИХІД

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.

Додайте ці зміни в зону стейджингу:

BASH

$ git add whitesauce.md bechamel.md
$ git status

ВИХІД

On branch main
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    whitesauce.md -> bechamel.md

Зверніть увагу, що тепер Git зрозумів, що whitesauce.md не зник - його просто перейменували.

Останнім кроком, як і раніше, є внесення змін до репозиторію:

BASH

$ git commit -m 'Use the French name for the whitesauce'

Додаткові тонкощі використання .gitignore

Для отримання додаткової документації щодо .gitignore, будь ласка, зверніться до офіційної документації git.

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

Іноді також може знадобитись шаблон ‘**’, оскільки він відповідає будь-якій кількості рівнів підкаталогів. Наприклад, шаблон **/results/plots/* вкаже git ігнорувати каталог results/plots будь-де у дереві підкаталогів.

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

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

BASH

results/data
results/plots
results/run001.log
results/run002.log

Та .gitignore, який виглядає так:

ВИХІД

*.csv

Як би ви відстежували весь вміст results/data/, включно з файлами *.csv, але ігноруючи решту results/?

Рішення

Для цього ваш .gitignore буде виглядати так:

ВИХІД

*.csv                 #  ігноруйте файли .csv
results/*             # ігноруйте файли в директорії
!results/data/        # не ігноруйте файли в results/data
!results/data/*       # не ігноруйте файли .dat в results/data