Commit

Практична порада: окремий refactoring commit — це подарунок reviewer-у й майбутньому debugging-у.; * завершена логічна частина роботи;

tests проходять;
зміна має сенс окремо;
потрібно зберегти прогрес;
зміна готова для review;
завершено bug fix;
додано documentation;
зроблено refactoring;
оновлено config;
створено migration.; Commit каже: “ось зміна забезпечується через Саме з цієї причини Git більше схожий не на кнопку “Save”, а на машину часу; додатково реалізовано ось хто її зробив, ось коли, ось повідомлення, ось її місце в історії”.; * Commit history має змогу бути технічною документацією, якщо її писали уважно.;== Commit і Remote Repository ==

Головна думка: commit — це не без ускладнень “зберегти код”.; refactor: extract invoice calculator </syntaxhighlight> Команда для перегляду: feat: add user profile route

Поширені типи:

Commit у Git — це не без ускладнень “збереження файлів”.;

</syntaxhighlight> </syntaxhighlight>

Приклад:

Приклад хорошого atomic commit:

</syntaxhighlight> Практична роль: repository — це місце, де живе вся commit history проєкту.;== Revert Commit ==

Commit і CI/CD

переважні аспекти revert:

Commit у Open Source

Небезпека: поганий commit має змогу не тільки зламати код, а й ускладнити розуміння історії на роки вперед.; Практична роль: tests у commit показують, що зміна не тільки написана, а й перевірена.;</syntaxhighlight>

git log Add email validation to signup form

Практична роль: parent commits дозволяють Git будувати історію й розуміти, як зміни пов’язані між собою.; a1b2c3d4e5f678901234567890abcdef12345678

Tag часто ставлять на commit, який відповідає release.;</syntaxhighlight>

