-
1. Вступ
- 1.1 Про систему контролю версій
- 1.2 Коротка історія Git
- 1.3 Основи Git
- 1.4 Git, зазвичай, тільки додає дані
- 1.5 Три стани
- 1.6 Командний рядок
- 1.7 Інсталяція Git
- 1.8 Початкове налаштування Git
- 1.9 Отримання допомоги
- 1.10 Підсумок
-
2. Основи Git
- 2.1 Створення Git-сховища
- 2.2 Запис змін до репозиторія
- 2.3 Перегляд історії комітів
- 2.4 Скасування речей
- 2.5 Взаємодія з віддаленими сховищами
- 2.6 Теґування
- 2.7 Псевдоніми Git
- 2.8 Підсумок
-
3. Галуження в git
- 3.1 Гілки у кількох словах
- 3.2 Основи галуження та зливання
- 3.3 Управління гілками
- 3.4 Процеси роботи з гілками
- 3.5 Віддалені гілки
- 3.6 Перебазовування
- 3.7 Підсумок
-
4. Git на сервері
- 4.1 Протоколи
- 4.2 Отримання Git на сервері
- 4.3 Генерація вашого публічного ключа SSH
- 4.4 Налаштування Серверу
- 4.5 Демон Git
- 4.6 Розумний HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Варіанти стороннього хостингу
- 4.10 Підсумок
-
5. Розподілений Git
-
6. GitHub
-
7. Інструменти Git
- 7.1 Вибір ревізій
- 7.2 Інтерактивне індексування
- 7.3 Ховання та чищення
- 7.4 Підписання праці
- 7.5 Пошук
- 7.6 Переписування історії
- 7.7 Усвідомлення скидання (reset)
- 7.8 Складне злиття
- 7.9 Rerere
- 7.10 Зневадження з Git
- 7.11 Підмодулі
- 7.12 Пакування
- 7.13 Заміна
- 7.14 Збереження посвідчення (credential)
- 7.15 Підсумок
-
8. Налаштування Git
-
9. Git and Other Systems
- 9.1 Git як клієнт
- 9.2 Міграція на Git
- 9.3 Підсумок
-
10. Git зсередини
- 10.1 Кухонні та парадні команди
- 10.2 Об’єкти Git
- 10.3 Посилання Git
- 10.4 Файли пакунки
- 10.5 Специфікація посилань (refspec)
- 10.6 Протоколи передачі
- 10.7 Супроводження та відновлення даних
- 10.8 Змінні середовища
- 10.9 Підсумок
-
A1. Додаток A: Git в інших середовищах
- A1.1 Графічні інтерфейси
- A1.2 Git у Visual Studio
- A1.3 Git в Eclipse
- A1.4 Git у Bash
- A1.5 Git у Zsh
- A1.6 Git у Powershell
- A1.7 Підсумок
-
A2. Додаток B: Вбудовування Git у ваші застосунки
- A2.1 Git з командного рядка
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
-
A3. Додаток C: Команди Git
- A3.1 Налаштування та конфігурація
- A3.2 Отримання та створення проектів
- A3.3 Базове збереження відбитків
- A3.4 Галуження та зливання
- A3.5 Поширення й оновлення проектів
- A3.6 Огляд та порівняння
- A3.7 Зневаджування
- A3.8 Латання (patching)
- A3.9 Електронна пошта
- A3.10 Зовнішні системи
- A3.11 Адміністрування
- A3.12 Кухонні команди
8.3 Налаштування Git - Гаки (hooks) Git
Гаки (hooks) Git
Як і багато інших Систем Керування Версіями, Git має спосіб запускати користувацькі скрипти, коли виконує якісь важливі дії. Існує дві групи таких гаків: клієнтські та серверні. Клієнтські гаки викликаються операціями на кшталт збереження коміту та зливання, у той час як серверні гаки виконуються під час мережевих операцій типу отримання надісланих змін. Ви можете використовувати ці гаки з різноманітних причин.
Встановлення гаків
Усі гаки зберігаються у піддиректорії hooks
директорії Git.
У більшості проектів, це .git/hooks
.
Під час ініціалізації нового сховища за допомогою git init
, Git заповнює директорію гаків купою прикладів скриптів, багато з яких є корисними, а також документують вхідні значення кожного скрипта.
Всі приклади написані як скрипти оболонки, з невеликими додатками на Perl, проте, будь-який правильно названий виконанний скрипт спрацює – ви можете писати їх на Ruby, Python чи на будь-якій відомій вам мові.
Якщо ви бажаєте використати скрипти, які постачає Git, то треба їх перейменувати; їхні назви закінчуються на .sample
.
Щоб увімкнути гак, покладіть файл до піддиректорії hooks
директорії .git, назвіть його відповідно (без розширення) та зробіть виконанним.
Після цього, він має викликатися.
Ми розглянемо тут найголовніші назви файлів гаків.
Клієнтські гаки
Існує багато клієнтських гаків. Ця секція розділяє їх на гаки процесу роботи з комітами, процесу роботи з поштою, та все інше.
Зауваження
|
Важливо зауважити, що клієнтські гаки не копіюються, коли ви створюєте клон сховища. Якщо ви бажаєте використовувати ці скрипти для створення примусової політики, то напевно ви бажаєте це зробити з боку сервера; дивіться приклад в Приклад політики користування виконуваної Git-ом. |
Гаки процесу роботи з комітами
Перші чотири гаки пов’язані з процесом створення комітів.
Спочатку виконується гак pre-commit
, навіть перед тим, як ви набрали повідомлення коміту.
Він використовується щоб оглянути відбиток, який ви збираєтесь зберегти в коміті, щоб побачити, чи забули ви щось, переконатись, що тести проходять, чи щоб перевірити будь-що в коді.
Вихід з цього гака не з нулем скасовує коміт, хоча щоб цього уникнути за допомогою git commit --no-verify
.
Ви можете робити такі речі, як перевірка стилю коду (виконати lint
чи аналог), перевірити пробільні символи наприкінці рядка (типовий гак саме це й робить), чи перевірити відповідність документації новим методам.
Гак prepare-commit-msg
викликається перед тим, як запускається редактор повідомлення коміту, проте після того, як типове повідомлення створено.
Це дозволяє вам редагувати типове повідомлення перед тим, як автор коміту побачить його.
Цей гак приймає декілька параметрів: шлях до файлу, який містить поточне повідомлення коміту, тип коміту та SHA-1 коміту, якщо це виправлення (amend) коміту.
Цей гак зазвичай не є дуже корисним для нормальних комітів: швидше він є доречним для комітів, для яких типове повідомлення комітів автоматично генеруються, наприклад шаблонні повідомлення комітів, коміти злиття, коміти зварювання та коміти виправлення.
Ви можете використовувати його разом з шаблоном коміту, щоб програмно додати інформацію.
Гак commit-msg
приймає один параметр — той самий шлях до тимчасового файлу, який містить повідомлення коміту, яке написав розробник.
Якщо скрипт виходить не з нулем, то Git скасовує коміт, отже ви можете використати його, щоб перевіряти стан або повідомлення коміту перед тим, як дозволити йти далі.
В останній секції цього розділу, ми продемонструємо використання цього гаку для перевірки відповідності повідомлення коміту необхідному взірцю.
Після того, як весь процес коміту завершено, виконується гак post-commit
.
Він не приймає жодних параметрів, проте ви легко можете отримати останній коміт за допомогою git log -1 HEAD
.
Зазвичай, цей скрипт використовують для звісток чи чогось схожого.
Гаки процесу роботи з поштою
Ви можете налаштувати три клієнтські гаки для процесу роботи з поштою.
Вони всі викликаються командою git am
, отже якщо ви її не використовуєте в роботі, ви можете спокійнісінько пропустити цей підрозділ.
Якщо ви отримуєте латки через пошту, та вони були підготовлені командою git format-patch
, то якісь з них можуть бути для вас корисними.
Спершу виконується гак applypatch-msg
.
Він приймає один аргумент: імʼя тимчасового файлу, що містить пропоноване повідомлення коміту.
Git відкидає латку, якщо скрипт виходить не з нулем.
Ви можете використати його, щоб переконатися, що повідомлення коміту написано належним чином, чи для нормалізації повідомлення — скрипт може одразу відредагувати його.
Наступний гак — pre-applypatch
— викликається під час застосування латок командою git am
.
Це може збити з пантелику, проте він виконується після того, як латку застосовано, проте перед тим, як створюється коміт. Отже, його можна використати для перевірки відбитку перед додаванням коміту.
Ви можете виконати тести, чи іншим чином перевірити робоче дерево в цьому скрипті.
Якщо чогось бракує, чи тести не пройшли, вихід з ненульовим значенням припиняє скрипт git am
без створення коміту з латкою.
Останній гак, який виконується під час праці git am
, називається post-applypatch
, та викликається після створення коміту.
Його можна використати для сповіщення групи чи автора, в якого ви взяли латку, про те, що ви зробили.
Ви не можете зупинити процес застосування латки в цьому скрипті.
Інші клієнтські гаки
Гак pre-rebase
виконується перед кожним перебазуванням, та може припинити процес, якщо поверне не нуль.
Ви можете його використати, щоб заборонити перебазування будь-яких вже надісланих комітів.
Приклад гаку pre-rebase
, який встановлює Git, робить це, хоч і деякими припущеннями, яки можуть бути неправильними для вашого процесу роботи.
Гак post-rewrite
виконується командами, які замінюють коміти — такими як git commit --amend
та git rebase
(хоча git filter-branch
його не викликає).
Його єдиним аргументом є команда, яка спричинила переписування, а список переписувань надається через stdin
.
Цей гак має багато спільних використань з гаками post-checkout
та post-merge
.
Після успішного виконання git checkout
, викликається гак post-checkout
; його можна використати, щоб правильно налаштувати вашу робочу директорію для середовища проекту.
Це може означати пересування великих двійкових файлів, які не перебувають під контролем версій, автоматична генерація документацій, чи щось схоже на ці приклади.
Гак post-merge
викликається після успішної команди merge
.
Його можна використати для відновлення даних у робочій директорії, що їх не може супроводжувати Git, наприклад дані про права доступу.
Цей гак може також перевіряти присутність файлів, якими Git не керує, проте які мають бути скопійовані під час змін робочого дерева.
Гак pre-push
виконується під час git push
, після того, як віддаленні посилання оновлено, проте перед тим, як якісь обʼєкти надсилаються.
Він отримує імʼя та розташування віддаленого сховища як параметри, та список посилань, які будуть оновлені, через stdin
.
Ви можете його використати для перевірки набору оновлень посилань перед тим, як станеться надсилання змін (вихід з не нулем скасує надсилання)
Git іноді збирає сміття під час своєї звичайної роботи, тоді він викликає git gc --auto
.
Гак pre-auto-gc
викликається саме перед збиранням сміття, та може використовуватись для того, щоб повідомити вам про це, або скасувати збір, якщо зараз не час для цього.
Серверні гаки
На додаток до клієнтських гаків, ви можете використати декілька важливих серверних гаків, як системний адміністратор, щоб зробити майже будь-яку політику вашого проекту примусовою. Ці скрипти виконуються перед та після надсиланням змін до сервена. Гаки, які викликаються перед, можуть вийте не з нулем у будь-який час, щоб відхилити надсилання, а також вивести повідомлення помилки клієнту; ви можете зробити політику надсилань змін такою складною, яка вам потрібна.
pre-receive
Під час обробки надсилання змін клієнтом спочатку викликається pre-preceive
.
Він отримує список посилань, які надсилаються, через stdin; якщо він виходить з не нулем, жодне з них не приймається.
Ви можете використати цей гак для того, щоб, наприклад, переконатися, що всі оновлені посилання є перемотуваннями вперед, або щоб здійснити перевірку доступу для всіх посилань та файів, які в них відредагували.
update
Скрипт update
є дуже схожим на скрипт pre-receive
, окрім того, що він виконується окремо для кожної гілки, яка намагається оновити автор змін.
Якщо автор намагається надіслати декілька гілок, pre-receive
виконується лише один раз, у той час як update виконується для кожної надісланої гілки.
Замість того, щоб читати з stdin, цей скрипт приймає три аргументи: імʼя посилання (гілки), SHA-1 того, на що вказувало це посилання до надсилання, та SHA-1 того, що намагається надіслати користувач.
Якщо скрипт update вийде з не улем, лише це посилання відхиляється; інші посилання все одно можуть бути оновлені.
post-receive
Гак post-receive
виконується після того, як весь процес завершено, та може бути використаним для оновлення інших сервісів або сповіщення користувачів.
Він приймає такі самі дані з stdin, як і гак pre-receive
.
Приклади включають надсилання листа до розсилки, сповіщення сервера постійної інтеграції, або оновлення системи слідкування за завданнями – ви можете навіть проаналізувати повідомлення комітів, щоб побачити, можливо, якісь завдання треба відкрити, змінити або закрити.
Цей скрипт не може зупинити процес надсилання, проте клієнт не відключається, доки він не завершиться, тому будьте обережні з тим, щоб намагатись зробити щось, що потребує багато часу.