Перейти до вмісту

Commit

Матеріал з K2 ERP Wiki

</syntaxhighlight>

Приклад:

Git binary-searches history 

<syntaxhighlight lang="bash">

Commit має одну логічну зміну? git commit -m "Update file"

'''Небезпека:''' найпростіша помилка — зробити commit не в тому branch.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
 D---E-- feature
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Хороший commit має бути логічним, зрозумілим, перевіреним і безпечним. Якщо commit messages структуровані, changelog легше генерувати автоматизовано. Проблема — коли в одному commit змішано багато різних задач. Приклад:
'''критично:''' empty commit корисний іноді, але якщо команда часто ним запускає процеси, можливо, pipeline потребує кращого manual trigger. * Revert не видаляє commit із history, а створює новий commit зі зворотною зміною. '''Практична роль:''' parent commits дозволяють Git будувати історію й розуміти, як зміни пов’язані між собою. Ідея:
<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
Краще:

Або для нового branch:

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

git diff

  • короткий summary;
  • пояснено причину;
  • пояснено fix;
  • згадано test;
  • майбутній читач зрозуміє контекст. * Практики CI/CD, DevOps, build metadata, signed commits, software supply chain security і secure development.=== Refactoring ===

</syntaxhighlight> Commit краще відкласти, якщо: a1b2c3d4e5f678901234567890abcdef12345678

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

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

критично: тимчасовий локальний commit — нормально. До secrets належать: Pull request зазвичай складається з одного або кількох commits. Це частина ланцюга історії. Fix cart total calculation for discounted items

fix: correct tax rounding in invoice calculator

Практична роль: commit стає не лише записом в історії, а й тригером автоматичної перевірки якості. commit: a1b2c3d

git rebase -i HEAD~3

Приклади:

Але для локальної експериментальної роботи іноді тимчасові commits нормальні, якщо потім history буде cleaned up перед merge.
</div>
== Cherry-Pick Commit ==

The checkout page assumed that cart.items always existed. * Git;
* Mercurial;
* Subversion у близьких за змістом операціях;
* software development;
* documentation projects;
* DevOps;
* data engineering;
* infrastructure as code;
* open source;
* CI/CD;
* code review;
* release management. * Практики version control, source control, code review і Git workflows. * Зміна commit message через amend змінює commit hash. docs: remove outdated deployment command

'''Головна думка:''' commit — це не без зусиль “зберегти код”.== Приклади сценаріїв використання ==

* зміни випадкові;
* код не компілюється;
* tests явно падають через вашу зміну;
* у diff виступає як secrets;
* у commit змішано багато unrelated changes;
* message довелося б писати як “stuff”;
* у staged changes виступає як debug logs;
* ви не перевірили `git status`;
* зміна ще настільки хаотична, що її краще розділити. Якщо він уже був у history, його могли скопіювати.</div>
'''Практична роль:''' tests у commit показують, що зміна не тільки написана, а й перевірена. Складно debug-ити систему, якщо невідомо, який код функціонує. * Матеріали щодо conventional commits, semantic versioning, changelog generation і release automation.<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">

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

Це оптимізує:

* перенесення hotfix;
* backport у release branch;
* вибіркового сценарії використання зміни;
* відновлення окремого commit;
* перенесення fix без усієї feature branch. Погано, коли “wip fix stuff maybe” без контексту потрапляє в main.<syntaxhighlight lang="text">
'''Найлюдяніший факт:''' commit — це спосіб не покладатися на пам’ять.</div>
A---B---C
git commit -m "Add profile settings"

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

Команда `git diff` показує різницю між версіями файлів.</div>

* bug fix + regression test;
* new feature + unit tests;
* API change + integration tests;
* UI change + component tests;
* refactoring + existing tests still pass. * Commit hash часто потрапляє в build metadata, logs і release notes.== Parent Commit ==
Приклад:
'''Conventional Commits''' — формат commit messages, який оптимізує цифровізувати changelog і versioning. Поширені помилки:
*.log
Commit завжди належить до історії repository, а branch вказує на один із commits. '''критично:''' `git blame` має бути інструментом пошуку контексту, а не пошуку винного. Підхід