{{SEO

Створити: Краще: Git binary-searches history

Підказка: якщо commit message без зайвих зусиль перетворити на пункт changelog або пояснення в PR, він зазвичай написаний добре.; Git commit — об’єкт Git, який фіксує snapshot проєкту й metadata.; Commit history має змогу використовуватися для створення changelog.;

`.gitignore` сприяє не додавати зайві файли в commits.; * Документація Git щодо commits, staging area, commit objects, branches, merge, rebase, revert і reset.;

Практична роль: commit стає не лише записом в історії, а й тригером автоматичної перевірки якості.; Це простий спосіб помітити випадкові debug logs, secrets або непотрібні зміни.;== Amend Commit ==

Parent Commit

git status

Ідея:

Pull отримує changes з remote repository і інтегрує їх у локальний branch.; До secrets належать:

Commit у Documentation Projects

Commit містить:

git rebase -i HEAD~3

Hotfix

істотно: перед commit варто подивитися diff.; Команди: </syntaxhighlight> У Git commit зберігає стан файлів на певний момент, автора, дату, повідомлення, посилання на попередній commit і унікальний ідентифікатор — commit hash.; Приклад:

істотно: squash зручний, але не треба зливати в один commit unrelated changes.; У Добрий commit часто передбачено tests для зміни.;

== git bisect ==
'''Перевага:''' commits дозволяють не без ускладнень бачити фінальний код, а розуміти шлях, яким команда до нього прийшла.;== Ризики Commit ==
'''Atomic commit''' — commit, який містить одну логічну зміну.; * Merge commit має змогу мати більше одного parent.; git tag v1.4.0 a1b2c3d

'''Практична роль:''' cherry-pick надає можливість взяти одну “вишеньку” з історії й перенести її в інше місце.; '''Repository''' зберігає commits, branches, tags і metadata.; * linting;
* tests;
* build;
* security scan;
* type checking;
* preview deployment;
* artifact creation;
* Docker image build;
* deployment to staging;
* release automation.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

fix: correct invoice rounding
У conventional commits breaking change часто позначають так:
== Breaking Change у Commit ==

У monorepo один commit має змогу торкатися кількох packages або applications.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* зміни в одному файлі;
* зміни в багатьох файлах;
* додавання файлу;
* видалення файлу;
* перейменування;
* refactoring;
* bug fix;
* feature;
* test update;
* documentation update;
* configuration change;
* migration script.;</div>
== Commit і Pull Request ==
Commits можуть створювати проблеми, якщо їх робити недбало.;<syntaxhighlight lang="text">

'''істотно:''' перед створенням нового branch або commit у спільному branch корисно підтягнути актуальні зміни.; '''Практична роль:''' documentation commit фіксує зміни знань так само, як code commit фіксує зміни поведінки.; * Revert не видаляє commit із history, а створює новий commit зі зворотною зміною.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Pull request зазвичай складається з одного або кількох commits.; Commit має змогу містити:

знати, який код у production;
debug-ити bug;
робити rollback;
відтворити build;
провести audit;
знайти diff між releases.;

Commit History

Краще:

Корисні інструменти:

secrets у history;
великі незрозумілі commits;
погані commit messages;
unrelated changes в одному commit;
переписана shared history;
force push без узгодження;
commits без tests;
broken main;
noisy history;
autogenerated files без потреби;
binary files у Git;
merge conflicts;
lost local commits без push;
неправильний author.;

істотно пам’ятати, що великі datasets і model artifacts зазвичай не варто зберігати прямо в Git commits.; * Найкращі commits часто нудні: маленькі, зрозумілі, перевірені й добре названі.;

Короткий варіант:

Large commit — commit із великою кількістю різних змін.;

* `git diff` показує unstaged changes;
* `git diff --staged` показує зміни, які вже потраплять у commit.; * знайти, коли з’явилась зміна;
* зрозуміти еволюція feature;
* відстежити bug;
* знайти автора;
* підготувати release notes;
* зробити revert;
* провести audit.; Коли доречний

Приклад слабкого повідомлення:

Файли можуть бути:
'''Практична роль:''' `.gitignore` зменшує шанс випадково закомітити сміття, secrets або локальні файли.; git commit --amend

'''істотно:''' release має бути traceable до конкретного commit або tag.; Потім Git пропонує commits для перевірки, поки не знайде перший bad commit.; Приклад:

<syntaxhighlight lang="bash">

== Коли краще не робити Commit ==

Поганий приклад:
fix: handle empty cart during checkout
Приклад:

Working Tree

Розробник виносить розрахунок ціни в окремий class без зміни поведінки:

fix

git commit -m "Add profile update validation"

git diff переглянуто?;

Приклад:

!; Можна:

Звичайний commit має одного parent:

== Commit Message ==

Release process має змогу включати:
'''Помилка:''' commit message типу `stuff`, `update`, `fix2` або `final` майже нічого не каже майбутній команді.; '''Signed commit''' — commit із cryptographic signature, яка підтверджує автора або джерело commit.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
== Staging Area ==
== Commit і Branch ==

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">

Tokens were accepted for 48 hours because the expiration check used </syntaxhighlight>

`git bisect` сприяє знайти commit, у якому з’явився bug.; D - Add form Commit message — текстове пояснення, що змінив commit і навіщо.; Приклад: .env

Commit history — послідовність commits у repository.; git add file.txt

Conventional Commits

Commit і Formatting

Commit і Tags

</syntaxhighlight> Приклад:

істотно: commit message має пояснювати не лише “що”, а іноді й “чому”.;

втрачається детальна commit history branch;
складніше побачити проміжні кроки;
погано, якщо commits були логічно різними.; Fix password reset token expiration

як ілюстрація:
<syntaxhighlight lang="text">

застосовується для:

* перевіряє поточний стан;
* переглядає зміни;
* додає потрібний файл;
* перевіряє staged diff;
* створює commit;
* відправляє commit у remote.;

Commit і Debugging

git diff

feat!: change authentication token format

Приклад:

Cherry-Pick Commit

Висновок

легше review;
легше revert;
зрозуміліша історичний розвиток;
простіше debug;
краще для bisect;
менше ризику змішаних змін.;== Приклади сценаріїв використання ==

git push git push

Цікаві факти про Commit

Практична роль: push робить commits доступними іншим людям і системам.;

Amend надає можливість змінити останній commit.;</syntaxhighlight>

git reset --mixed HEAD~1

Проста різниця: commit — це точка в історії, tag — це важлива мітка на цій точці.;

Commits можуть змінювати не тільки код, а й документацію.;

git bisect bad

This adds a guard for empty carts and returns the user to the cart page.;

{| class="wikitable"

</div>

* короткий summary;
* пояснено причину;
* пояснено fix;
* згадано test;
* майбутній читач зрозуміє контекст.; * Commit hash часто потрапляє в build metadata, logs і release notes.;</div>
<syntaxhighlight lang="text">
A---B---C

!;<syntaxhighlight lang="text">
'''Merge commit''' створюється, коли Git об’єднує дві гілки й фіксує це як окремий commit.; * Поганий commit message має змогу здаватися дрібницею сьогодні, але дуже дратувати через пів року.;== Commit у Infrastructure as Code ==
== Commit і Secrets ==

Initial Commit

Terraform changes;
Kubernetes manifests;
CI/CD config;
cloud IAM policies;
network rules;
monitoring alerts;
deployment scripts.;

git commit -m "Add user profile page"

Головна перевага: commit робить зміну коду конкретною, поясненою й відстежуваною.;

Цей workflow: Tests додані або оновлені, якщо потрібно?; Staging area надає можливість:

refactor: simplify payment calculation Найлюдяніший факт: commit — це спосіб не покладатися на пам’ять.;</syntaxhighlight>

Рекомендовано:

історичний розвиток змін;
traceability;
можливість rollback;
командна робота;
code review;
CI/CD integration;
debugging;
release management;
audit;
documentation of intent;
супровід branches;
порівняння versions;
пошук regression;
прив’язка build до source code.; Release зазвичай складається з одного або кількох commits, які потрапили в стабільну версію.; * Зміна commit message через amend змінює commit hash.; docs: remove outdated deployment command

</syntaxhighlight> git push -u origin feature/login refactor: extract invoice calculator |- | Revert | Створює новий commit, який скасовує зміну | Shared branches, main, production history |- | Reset | Переміщує branch pointer і має змогу прибрати commits | Локальна історичний розвиток, cleanup перед push |}

Longer explanation if needed.;

A---B---C------M main

</div>
F - Update tests

Initial commit

Refactoring commits краще відокремлювати від behavior changes.; test: add checkout tests Empty commit — commit без змін у файлах.; created_at instead of expires_at.; * README updates;

API docs;
changelog;
architecture notes;
tutorials;
configuration guide;
migration guide;
comments;
examples.;

Приклад:

</div>

fix: correct invoice total rounding

feat: add profile edit form

* одна логічна зміна;
* зрозуміле message;
* немає випадкових файлів;
* tests поруч зі зміною;
* refactoring окремо від behavior change;
* formatting окремо від logic.; Часто використовують коротку форму:

== Коли варто робити Commit ==
After squash:
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

</div>
'''Небезпека:''' найпростіша помилка — зробити commit не в з цієї причини branch.; * поточний branch;
* staged changes;
* unstaged changes;
* untracked files;
* чи branch випереджає remote;
* чи є собою conflicts;
* підказки щодо наступних команд.;<syntaxhighlight lang="bash">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
git cherry-pick a1b2c3d

Interactive rebase надає можливість редагувати локальну історію commits.;

Різниця:

</div>

Локальні tests проходять?; Тут commits `D` і `E` знаходяться на branch `feature/login`.; fetch + merge

</div>

У Git commits утворюють graph, а не без ускладнень лінійний список.; це зафіксований знімок змін у системі контролю версій виступає ключовою рисою '''Commit''' або '''коміт'''.;</div>
git diff --staged

git status

* `feat`;
* `fix`;
* `docs`;
* `style`;
* `refactor`;
* `test`;
* `build`;
* `ci`;
* `chore`;
* `perf`.; Команда має знати:
against expires_at and adds a regression test.;</div>
test: add profile update tests
<syntaxhighlight lang="text">
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

історичний розвиток сприяє:
'''Критично:''' infrastructure commit має змогу створити, змінити або видалити реальні ресурси.; * показує факт об’єднання branches;
* зберігає topology історії;
* групує changes feature branch;
* сприяє зрозуміти, коли feature потрапила в main.; * unmodified;
* modified;
* staged;
* untracked;
* deleted;
* renamed.;== Commit і Refactoring ==

== Commit у Data і ML-проєктах ==

new features;
bug fixes;
breaking changes;
performance improvements;
security fixes;
dependency updates;
migration notes.; * зрозуміти історію;
швидше review-ити код;
debug-ити regression;
писати changelog;
пояснювати рішення для бізнесу;
підтримувати проєкт через місяці або роки.; Практична порада: перед commit майже завжди корисно запустити `git status`, щоб не зафіксувати зайве.; Проста аналогія: Git commit — це фотографія проєкту плюс підпис, хто її зробив і чому.; git blame src/payment.ts

</syntaxhighlight>

tree — стан файлів;
parent commit або кілька parents;
author;
committer;
timestamp;
commit message;
commit hash.; Якщо він уже був у history, його могли скопіювати.;</syntaxhighlight>

переглянути commits;
обговорити diff;
запустити CI;
перевірити tests;
провести code review;
об’єднати changes у main;
squash або merge commits.; Або для нового branch:

Merge commit корисний, бо:

== Atomic Commit ==
Commit hash надає можливість:
*.log
build: 3481
Проблеми:

'''Основна ідея:''' commit — це контрольна точка в історії коду, яка зберігає конкретні зміни разом із поясненням.; Після commit і push можуть запускатися:
Documentation commits можуть містити:

коду.; Перед роботою й перед commit корисно запускати `git status`.; '''істотно:''' amend безпечний для локальних commits, але з shared commits потрібно бути обережним, бо змінюється history.; \ \
Після commit потрібно зробити push?;

Недоліки:

Commit часто запускає CI/CD pipeline.;== Revert vs Reset ==

Після цього Git створює нову точку в історії repository.;

git add forgotten-file.ts
refactor: simplify payment service

'''Cherry-pick''' переносить конкретний commit в іншу гілку.;<syntaxhighlight lang="bash">
'''Практична роль:''' хороший message зменшує потребу шукати автора й питати: “А чому це змінили?”

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

* запуску CI/CD;
* позначення події;
* тестування pipeline;
* створення marker commit;
* ручного deployment trigger.; A → B → C
<syntaxhighlight lang="bash">
 D---M

</div>

'''Parent commit''' — commit, на якому базується поточний commit.; Його не варто review-ити поверхнево.; D---E-- feature

</div>
Push надає можливість:
Приклади:

<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

== Commit і Deployment ==

* чистіша main history;
* один commit на feature;
* простіший revert;
* менше шуму.; |-
| `--soft`
| прибирає commit, але залишає зміни staged
|-
| `--mixed`
| прибирає commit і залишає зміни unstaged
|-
| `--hard`
| прибирає commit і зміни з working tree
|}

'''Практична роль:''' working tree — це місце, де ви реально редагуєте файли перед тим, як зафіксувати зміни.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<syntaxhighlight lang="text">

Якщо secret потрапив у commit:
'''Практична роль:''' commit — одиниця історії, а pull request — одиниця обговорення й інтеграції змін.; Commits дозволяють відстежувати еволюція коду, працювати в branches, робити pull requests, запускати CI/CD, створювати releases і debug-ити production.; '''істотно:''' production без інформації про commit — це blind spot.;

Основні переважні аспекти commits: git reset --hard HEAD~1

Практична роль: commit hash у build metadata — це міст між source code і running application.;

docs: add API authentication examples
переважні аспекти atomic commits:

<syntaxhighlight lang="bash">

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
У staged changes немає зайвих файлів?;</div>

<syntaxhighlight lang="text">

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* API keys;
* passwords;
* private keys;
* database credentials;
* tokens;
* cloud credentials;
* signing keys;
* OAuth secrets;
* `.env` файли з паролями.;</div>
<syntaxhighlight lang="bash">

== Commit і Build ==

<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

Я в правильному branch?; Підхід

</div>

* видалено public API;
* змінено формат response;
* змінено database schema;
* змінено required config;
* видалено підтримку старої версії;
* змінено behavior function.;== Тематичні мітки ==

Short summary

* який commit deployed;
* коли deployed;
* ким або яким pipeline;
* які commits увійшли в release;
* який commit був попереднім;
* як зробити rollback;
* які migrations пов’язані з commit.; Add email validation, rewrite navbar, update database schema, fix typo

Commit Hash

Команда `git diff` показує різницю між версіями файлів.; Working tree → Staging area → Commit

істотно: commit не дорівнює backup у remote.;

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Приклад:
 D---E feature/login
</div>

known bad commit

Команди:
Типовий flow:

<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">
Refactor payment logic and reformat 80 files

Джерела

<syntaxhighlight lang="text">

</div>

<syntaxhighlight lang="bash">

<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">

Secrets не можна додавати в commit.; '''Conventional Commits''' — формат commit messages, який сприяє автоматизувати changelog і versioning.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''Проста думка:''' commit history — це щоденник проєкту, написаний кодом і повідомленнями commits.;<syntaxhighlight lang="text">

* У Git commit — це object із hash, metadata і посиланням на tree.;

== Squash Commit ==

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

перевірити identity;
зменшити ризик підроблених commits;
підвищити supply chain security;
виконати compliance-вимоги;
захистити важливі branches.; * Atomic commits дуже допомагають `git bisect`.; Приклад:

E - Fix typo

Author — людина, яка написала зміни.; Добрий open source commit:

git add .; Large commit не завжди поганий.; dist/

Практична роль: commit hash — це адреса конкретної точки в історії коду.; Через branches і merges історичний розвиток має змогу мати розгалуження.; Він зберігає рішення для бізнесу тоді, коли люди вже забули деталі.; !; Проблеми:

fix: correct tax rounding in invoice calculator

Commit і Changelog

</syntaxhighlight>

Commit варто робити, коли:

код переставлено без зміни поведінки;
поведінку справді змінено;
bug fix має конкретний ефект.; * важко review-ити;
важко revert-ити;
важко зрозуміти intent;
має змогу змішувати unrelated changes;
складніше debug;
більше шансів приховати bug;
гірше функціонує з git bisect.;

<syntaxhighlight lang="text">
Приклади:
</div>

* відстежувати зміни інструкцій;
* знаходити застарілі поради;
* перевіряти review;
* прив’язувати docs до release;
* пояснювати policy changes.;== Git Commit ==

Build artifact часто прив’язують до commit hash.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Documentation update

Pull

Практична порада: якщо reviewer не має змогу зрозуміти commit без усного пояснення, message або структура commit потребує покращення.; !;

Code review часто відбувається на рівні commits або pull request.; Commit надає можливість розробникам бачити історію проєкту, повертатися до попередніх версій, порівнювати зміни, працювати в branches, робити code review і точно розуміти, коли, ким і навіщо була внесена зміна.; Перед ним потрібно дуже чітко розуміти наслідки.;== переважні аспекти Commit ==

`M` — merge commit.;

</syntaxhighlight>

!; Практична роль: у open source commit message — це частина публічної історії проєкту.; Найкраща commit history — це не без ускладнень список змін, а корисна технічна історичний розвиток проєкту, яку можна читати, аналізувати й використовувати для рішень.; commit: a1b2c3d

</syntaxhighlight>

version: 1.4.2

Практична роль: документація теж має історію, і commits роблять її контрольованою.; Кожен commit знає свого parent commit, з цієї причини Git має змогу побудувати повну історію розвитку проєкту.;

git commit -m "Update file"

== Commit і Release ==

Formatting changes краще робити окремим commit.; Погано, коли “wip fix stuff maybe” без контексту потрапляє в main.; '''Практична роль:''' signed commit додає до історії не лише “хто написаний як автор”, а й криптографічне підтвердження.; a1b2c3d

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
git commit --allow-empty -m "Trigger deployment"
BREAKING CHANGE: clients must send tokens in the Authorization header.; як ілюстрація, automated formatting або mass rename має змогу бути великим, але логічно єдиним.; Команда `git status` показує стан repository.; Для цього використовують artifact storage, dataset versioning або model registry.; git revert a1b2c3d

fetch + rebase

== Interactive Rebase ==

Приклади:
<syntaxhighlight lang="text">
Поширена структура:
'''Головне правило:''' commit має бути маленьким настільки, щоб його без зайвих зусиль зрозуміти, і повним настільки, щоб він мав самостійний сенс.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
== Commit і Code Review ==

`commit` зберігає зміни локально.; Хороше commit message сприяє:

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

* вибір commit або tag;
* build artifact;
* tests;
* security scan;
* changelog;
* release notes;
* deployment;
* rollback plan;
* monitoring.; git log --oneline

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

git diff

перенесення hotfix;
backport у release branch;
вибіркового сфера застосування зміни;
відновлення окремого commit;
перенесення fix без усієї feature branch.;== Структура Commit Message ==

git add .; Що робить

Приклад checklist для Commit

Практична роль: merge commit показує не тільки зміни, а й момент інтеграції гілок.; Найлюдяніший факт: commit — це записка майбутньому розробнику: “Я змінив це ось чому”.; Типовий flow: Такі commits потребують особливо уважного review, бо можуть вплинути на production.; * не переписує історію;

безпечний для shared branches;
зрозуміло видно, що зміна була скасована;
добре підходить для main і production branches.; Explain why the change was made, not just what changed.;</syntaxhighlight>

істотно: розмір commit менш важливий, ніж його логічна цілісність.; * Committer — людина або платформа, яка створила commit у repository.; * Практики version control, source control, code review і Git workflows.;

В open source commits мають бути зрозумілими для людей, які не були в приватному контексті команди.; git diff --staged

Technical writer оновлює інструкцію deployment:

Добрі commits полегшують review:

</syntaxhighlight>

робити atomic commits;
писати зрозумілі commit messages;
перевіряти `git status`;
переглядати `git diff --staged`;
не комітити secrets;
не змішувати formatting і logic;
додавати tests для bug fixes;
робити push важливої роботи;
не переписувати shared history без узгодження;
використовувати conventional commits, якщо команда їх прийняла;
прив’язувати commits до issues або PR;
тримати main green;
не комітити generated files без потреби;
використовувати `.gitignore`;
робити revert замість reset у shared branches.;

Squash commit об’єднує кілька commits в один.; * вибрати, які зміни увійдуть у commit;

розділити різні зміни на окремі commits;
перевірити staged changes;
не комітити випадкові файли;
створювати atomic commits.;

Large Commit

зміни випадкові;
код не компілюється;
tests явно падають через вашу зміну;
у diff є собою secrets;
у commit змішано багато unrelated changes;
message довелося б писати як “stuff”;
у staged changes є собою debug logs;
ви не перевірили `git status`;
зміна ще настільки хаотична, що її краще розділити.;</syntaxhighlight>

Критично: breaking change має бути явно позначений, бо він впливає на users, clients, deployments і migration.; Практична роль: такий порядок зменшує шанс випадково закомітити не ті файли.;== .gitignore і Commit ==

має ясне message;
пов’язаний із issue або PR;
містить tests;
не містить secrets;
не ламає public API без пояснення;
відповідає contributing guide;
без зайвих зусиль review-иться.; Команда оперативно виправляє production issue:

істотно: для shared history частіше безпечніший revert, бо він не переписує минуле.;

Це надає можливість:

змінити порядок commits;
squash commits;
змінити commit message;
видалити commit;
розділити commit;
виправити попередній commit.; істотно: interactive rebase корисний для прибирання локальної історії перед PR, але небезпечний для commits, які вже використовує команда.; git status

Push надсилає local commits у remote repository.; git reset --soft HEAD~1

Staging area або index — проміжна зона Git, куди додають зміни перед commit.; Що робить

позначити release;
знайти source code версії;
створити changelog;
зробити rollback;
порівняти releases;
публікувати artifacts.;

Empty Commit

Working tree — поточний стан файлів у вашій робочій папці.; Commit краще відкласти, якщо:

як ілюстрація: Це сприяє reviewer-у відрізнити: Revert створює новий commit, який скасовує зміни попереднього commit.;</syntaxhighlight>

Приклад хорошого commit message

</syntaxhighlight>

Практична роль: conventional commits роблять історію більш машинозчитуваною й корисною для release automation.; Він не повинен містити secrets, випадкові файли або unrelated changes.; У більшості звичайних commits це одна й та сама людина.; Приклад додавання забутого файлу:

Проста думка: revert не стирає минуле, а додає нову зміну, яка нейтралізує стару.;

завдяки наявності Практична роль: короткий summary зручний у `git log`, а довший характеристика користувачі можуть зрозуміти контекст.; Приклад:

</syntaxhighlight>

У Git commit має author і committer.; Reset переміщує branch pointer на інший commit.;

== Див.; додатково ==

* affected projects;
* dependency graph;
* CI scope;
* ownership;
* code review;
* changelog generation;
* versioning;
* atomicity.;</div>
`push` відправляє commits у remote repository.; * `git log`;
* `git blame`;
* `git bisect`;
* `git show`;
* `git diff`;
* release tags;
* commit hash у logs;
* build metadata.;</div>

Приклад створення commit:

Message зрозуміле?; У Git commit містить snapshot файлів, metadata, автора, повідомлення, parent commits і унікальний hash.;=== Нова функція ===

=== Refactoring ===

== Приклад слабкого commit message ==
<syntaxhighlight lang="text">
</div>

Можливі ризики:
== git diff ==
У commit немає secrets?;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Приклад:

або в налаштованих workflow:

Amend переписує останній commit і змінює його hash.;== Типові помилки початківців ==

</syntaxhighlight>

</div>
Commit застосовується в:

'''Commit hash''' — унікальний ідентифікатор commit.; Звичайне збереження файлу каже: “ось поточний стан”.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>

'''істотно:''' commit добре версіонує код, але погано підходить для великих binary artifacts або datasets.; .DS_Store
Зазвичай `git pull` означає:
Generated files додані тільки якщо потрібно?; Це сприяє:

<syntaxhighlight lang="text">

* training code;
* feature engineering;
* notebooks;
* pipeline config;
* evaluation scripts;
* model serving code;
* data schema changes;
* experiment tracking config.;

</syntaxhighlight>

Цікавий момент: initial commit — це народження історії repository.;

<syntaxhighlight lang="bash">

* не пояснює, що змінилося;
* не пояснює причину;
* не сприяє review;
* не сприяє debugging;
* не підходить для changelog.;</div>

'''Практична роль:''' author і committer допомагають точніше зрозуміти походження зміни.; Якщо ви не зробили push, commit має змогу бути тільки на вашому комп’ютері.;

вважайте його скомпрометованим;
rotate secret;
перевірте remote repository;
перевірте CI logs;
видаліть secret із history за потреби;
повідомте відповідальних за security.; style: format codebase

* знайти контекст;
* побачити commit;
* знайти author;
* перейти до pull request;
* зрозуміти історію рядка.; * Матеріали щодо conventional commits, semantic versioning, changelog generation і release automation.;</div>
Розробник знаходить помилку в розрахунку invoice total, виправляє logic, додає regression test і створює commit:
Приклади:
<syntaxhighlight lang="text">
Fix invoice total rounding

істотно: `git blame` має бути інструментом пошуку контексту, а не пошуку винного.;=== Bug fix === A---B---C main

Цікавий факт

Formatting не змішаний із logic без потреби?;== Хороші практики Commit ==

git blame

Цікавий факт: atomic commits роблять `git bisect` набагато кориснішим, бо легше зрозуміти конкретну причину regression.; * Практики CI/CD, DevOps, build metadata, signed commits, software supply chain security і secure development.; Команда додає сторінку профілю користувача кількома atomic commits:

Commit і Repository

Commit завжди належить до історії repository, а branch вказує на один із commits.;== Commit і Tests ==

істотно: якщо formatting і logic змішані, review стає набагато складнішим.; Це зафіксувати осмислену зміну так, щоб команда й майбутні розробники могли їй довіряти.;

У Infrastructure as Code commits можуть змінювати реальну інфраструктуру.; git bisect good v1.2.0

Після локального commit зміни ще не обов’язково є собою на remote server.; Проблема — коли в одному commit змішано багато різних задач.; Типовий flow:

Зазвичай містить:

поділитися changes;
відкрити pull request;
запустити CI;
зберегти роботу на remote;
синхронізуватися з командою.;

Before:

Merge commit має змогу мати кілька parents:

Приклад: </syntaxhighlight> </syntaxhighlight>

<syntaxhighlight lang="bash">

<syntaxhighlight lang="bash">

Merge Commit

Commits допомагають debug-ити проблеми.; This changes the validation to compare

git pull Branch рухається вперед, коли в ньому створюються нові commits.; Поширені помилки: Fix checkout crash on empty cart

Практична порада: робіть commit тоді, коли можете чесно написати зрозуміле message про одну зміну.;

S - Add signup form Критично: видалити secret у наступному commit недостатньо.; Tag сприяє:

Commit у Monorepo

Author і Committer

docs: add deployment troubleshooting guide

git commit --amend -m "Fix invoice rounding"

Breaking change — зміна, яка ламає сумісність.; Deployment часто пов’язаний із конкретним commit.;

писати commit message `fix`;
комітити все через `git add .` без перевірки;
забувати push;
комітити secrets;
комітити build artifacts без потреби;
змішувати кілька задач в одному commit;
боятися робити часті commits;
робити commit у неправильному branch;
використовувати `reset --hard` без розуміння;
force push у shared branch;
не перевіряти diff;
не додавати tests;
думати, що commit автономно означає backup у remote;
не знати різницю між commit, push і merge.;

Приклади:

Загальний характеристика

git status перевірено?;

Але для локальної експериментальної роботи іноді тимчасові commits нормальні, якщо потім history буде cleaned up перед merge.; * точно знайти commit;
* посилатися на зміни;
* робити checkout;
* створювати tags;
* debug-ити production;
* пов’язувати build із source code;
* робити revert;
* аналізувати історію.; Приклади:

'''Commit''' — це зафіксована одиниця історії змін у системі контролю версій.; Команда
<syntaxhighlight lang="text">
У data science і ML commits часто містять:

Потрібно уважно стежити за:

git add src/profile.ts

Fix cart total calculation for discounted items

* build artifacts;
* logs;
* local config;
* secrets;
* dependencies у частині екосистем;
* temporary files;
* OS metadata;
* editor files;
* cache folders.; Squash корисний, якщо feature branch має багато дрібних або “робочих” commits.; Зазвичай ігнорують:

<syntaxhighlight lang="bash">
Приклад зміни повідомлення:
'''Практична порада:''' у monorepo особливо істотно не змішувати unrelated changes в одному commit.; \ /
git commit -m "Add profile settings"
'''Практична роль:''' хороші commits допомагають не згадувати перед релізом, що саме змінилося.; '''Проста аналогія:''' commit — це точка на дорозі, branch — це назва дороги, яка веде до поточної точки.; '''істотно:''' тимчасовий локальний commit — нормально.; Changelog має змогу включати:
== Reset Commit ==
Приклад:

</div>

Вона показує:

'''істотно:''' empty commit корисний іноді, але якщо команда часто ним запускає процеси, можливо, pipeline потребує кращого manual trigger.;<syntaxhighlight lang="text">

Приклад:
Commit → Push → CI checks → Pull Request → Merge → Deploy
feat: add password reset flow

changes

== Приклад базового commit workflow ==

The checkout page assumed that cart.items always existed.; Складно debug-ити систему, якщо невідомо, який код функціонує.; '''Критично:''' `git reset --hard` має змогу знищити незбережені зміни.; '''Проста аналогія:''' staging area — це кошик перед касою: ви вирішуєте, що саме піде в наступний commit.;

git push origin feature/profile-settings

docs: update staging deployment guide

project structure;
README;
license;
basic configuration;
source code skeleton;
`.gitignore`;
package manifest;
initial tests.; Практична роль: commits дозволяють знайти не тільки де проблема, а й коли вона з’явилася.; * Матеріали щодо atomic commits, debugging, git bisect, git blame і clean commit history.; У documentation projects commit має змогу бути так само важливим, як у code repository.; Приклад:

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

<syntaxhighlight lang="text">
</div>

Initial commit — перший commit у repository.;

node_modules/

`git blame` показує, який commit останнім змінив кожен рядок файлу.; * Signed commits допомагають підтвердити походження змін.; Якщо commit messages структуровані, changelog легше генерувати автономно.; Це частина ланцюга історії.; * Git;

Mercurial;
Subversion у близьких за змістом операціях;
software development;
documentation projects;
DevOps;
data engineering;
infrastructure as code;
open source;
CI/CD;
code review;
release management.;

Documentation commits допомагають:

git bisect start Хороший commit має бути логічним, зрозумілим, перевіреним і безпечним.; Але вони можуть відрізнятися, як ілюстрація, при applying patches або rebasing.; known good commit Приклад хорошого повідомлення:

PR надає можливість:

Push

chore: update dependencies

</syntaxhighlight>

Commit і Documentation

docs: clarify backup restore steps

Практична роль: checklist сприяє зробити commit чистим, безпечним і корисним для історії проєкту.; Інакше складно відтворити версію.;== git status == застосовується для:

Signed Commit

переважні аспекти:

docs: update API guide

Переглянути історію:

Чому це добре:

Commit має одну логічну зміну?; Погано:

Signed commits допомагають: