Git: система контролю версій
Git -- розподілена система контролю версій, створена Лінусом Торвальдсом у 2005 році. Відстежує зміни у файлах, дозволяє повертатися до попередніх версій, працювати кільком розробникам одночасно та об\'єднувати зміни. GitHub, GitLab та Bitbucket -- хмарні платформи для зберігання репозиторіїв, code review через Pull Requests та CI/CD. Git використовується у 95%+ програмних проєктів.
| Команда | Дія |
|---|---|
| git init | Ініціалізація нового репозиторію |
| git clone | Клонування віддаленого репозиторію |
| git add . | Додати всі зміни до staging area |
| git commit -m "" | Зафіксувати зміни з повідомленням |
| git push | Відправити коміти на сервер |
| git pull | Отримати та об\'єднати зміни |
| git branch / checkout | Створити / переключити гілку |
| git merge | Об\'єднати гілки |
Staging, commits та workflow
Git має три зони: Working Directory (змінені файли), Staging Area (підготовлені до коміту, git add), Repository (зафіксовані, git commit). Хороший коміт -- атомарний (одна логічна зміна) з описовим повідомленням: "feat: add user authentication" або "fix: resolve login redirect bug". Conventional Commits стандартизують формат: feat, fix, docs, style, refactor, test, chore. git stash тимчасово зберігає незафіксовані зміни.
Скасування змін
- git checkout -- file -- скасувати зміни файлу
- git reset HEAD file -- прибрати з staging
- git commit --amend -- змінити останній коміт
- git revert -- створити зворотний коміт
- git reset --hard -- повне скасування (небезпечно)
Pull Request workflow
- 1. Створити feature branch від main
- 2. Зробити зміни та коміти
- 3. Push branch на GitHub
- 4. Створити Pull Request
- 5. Code review та обговорення
- 6. Merge після approve
Merge, rebase та конфлікти
Merge створює merge-коміт, зберігаючи історію обох гілок. Rebase переносить коміти на вершину іншої гілки -- лінійна історія, але змінює хеші комітів (не використовувати для вже запушених гілок). Конфлікти виникають коли дві гілки змінили один файл у одному місці -- Git позначає конфлікт маркерами (<<<<<<, ======, >>>>>>), розробник вирішує вручну. .gitignore виключає файли з відстеження: node_modules, .env, build-артефакти.
За даними Stack Overflow Developer Survey (2025), Git використовують 97% професійних розробників, що робить його найпоширенішим інструментом контролю версій в історії. GitHub має понад 100 млн розробників та 420 млн репозиторіїв. Дослідження Google DORA підтверджує: команди з trunk-based development та частими комітами деплоять у 973 рази частіше з утричі нижчим відсотком помилок.
Git branching strategies визначають workflow команди: Git Flow (feature/develop/release/hotfix), GitHub Flow (main + feature branches, PR-based), Trunk-Based Development (часті коміти в main, feature flags). Конвенція комітів (Conventional Commits) стандартизує повідомлення: feat, fix, refactor, docs, chore. Git hooks автоматизують перевірки перед комітом: лінтинг, тести, формат коду. Rebase vs Merge: rebase створює лінійну історію, merge зберігає контекст розгалужень.
Про тест
Тест «Git та контроль версій» містить 20 питань про git commands, staging, branching, merge, rebase, конфлікти, Pull Request, .gitignore та GitHub workflow.
Також рекомендуємо: Linux, JavaScript, Python та Docker.