'''Проста аналогія:''' commit — це точка на дорозі, branch — це назва дороги, яка веде до поточної точки.</div>
== Initial Commit ==

</div>

<syntaxhighlight lang="text">

== Commit у Infrastructure as Code ==

D - Add form
як приклад:
git cherry-pick a1b2c3d

</div>

* позначити release;
* знайти source code версії;
* створити changelog;
* зробити rollback;
* порівняти releases;
* публікувати artifacts. Push дає можливість:
Недоліки:
<syntaxhighlight lang="text">

docs: update API guide

Tag часто ставлять на commit, який відповідає release.=== Documentation update ===

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

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

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

</div>
Explain why the change was made, not just what changed. ! Release process здатна включати:

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

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

== git diff ==
Initial commit
<syntaxhighlight lang="bash">

known good commit

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
Formatting changes краще робити окремим commit. Після commit і push можуть запускатися:
'''Критично:''' `git reset --hard` здатна знищити незбережені зміни.<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">
<syntaxhighlight lang="text">

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

Commit і Repository

* new features;
* bug fixes;
* breaking changes;
* performance improvements;
* security fixes;
* dependency updates;
* migration notes. git diff
Technical writer оновлює інструкцію deployment:

Commit дає можливість розробникам бачити історію проєкту, повертатися до попередніх версій, порівнювати зміни, працювати в branches, робити code review і точно розуміти, коли, ким і навіщо була внесена зміна. * змінити порядок commits;
* squash commits;
* змінити commit message;
* видалити commit;
* розділити commit;
* виправити попередній commit. '''критично:''' commit добре версіонує код, але погано підходить для великих binary artifacts або datasets. feat: add user profile route
== Commit і Pull Request ==
конкурентні переваги:

У conventional commits breaking change часто позначають так:

'''критично:''' для shared history частіше безпечніший revert, бо він не переписує минуле. * Commit history здатна бути технічною документацією, якщо її писали уважно.

Приклад: Empty commit — commit без змін у файлах.</syntaxhighlight> |- | Revert | Створює новий commit, який скасовує зміну | Shared branches, main, production history |- | Reset | Переміщує branch pointer і здатна прибрати commits | Локальна історія продукту, cleanup перед push |}

E - Fix typo

Commit і Secrets

Приклади:

Основна ідея: commit — це контрольна точка в історії коду, яка зберігає конкретні зміни разом із поясненням. known bad commit

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

Краще:

  • поділитися changes;
  • відкрити pull request;
  • запустити CI;
  • зберегти роботу на remote;
  • синхронізуватися з командою. Цей workflow:
Практична порада: якщо reviewer не здатна зрозуміти commit без усного пояснення, message або структура commit потребує покращення.
  • поточний branch;
  • staged changes;
  • unstaged changes;
  • untracked files;
  • чи branch випереджає remote;
  • чи виступає як conflicts;
  • підказки щодо наступних команд. Команда має знати:
  • зміни в одному файлі;
  • зміни в багатьох файлах;
  • додавання файлу;
  • видалення файлу;
  • перейменування;
  • refactoring;
  • bug fix;
  • feature;
  • test update;
  • documentation update;
  • configuration change;
  • migration script.== git blame ==

Якщо secret потрапив у commit:

</syntaxhighlight>

</syntaxhighlight>

git status Приклад: 

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

Приклад: критично: перед створенням нового branch або commit у спільному branch корисно підтягнути актуальні зміни. Що робить

Цікавий факт

</syntaxhighlight>

  • який commit deployed;
  • коли deployed;
  • ким або яким pipeline;
  • які commits увійшли в release;
  • який commit був попереднім;
  • як зробити rollback;
  • які migrations пов’язані з commit.== конкурентні переваги Commit ==

Commit у Documentation Projects

git reset --mixed HEAD~1

Commit hash — унікальний ідентифікатор commit. Після локального commit зміни ще не обов’язково виступає як на remote server.
Parent commit — commit, на якому базується поточний commit. Кожен commit знає свого parent commit, тому Git здатна побудувати повну історію розвитку проєкту.

A---B---C main Merge commit корисний, бо:

feat: add password reset flow

Критично: breaking change має бути явно позначений, бо він впливає на users, clients, deployments і migration. Tests додані або оновлені, якщо потрібно?
{| class="wikitable"
'''критично:''' перед commit варто подивитися diff. Commit history здатна використовуватися для створення changelog. ! Приклад:
Refactoring commits краще відокремлювати від behavior changes. `.gitignore` оптимізує не додавати зайві файли в commits. * Atomic commits дуже допомагають `git bisect`.

</syntaxhighlight> </syntaxhighlight> критично: commit message має пояснювати не лише “що”, а іноді й “чому”. У data science і ML commits часто містять: 

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

<syntaxhighlight lang="bash">

* перевірити identity;
* зменшити ризик підроблених commits;
* підвищити supply chain security;
* виконати compliance-вимоги;
* захистити важливі branches. В open source commits мають бути зрозумілими для людей, які не були в приватному контексті команди.</div>

* '''Author''' — людина, яка написала зміни. Build artifact часто прив’язують до commit hash.
  • чистіша main history;
  • один commit на feature;
  • простіший revert;
  • менше шуму.
    == Коли варто робити Commit ==
<syntaxhighlight lang="bash">
Команда для перегляду:

Приклади:

git diff --staged

git add src/profile.ts 

Fix password reset token expiration
|-
| `--soft`
| прибирає commit, але залишає зміни staged
|-
| `--mixed`
| прибирає commit і залишає зміни unstaged
|-
| `--hard`
| прибирає commit і зміни з working tree
|}

git log --oneline
</div>
Команда `git status` показує стан repository.<syntaxhighlight lang="bash">
version: 1.4.2

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

</syntaxhighlight> Add email validation to signup form

</syntaxhighlight>

Приклад:

  • переглянути commits;
  • обговорити diff;
  • запустити CI;
  • перевірити tests;
  • провести code review;
  • об’єднати changes у main;
  • squash або merge commits. git push -u origin feature/login

Команда додає сторінку профілю користувача кількома atomic commits: 

</div>
docs: add API authentication examples
== Висновок ==

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

</div>

* показує факт об’єднання branches;
* зберігає topology історії;
* групує changes feature branch;
* оптимізує зрозуміти, коли feature потрапила в main.</div>

<syntaxhighlight lang="text">

* `feat`;
* `fix`;
* `docs`;
* `style`;
* `refactor`;
* `test`;
* `build`;
* `ci`;
* `chore`;
* `perf`.</div>
== Git Commit ==

Branch рухається вперед, коли в ньому створюються нові commits. Short summary docs: clarify backup restore steps

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

Tokens were accepted for 48 hours because the expiration check used

git blame src/payment.ts

  • project structure;
  • README;
  • license;
  • basic configuration;
  • source code skeleton;
  • `.gitignore`;
  • package manifest;
  • initial tests. chore: update dependencies

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

node_modules/

  • робити 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. Merge commit здатна мати кілька parents:

Amend переписує останній commit і змінює його hash. git commit --amend

Merge commit створюється, коли Git об’єднує дві гілки й фіксує це як окремий commit. У Git commit містить snapshot файлів, metadata, автора, повідомлення, parent commits і унікальний hash.</syntaxhighlight>

Conventional Commits

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

! критично: commit не дорівнює backup у remote.== Див. так само == 

'''Large commit''' — commit із великою кількістю різних змін.</div>
'''Практична роль:''' у open source commit message — це частина публічної історії проєкту. * писати 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 diff переглянуто?== Commit і Formatting ==

історія продукту оптимізує:

</syntaxhighlight> refactor: extract invoice calculator

Amend Commit

dist/

Revert Commit

Staging area дає можливість: git add file.txt git bisect good v1.2.0

Commit і Tags

* знати, який код у production;
* debug-ити bug;
* робити rollback;
* відтворити build;
* провести audit;
* знайти diff між releases. Проблеми:
test: add profile update tests

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

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

Зазвичай `git pull` означає:

Signed Commit

  • не переписує історію;
  • безпечний для shared branches;
  • зрозуміло видно, що зміна була скасована;
  • добре підходить для main і production branches. Add email validation, rewrite navbar, update database schema, fix typo
  • втрачається детальна commit history branch;
  • складніше побачити проміжні кроки;
  • погано, якщо commits були логічно різними. `M` — merge commit. `git blame` показує, який commit останнім змінив кожен рядок файлу. Commit каже: “ось зміна забезпечується через Саме тому Git більше схожий не на кнопку “Save”, а на машину часу; так само реалізовано ось хто її зробив, ось коли, ось повідомлення, ось її місце в історії”. Проста думка: commit history — це щоденник проєкту, написаний кодом і повідомленнями commits.</syntaxhighlight>

Commit Message

Загальний SEO-опис

коду.
У documentation projects commit здатна бути так само важливим, як у code repository. '''Практична роль:''' working tree — це місце, де ви реально редагуєте файли перед тим, як зафіксувати зміни. * точно знайти commit;
* посилатися на зміни;
* робити checkout;
* створювати tags;
* debug-ити production;
* пов’язувати build із source code;
* робити revert;
* аналізувати історію. Після commit потрібно зробити push? \ /
<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;">

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

Поганий приклад:

як приклад: Приклад:

  • `git diff` показує unstaged changes;
  • `git diff --staged` показує зміни, які вже потраплять у commit.</syntaxhighlight>

</syntaxhighlight> After squash:

Практична роль: conventional commits роблять історію більш машинозчитуваною й корисною для release automation. \ \

</syntaxhighlight>

У Git commits утворюють graph, а не без зусиль лінійний список.== Reset Commit ==

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

Git commit — об’єкт Git, який фіксує snapshot проєкту й metadata.== Цікаві факти про Commit == </syntaxhighlight> </syntaxhighlight>

Commit і Changelog

git status

Commit history — послідовність commits у repository. * Signed commits допомагають підтвердити походження змін. git commit --allow-empty -m "Trigger deployment"

Commit і Deployment

Squash корисний, якщо feature branch має багато дрібних або “робочих” commits. Команда

Commit і Build

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

== Working Tree ==

* affected projects;
* dependency graph;
* CI scope;
* ownership;
* code review;
* changelog generation;
* versioning;
* atomicity.</div>
== Commit і CI/CD ==

Я в правильному branch? * знайти, коли з’явилась зміна;

  • зрозуміти дорожня карта розвитку feature;
  • відстежити bug;
  • знайти автора;
  • підготувати release notes;
  • зробити revert;
  • провести audit. A → B → C
* має ясне message;
* пов’язаний із issue або PR;
* містить tests;
* не містить secrets;
* не ламає public API без пояснення;
* відповідає contributing guide;
* швидко review-иться. Рекомендовано:

== Merge Commit ==

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

== Revert vs Reset ==

== Commit у Open Source ==
</div>
застосовується для для:
</div>
Приклад додавання забутого файлу:

</div>

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

a1b2c3d
</div>
У Добрий commit часто передбачено tests для зміни.<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

'''критично:''' release має бути traceable до конкретного commit або tag. '''Staging area''' або '''index''' — проміжна зона Git, куди додають зміни перед commit. '''Головне правило:''' commit має бути маленьким настільки, щоб його швидко зрозуміти, і повним настільки, щоб він мав самостійний сенс.== Структура Commit Message ==

== Author і Committer ==

* вибрати, які зміни увійдуть у commit;
* розділити різні зміни на окремі commits;
* перевірити staged changes;
* не комітити випадкові файли;
* створювати atomic commits. Його не варто review-ити поверхнево. Добрі commits полегшують review:

<syntaxhighlight lang="bash">

Це дає можливість:
Приклади:
'''критично:''' amend безпечний для локальних commits, але з shared commits потрібно бути обережним, бо змінюється history. * unmodified;
* modified;
* staged;
* untracked;
* deleted;
* renamed.<syntaxhighlight lang="bash">
'''Reset''' переміщує branch pointer на інший commit. '''Цікавий момент:''' initial commit — це народження історії repository. Message зрозуміле? '''Revert''' створює новий commit, який скасовує зміни попереднього commit.<syntaxhighlight lang="text">

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

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

git revert a1b2c3d

== Commit і Branch ==

* training code;
* feature engineering;
* notebooks;
* pipeline config;
* evaluation scripts;
* model serving code;
* data schema changes;
* experiment tracking config. D---E feature/login

* зрозуміти історію;
* швидше review-ити код;
* debug-ити regression;
* писати changelog;
* пояснювати рішення для бізнесу;
* підтримувати проєкт через місяці або роки.</div>

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

'''Перевага:''' commits дозволяють не без зусиль бачити фінальний код, а розуміти шлях, яким команда до нього прийшла. refactor: simplify payment calculation

* У Git commit — це object із hash, metadata і посиланням на tree. * '''Committer''' — людина або платформа, яка створила commit у repository. '''критично:''' production без інформації про commit — це blind spot.<syntaxhighlight lang="text">

Типовий flow:

</div>
== Commit і Remote Repository ==
== Commit History ==

fetch + rebase

Такі commits потребують особливо уважного review, бо можуть вплинути на production. .env
<syntaxhighlight lang="text">

Практична порада: перед commit майже завжди корисно запустити `git status`, щоб не зафіксувати зайве. Signed commits допомагають:

Commit і Refactoring

Приклад:

Часто використовують коротку форму:

Команда оперативно виправляє production issue:

Джерела

created_at instead of expires_at. Він зберігає рішення для бізнесу тоді, коли люди вже забули деталі.<syntaxhighlight lang="bash">
<syntaxhighlight lang="text">
== Commit і Tests ==

changes
</div>
'''Критично:''' infrastructure commit здатна створити, змінити або видалити реальні ресурси. Що робить

Push надсилає local commits у remote repository. git bisect bad

  • API keys;
  • passwords;
  • private keys;
  • database credentials;
  • tokens;
  • cloud credentials;
  • signing keys;
  • OAuth secrets;
  • `.env` файли з паролями.== Commit і Documentation ==

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

У staged changes немає зайвих файлів? Commits дозволяють відстежувати дорожня карта розвитку коду, працювати в branches, робити pull requests, запускати CI/CD, створювати releases і debug-ити production.
'''Практична роль:''' commit hash — це адреса конкретної точки в історії коду. Це зафіксувати осмислену зміну так, щоб команда й майбутні розробники могли їй довіряти.</div>

refactor: extract invoice calculator

* код переставлено без зміни поведінки;
* поведінку справді змінено;
* bug fix має конкретний ефект. git reset --soft HEAD~1

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

<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;">
<syntaxhighlight lang="bash">
'''Atomic commit''' — commit, який містить одну логічну зміну.</div>

F - Update tests

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

git diff --staged

against expires_at and adds a regression test. * README updates;

  • API docs;
  • changelog;
  • architecture notes;
  • tutorials;
  • configuration guide;
  • migration guide;
  • comments;
  • examples. Squash commit об’єднує кілька commits в один. Це простий спосіб помітити випадкові debug logs, secrets або непотрібні зміни.
    <div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
  • 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. Commit варто робити, коли:
Cherry-pick переносить конкретний commit в іншу гілку.
Fix checkout crash on empty cart

== git status ==
</div>

test: add checkout tests

Можна: 

Commit здатна містити:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Команди:

<syntaxhighlight lang="text">

'''Найлюдяніший факт:''' commit — це записка майбутньому розробнику: “Я змінив це ось чому”. Tag оптимізує:

У monorepo один commit здатна торкатися кількох packages або applications. Чому це добре:
Commit hash дає можливість:
'''Практична роль:''' `.gitignore` зменшує шанс випадково закомітити сміття, secrets або локальні файли.== Breaking Change у Commit ==

Приклад:

== Ризики Commit ==

* `git log`;
* `git blame`;
* `git bisect`;
* `git show`;
* `git diff`;
* release tags;
* commit hash у logs;
* build metadata. * Найкращі commits часто нудні: маленькі, зрозумілі, перевірені й добре названі.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

git status перевірено? Якщо ви не зробили push, commit здатна бути тільки на вашому комп’ютері.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

== Pull ==
'''Практична роль:''' документація теж має історію, і commits роблять її контрольованою. '''Практична роль:''' commits дозволяють знайти не тільки де проблема, а й коли вона з’явилася. fix

* видалено public API;
* змінено формат response;
* змінено database schema;
* змінено required config;
* видалено підтримку старої версії;
* змінено behavior function. '''Проста аналогія:''' Git commit — це фотографія проєкту плюс підпис, хто її зробив і чому.<syntaxhighlight lang="bash">

Large commit не завжди поганий.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
'''Головна перевага:''' commit робить зміну коду конкретною, поясненою й відстежуваною. Generated files додані тільки якщо потрібно? * Merge commit здатна мати більше одного parent. PR дає можливість:

* одна логічна зміна;
* зрозуміле message;
* немає випадкових файлів;
* tests поруч зі зміною;
* refactoring окремо від behavior change;
* formatting окремо від logic. Working tree → Staging area → Commit

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

'''Цікавий факт:''' atomic commits роблять `git bisect` набагато кориснішим, бо легше зрозуміти конкретну причину regression.== Staging Area ==

Добрий open source commit:

</div>
Типовий flow:

критично: розмір commit менш важливий, ніж його логічна цілісність. Інакше складно відтворити версію.== Squash Commit == 

Secrets не можна додавати в commit. feat!: change authentication token format
== Commit Hash ==

D---M

feat: add profile edit form fix: correct invoice total rounding

Потім Git пропонує commits для перевірки, поки не знайде перший bad commit.</syntaxhighlight>

.DS_Store

Commit у Git — це не без зусиль “збереження файлів”.
== Empty Commit ==
Можливі ризики:
Розробник виносить розрахунок ціни в окремий class без зміни поведінки:

У Infrastructure as Code commits можуть змінювати реальну інфраструктуру. Приклад:

Поширена структура:
`git bisect` оптимізує знайти commit, у якому з’явився bug. '''критично:''' squash зручний, але не треба зливати в один commit unrelated changes. Приклади:

* вважайте його скомпрометованим;
* rotate secret;
* перевірте remote repository;
* перевірте CI logs;
* видаліть secret із history за потреби;
* повідомте відповідальних за security. як приклад, automated formatting або mass rename здатна бути великим, але логічно єдиним. docs: update staging deployment guide
<syntaxhighlight lang="text">
'''Практична роль:''' checklist оптимізує зробити commit чистим, безпечним і корисним для історії проєкту.== Типові помилки початківців ==

</div>

Documentation commits допомагають:
'''Практична порада:''' у monorepo особливо критично не змішувати unrelated changes в одному commit. Commits допомагають debug-ити проблеми.</div>
git add .</div>

'''Головна ідея:''' один commit — одна зрозуміла причина для зміни. Перед ним потрібно дуже чітко розуміти наслідки. Короткий варіант:
  • build artifacts;
  • logs;
  • local config;
  • secrets;
  • dependencies у частині екосистем;
  • temporary files;
  • OS metadata;
  • editor files;
  • cache folders.</syntaxhighlight>

</syntaxhighlight>

Interactive rebase дає можливість редагувати локальну історію commits. конкурентні переваги atomic commits: Небезпека: поганий commit здатна не тільки зламати код, а й ускладнити розуміння історії на роки вперед. Після цього Git створює нову точку в історії repository. This changes the validation to compare git add forgotten-file.ts

Commit message — текстове пояснення, що змінив commit і навіщо. Звичайне збереження файлу каже: “ось поточний стан”. Переглянути історію:

Практична роль: author і committer допомагають точніше зрозуміти походження зміни.

git reset --hard HEAD~1

Formatting не змішаний із logic без потреби? це зафіксований знімок змін у системі контролю версій виступає ключовою рисою Commit або коміт. У більшості звичайних commits це одна й та сама людина.
Основні конкурентні переваги commits:
  • Документація Git щодо commits, staging area, commit objects, branches, merge, rebase, revert і reset.== Приклад слабкого commit message ==

Нова функція

</syntaxhighlight> 

'''Практична роль:''' merge commit показує не тільки зміни, а й момент інтеграції гілок. * знайти контекст;
* побачити commit;
* знайти author;
* перейти до pull request;
* зрозуміти історію рядка.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
'''Repository''' зберігає commits, branches, tags і metadata. '''Проста різниця:''' commit — це точка в історії, tag — це важлива мітка на цій точці. Через branches і merges історія продукту здатна мати розгалуження. Перед роботою й перед commit корисно запускати `git status`.<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">

* linting;
* tests;
* build;
* security scan;
* type checking;
* preview deployment;
* artifact creation;
* Docker image build;
* deployment to staging;
* release automation. Приклад:
<syntaxhighlight lang="text">
== Commit і Release ==

<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">
This adds a guard for empty carts and returns the user to the cart page. Типовий flow:
== Приклад хорошого commit message ==
== git bisect ==
'''Amend''' дає можливість змінити останній commit. У commit немає secrets?

Критично: видалити secret у наступному commit недостатньо.</syntaxhighlight>

Приклади:

Commit і Debugging

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

Проблеми: 

Commit містить:
git log
Documentation commits можуть містити:
== Приклад checklist для Commit ==
Deployment часто пов’язаний із конкретним commit.<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
== Commit у Data і ML-проєктах ==
`commit` зберігає зміни локально.<syntaxhighlight lang="text">
<syntaxhighlight lang="gitignore">
Приклад:

</div>

* легше review;
* легше revert;
* зрозуміліша історія продукту;
* простіше debug;
* краще для bisect;
* менше ризику змішаних змін.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

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

Локальні tests проходять? Для цього використовують artifact storage, dataset versioning або model registry. style: format codebase

конкурентні переваги revert:
== Коли краще не робити Commit ==
git bisect start

'''критично:''' interactive rebase корисний для прибирання локальної історії перед PR, але небезпечний для commits, які вже використовує команда. Changelog здатна включати:

* завершена логічна частина роботи;
* tests проходять;
* зміна має сенс окремо;
* потрібно зберегти прогрес;
* зміна готова для review;
* завершено bug fix;
* додано documentation;
* зроблено refactoring;
* оновлено config;
* створено migration. У Git commit зберігає стан файлів на певний момент, автора, дату, повідомлення, посилання на попередній commit і унікальний ідентифікатор — commit hash. Тут commits `D` і `E` знаходяться на branch `feature/login`. * Матеріали щодо atomic commits, debugging, git bisect, git blame і clean commit history. Приклад:

fetch + merge

'''критично:''' якщо formatting і logic змішані, review стає набагато складнішим.== Push ==
</div>
</div>

Commit → Push → CI checks → Pull Request → Merge → Deploy

У Git commit має author і committer.</div>
</div>
</div>

\

S - Add signup form

</syntaxhighlight> Commit — це зафіксована одиниця історії змін у системі контролю версій. Створити:

Bug fix

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

Приклад: 

'''Помилка:''' commit message типу `stuff`, `update`, `fix2` або `final` майже нічого не каже майбутній команді. Fix invoice total rounding
git tag v1.4.0 a1b2c3d

<syntaxhighlight lang="text">

build: 3481

Code review часто відбувається на рівні commits або pull request.== Large Commit ==

SEO title: Commit — коміт у Git, контроль версій, історія змін, повідомлення commit і командна розробка

SEO keywords: Commit, коміт, Git commit, version control, source control, Git, commit hash, commit message, staging area, branch, repository, merge commit, squash commit, amend commit, revert commit, reset, conventional commits, atomic commit, code review, CI/CD, software development 

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки.

}}


  • перевіряє поточний стан;
  • переглядає зміни;
  • додає потрібний файл;
  • перевіряє staged diff;
  • створює commit;
  • відправляє commit у remote. Практична роль: documentation commit фіксує зміни знань так само, як code commit фіксує зміни поведінки.</syntaxhighlight>
