Пошук уроків, статей та іншого контенту
Визначте розмір, частоту й структуру комітів, щоб історія змін залишалася зрозумілою та придатною для підтримки.
Коміт — це зафіксований стан проєкту в Git. Він має показувати одну логічну зміну: виправлення помилки, додавання функції або оновлення документації.
Добра стратегія комітів допомагає:
швидко зрозуміти історію проєкту;
знайти коміт, у якому з’явилася проблема;
безпечно переглядати та скасовувати окремі зміни;
простіше перевіряти код під час code review;
не змішувати різні завдання в одній зміні.
Історія комітів має розповідати, що і навіщо змінювалося, а не лише показувати випадкові етапи роботи.
Коміт повинен бути достатньо малим, щоб його можна було легко зрозуміти, але достатньо повним, щоб описувати завершену логічну зміну.
Наприклад, додавання перевірки електронної пошти може містити:
зміну функції валідації;
додавання тесту;
оновлення повідомлення про помилку.
Це одна логічна зміна, тому її доречно оформити одним комітом.
Поганий приклад:
Додано авторизацію, перероблено стилі, оновлено залежності,
виправлено помилку в меню та змінено документаціюУ такому коміті змішані кілька незалежних завдань. Його складно перевіряти, а окрему зміну складно скасувати.
Краще розділити роботу:
Додано перевірку форми входу
Оновлено стилі навігації
Виправлено відкриття мобільного меню
Оновлено документацію запускуНе кожен проміжний крок потребує окремого коміту. Наприклад, такі коміти зазвичай не дають корисної інформації:
Проба
Ще зміни
Трохи виправив
Тепер точноЯкщо зміни є частинами однієї завершеної задачі, їх краще об’єднати в один зрозумілий коміт.
Атомарний коміт містить одну логічну зміну, яку можна розглядати як єдине ціле.
Перед створенням коміту поставте собі запитання:
Чи описує цей коміт одну задачу?
Чи можна зрозуміти його зміни без пояснень поза комітом?
Чи можна окремо перевірити або скасувати цю зміну?
Чи не потрапили сюди тимчасові файли або зміни з іншої задачі?
Якщо відповідь негативна, варто переглянути склад коміту.
Під час роботи над задачею часто змінюється кілька файлів. Це не означає, що кожен файл потрібно фіксувати окремим комітом. Важливо розділяти логічні зміни, а не просто файли.
Наприклад, у вас є такі зміни:
виправлено помилку у функції;
додано тест для цієї функції;
змінено форматування іншого файлу.
Перші дві зміни належать до однієї задачі, а форматування — до іншої. Тому доречно створити два коміти:
Виправлено обробку порожнього імені
Додано тест для порожнього іменіабо, якщо тест є невіддільною частиною виправлення:
Виправлено обробку порожнього імені та додано тестФорматування краще зафіксувати окремо.
Команда git add . додає до індексу всі зміни з поточної директорії. Вона зручна, але може випадково включити непов’язані файли.
Щоб уважніше сформувати коміт, можна:
додати конкретний файл;
додати кілька конкретних файлів;
додати окремі частини файлу за допомогою git add -p.
Приклад:
git add src/validateEmail.js tests/validateEmail.test.js
git commit -m "Додано перевірку електронної пошти"У цьому випадку до коміту потраплять лише вказані файли.
Команда git diff --staged показує зміни, які вже додано до майбутнього коміту:
git diff --stagedПереглядайте цей diff перед комітом. Так можна виявити:
випадкові зміни;
налагоджувальні повідомлення;
секретні дані;
незавершений код;
файли, які не стосуються задачі.
Коміт варто створювати після завершення логічного кроку, а не через фіксований проміжок часу.
Підходящі моменти:
функція реалізована;
помилку виправлено;
тест додано;
документацію оновлено;
конфігурацію змінено як окрему завершену задачу.
Не обов’язково чекати завершення всього великого завдання. Якщо завдання складається з кількох незалежних частин, кожну завершену частину можна зафіксувати окремо.
Водночас не слід створювати коміт після кожного введеного рядка. Коміт має бути зрозумілим станом проєкту.
Повідомлення має коротко пояснювати, що зроблено. Для цього використовуйте дієслово в одному стилі в усій команді.
Приклади:
Додано перевірку форми входу
Виправлено помилку розрахунку суми
Оновлено інструкцію запуску
Видалено невикористаний компонентУникайте повідомлень, які не пояснюють зміст змін:
Зміни
Виправлення
Update
Work
FinalДля невеликого проєкту достатньо одного рядка:
git commit -m "Додано перевірку форми входу"Повідомлення краще робити коротким і конкретним. Воно має бути зрозумілим без перегляду diff.
Для складнішої зміни можна додати пояснення:
git commit -m "Виправлено обробку помилки під час входу" \
-m "Користувач тепер отримує повідомлення, якщо сервер недоступний."Перший рядок стисло описує зміну, а другий пояснює важливу деталь або причину.
Нижче наведено приклад створення двох логічних комітів у навчальному репозиторії:
# Створюємо новий каталог проєкту
mkdir commit-example
cd commit-example
git init
# Створюємо початковий файл
printf "# Мій проєкт\n" > README.md
git add README.md
git commit -m "Додано опис проєкту"
# Додаємо окрему функцію
mkdir -p src
cat > src/greet.js <<'EOF'
function greet(name) {
return `Привіт, ${name}!`;
}
module.exports = greet;
EOF
git add src/greet.js
git commit -m "Додано функцію привітання"
# Переглядаємо коротку історію комітів
git log --onelineОчікувано історія міститиме два зрозумілі коміти:
a1b2c3d Додано функцію привітання
e4f5g6h Додано опис проєктуІдентифікатори комітів відрізнятимуться у вашому репозиторії.
Припустімо, ви змінили файл із кодом і одночасно оновили документацію. Ці зміни можна розділити:
git status
# Додаємо лише зміни в коді
git add src/greet.js
git diff --staged
git commit -m "Оновлено функцію привітання"
# Додаємо документацію окремим комітом
git add README.md
git diff --staged
git commit -m "Оновлено опис використання"У результаті історія краще відображає роботу, а кожну зміну можна переглянути окремо.
Не потрібно створювати публічний коміт із незавершеним або непрацюючим кодом лише для того, щоб «зберегти прогрес». Така історія ускладнює підтримку.
Якщо роботу потрібно тимчасово зберегти, але вона ще не готова для нормального коміту, використовуйте відповідний локальний механізм Git, а завершений коміт створіть після того, як зміни матимуть зрозумілий стан.
У готовій історії бажано уникати комітів на кшталт:
Код поки не працює
Тимчасово
Спроба виправленняПеред кожним комітом виконайте коротку перевірку:
Перегляньте стан репозиторію:
git statusПерегляньте всі незбережені зміни:
git diffДодайте до індексу лише потрібні файли:
git add path/to/fileПерегляньте саме підготовлені зміни:
git diff --stagedСтворіть коміт із конкретним повідомленням:
git commit -m "Опис логічної зміни"За можливості запустіть тести або іншу перевірку проєкту.
Такий порядок зменшує ризик випадково закомітити зайві або некоректні зміни.
Коміт на кшталт Реалізовано весь проєкт приховує багато різних змін. Розділяйте завершені логічні частини.
Масове форматування разом із виправленням помилки ускладнює перегляд diff. Форматування краще фіксувати окремо.
git add . без перевіркиКоманда може додати тимчасові файли, локальні налаштування або зміни з іншої задачі. Після неї обов’язково перевіряйте git diff --staged.
Повідомлення fix або changes не допомагають зрозуміти історію. Називайте конкретну зміну.
Надто велика кількість комітів із проміжними станами створює шум. Фіксуйте завершені логічні кроки.
Паролі, ключі доступу та приватні налаштування не повинні потрапляти до коміту. Перевіряйте підготовлені файли перед виконанням git commit.
Коміт має містити одну логічну, бажано завершену зміну.
Розділяйте незалежні функції, виправлення, документацію та форматування.
Не створюйте коміт після кожного рядка й не об’єднуйте всю роботу в один величезний коміт.
Використовуйте git add вибірково, а перед комітом перевіряйте git diff --staged.
Пишіть короткі конкретні повідомлення, які пояснюють зміст зміни.
Хороша історія комітів допомагає читати, перевіряти та підтримувати проєкт.