BREAKING CHANGE: clients must send tokens in the Authorization header. '''Практична роль:''' commit — одиниця історії, а pull request — одиниця обговорення й інтеграції змін.== Commit у Monorepo ==
'''Signed commit''' — commit із cryptographic signature, яка підтверджує автора або джерело commit. `push` відправляє commits у remote repository. * запуску CI/CD;
* позначення події;
* тестування pipeline;
* створення marker commit;
* ручного deployment trigger. '''Практична роль:''' такий порядок зменшує шанс випадково закомітити не ті файли. * не пояснює, що змінилося;
* не пояснює причину;
* не оптимізує review;
* не оптимізує debugging;
* не підходить для changelog.<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
! '''Практична роль:''' cherry-pick дає можливість взяти одну “вишеньку” з історії й перенести її в інше місце. Release зазвичай складається з одного або кількох commits, які потрапили в стабільну версію.

refactor: simplify payment service

  • tree — стан файлів;
  • parent commit або кілька parents;
  • author;
  • committer;
  • timestamp;
  • commit message;
  • commit hash.

Практична роль: signed commit додає до історії не лише “хто написаний як автор”, а й криптографічне підтвердження. Commit часто запускає CI/CD pipeline.</syntaxhighlight>

docs: add deployment troubleshooting guide

Before:

  • історія продукту змін;
  • traceability;
  • можливість rollback;
  • командна робота;
  • code review;
  • CI/CD integration;
  • debugging;
  • release management;
  • audit;
  • documentation of intent;
  • технічна підтримка branches;
  • порівняння versions;
  • пошук regression;
  • прив’язка build до source code. Refactor payment logic and reformat 80 files
Практична роль: push робить commits доступними іншим людям і системам. Working tree — поточний стан файлів у вашій робочій папці. * Поганий commit message здатна здаватися дрібницею сьогодні, але дуже дратувати через пів року. критично пам’ятати, що великі datasets і model artifacts зазвичай не варто зберігати прямо в Git commits. Найкраща commit history — це не без зусиль список змін, а корисна технічна історія продукту проєкту, яку можна читати, аналізувати й використовувати для рішень. Longer explanation if needed.

Різниця: або в налаштованих workflow:

Atomic Commit

Тематичні мітки

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

через Практична роль: короткий summary зручний у `git log`, а довший SEO-опис користувачі можуть зрозуміти контекст. Практична роль: хороший message зменшує потребу шукати автора й питати: “А чому це змінили?” fix: handle empty cart during checkout

Breaking change — зміна, яка ламає сумісність.

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

Практична порада: окремий refactoring commit — це подарунок reviewer-у й майбутньому debugging-у. Погано:

Pull отримує changes з remote repository і інтегрує їх у локальний branch. Зазвичай ігнорують:

Команди:

git commit -m "Add user profile page" git push

</syntaxhighlight>

Commit і Code Review

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

Commits можуть створювати проблеми, якщо їх робити недбало. git push origin feature/profile-settings

  • вибір commit або tag;
  • build artifact;
  • tests;
  • security scan;
  • changelog;
  • release notes;
  • deployment;
  • rollback plan;
  • monitoring. Але вони можуть відрізнятися, як приклад, при applying patches або rebasing. Коли доречний

git commit -m "Add profile update validation"

Interactive Rebase

Розробник знаходить помилку в розрахунку invoice total, виправляє logic, додає regression test і створює commit:

Підказка: якщо commit message швидко перетворити на пункт changelog або пояснення в PR, він зазвичай написаний добре.== Хороші практики Commit == Поширені типи:

Проста аналогія: staging area — це кошик перед касою: ви вирішуєте, що саме піде в наступний commit. fix: correct invoice rounding

Хороше commit message оптимізує:

Це оптимізує reviewer-у відрізнити:

Отримано з https://wiki.kyiv.ua/index.php?title=Commit&oldid=1404