Інструменти

Повне пояснення

Що це і навіщо

У багатьох системах кодування (Unix, Linux) файл повинен закінчуватися символом нової лінії ( ). Якщо його немає, Git вважає, що останній рядок не завершений.

Ключові принципи

• EOF (End Of File) – символ, що сигналізує про кінець файлу.
• LF ( ) – символ нової лінії у Unix‑системах.
• CRLF (\r ) – символ нової лінії у Windows.
• Git порівнює файли по байтах; різниця в одному символі → конфлікт.

Як це працює

Під час git pull Git виконує мердж. Якщо в локальній копії файл закінчується без , а у віддаленому репозиторії – з ним, Git розглядає це як зміну в останньому рядку і позначає його конфліктом.

Практика й реалізація

• Перевірка: git diff --check покаже повідомлення про відсутність EOF.
• Виправлення: додайте новий рядок у файл, збережіть.
• Автоматизація: налаштуйте .gitattributes:

  * text=auto eol=lf
  

  Це змушує Git конвертувати нові лінії у LF при комміті.

Тестування

У CI можна додати скрипт:

git diff --check | grep -q 'missing newline' && exit 1 || exit 0

Оптимізація

• У VS Code можна увімкнути files.eol: ' ' у налаштуваннях.
• У Git можна встановити core.autocrlf:

  git config --global core.autocrlf input
  

Безпека

Немає безпосереднього впливу на безпеку, але конфлікти можуть затримувати релізи.

Альтернативи

• Використовувати pre-commit hook, що додає EOF.
• Працювати у середовищі, яке автоматично додає нову лінію.

Часті помилки

1. Відсутність EOF – описано.
2. Різні EOL у різних ОС – вирішується core.autocrlf.
3. Невірний .gitattributes – перевірте, що eol=lf застосовується.
4. Коміт без зміни – Git все одно додає EOF, якщо його немає.
5. Merge‑conflict у файлі без нової лінії – додаємо EOF.
6. Проблеми з CI – додайте git diff --check.
7. Неправильний текстовий редактор – налаштуйте EOL.
8. Відсутність pre-commit hook – створіть його.

Повне пояснення

Що це і навіщо

• git fetch отримує останні комміти з віддаленого репозиторію (наприклад, origin) і оновлює відповідні remote‑branches (origin/main, origin/feature).
• Після fetch можна перевірити нові зміни, порівняти їх з локальними гілками або об’єднати через git merge/rebase.

Ключові принципи

• fetch не змінює локальні гілки; оновлюється лише інформація про віддалені.
• Після fetch можна виконати git log origin/main..main для перегляду нових коммітів.

Як це працює

• Git встановлює з’єднання з віддаленим репозиторієм, запитує об’єкти (blob, tree, commit) і зберігає їх у локальній базі.
• Оновлюються лише ті об’єкти, яких ще немає локально (пакетний режим).

Практика й реалізація

# Отримати оновлення з віддаленого репозиторію
git fetch origin
# Перевірити нові комміти
git log HEAD..origin/main --oneline

Тестування

• У CI можна виконати git fetch --quiet перед тестами, щоб переконатися, що локальна копія актуальна.

Оптимізація запитів

• Використовуйте --depth 1 для shallow‑fetch, коли потрібен лише останній коміт.

Безпека

• fetch не виконує коду, тому ризик XSS/SQL‑injection мінімальний. Однак слід перевіряти віддалений репозиторій на довіру.

Особливості в контексті DevOps

• У CI/CD pipelines git fetch часто слідкує за оновленнями перед збіркою.
• Після fetch можна автоматично запускати git rebase або merge у робочому процесі.

Часті помилки

1. Відсутність прав на доступ – перевірити SSH‑ключі або HTTPS‑автентифікацію.
2. Невідповідність remote‑URL – git remote -v.
3. Виконання fetch у гілці, що не існує локально – спочатку створити гілку.
4. Використання git pull замість fetch + merge – це може створити непередбачувані конфлікти.
5. Відсутність origin – додати remote: git remote add origin <url>.
6. Проблеми з кешем – git gc --prune=now.
7. Невірний branch‑name – перевірити назву через git branch -a.
8. Відсутність оновлень – перевірити, чи є нові комміти на віддаленому репозиторії.

Cheatsheet

• git fetch <remote> – отримати оновлення.
• git fetch --all – всі remotes.
• git fetch <remote> <branch> – конкретну гілку.
• git log HEAD..origin/<branch> – нові комміти.

Повне пояснення

Що це і навіщо

Git hygiene — система правил, що допомагає підтримувати зрозумілу та передбачувану історію репозиторію. Це важливо для колективної розробки, коли кілька розробників працюють над однією базою коду.

Ключові принципи

• Feature‑branch: кожна нова функція або баг‑фікс розробляється в окремому гілці.
• Commit‑messages: короткий заголовок (≤50 символів) + розширений опис, що пояснює «що» і «чому».
• Rebase: перед merge виконуємо git rebase origin/main, щоб уникнути «множинних» merge‑commit.
• Squash: при завершенні задачі об’єднуємо всі коміти в один, щоб історія залишалася лінійною.
• Pull‑request review: код перевіряється колегами, що знижує кількість помилок.
• Tagging: релізи позначаються тегами, що полегшує повернення до стабільної версії.
• Branch cleanup: видаляємо локальні та віддалені гілки, що вже змерджено.

Як це працює

При git rebase коміти з feature‑branch «переходять» поверх останнього commit‑у main, що створює лінійну історію. Squash‑commit зменшує кількість commit‑ів, що полегшує читання.

Практика й реалізація

# Створюємо гілку
git checkout -b feature/add-login
# Робимо коміти
git commit -m "Add login route"
# Після завершення
git rebase main
git push -u origin feature/add-login

# Після review
git checkout main
git merge --squash feature/add-login
git commit -m "Add login route"

Тестування

Під час PR можна запускати CI‑тести (Jest, Cypress). Якщо тест не проходить, коміт з помилкою видаляється за допомогою git reset --soft HEAD~1.

Оптимізація

• Fast‑forward merge: git merge --ff-only для уникнення зайвих commit‑ів.
• Git hooks: pre-commit для перевірки форматування коду.

Безпека

Використовуємо git config --global user.email та user.name, щоб уникнути конфліктів авторства.

Особливості в контексті колективної роботи

• Protected branches: main/master захищені від прямого пушу.
• Code owners: визначаються відповідальні особи за певні директорії.

Часті помилки

1. Merge без rebase → дубльовані коміти.
2. Великий commit без опису → важко зрозуміти зміни.
3. Не видаляти stale branches → збільшує clutter.
4. Неправильний порядок rebase → конфлікти.
5. Відсутність review → баги в коді.
6. Неправильне використання tags → труднощі з релізами.
7. Пуш без fetch → конфлікти при push.
8. Використання git merge --no-ff без потреби → непотрібна історія.

Cheatsheet

• git checkout -b <branch> – створити та перейти.
• git rebase main – оновити гілку.
• git merge --squash <branch> – об’єднати коміти.
• git push -u origin <branch> – відправити гілку.
• git branch -d <branch> – видалити локальну гілку.
• git push origin --delete <branch> – видалити віддалену гілку.

Повне пояснення

Що це і навіщо

CI/CD — сукупність практик, що об’єднують автоматичне збірку, тестування та розгортання застосунків. Це зменшує час від коміту до релізу, підвищує якість коду і знижує ризик людських помилок.

Ключові принципи

• Continuous Integration: кожен коміт інтегрується в спільну гілку, запускаються unit‑тести та статичний аналіз.
• Continuous Delivery: після успішної CI збірка готова до розгортання, але реліз в продакшн може бути ручним.
• Continuous Deployment: розгортання в продакшн відбувається автоматично після проходження всіх тестів.

Як це працює

1. Пуш коду в репозиторій (Git).
2. CI‑система (наприклад, GitHub Actions, GitLab CI, Jenkins) запускає пайплайн: lint, build, unit‑тести.
3. Якщо всі етапи успішні, створюється artefact (Docker‑image, .jar, .zip).
4. CD‑система розгортає artefact на staging/production (Kubernetes, AWS ECS, Heroku).

Практика й реалізація

• GitHub Actions: on: push, jobs: build-test-deploy.
• GitLab CI: .gitlab-ci.yml з stages: build, test, deploy.
• Jenkins: Pipeline script з stage('Build'), stage('Test').

Тестування

• Unit: Jest, Mocha для JavaScript; JUnit для Java.
• Integration: Prisma migrations + test DB, TypeORM with SQLite in memory.

Оптимізація запитів

• Використовувати кешування (Redis), pagination, індекси.
• Підключати EXPLAIN для складних SQL‑запитів.

Безпека

• Secrets: зберігати в CI‑системі, не в репозиторії.
• RBAC: обмежити доступ до пайплайнів.

Особливості в контексті DevOps

• Infrastructure as Code: Terraform, CloudFormation.
• Observability: Prometheus + Grafana для моніторингу пайплайнів.

Часті помилки

1. Необхідність ручного підтвердження в CD.
2. Відсутність тестів → збій розгортання.
3. Неправильне налаштування secrets → витік даних.
4. Переважання CI без CD → повільний реліз.
5. Невикористання rollback‑плану.
6. Перенавантаження сервера через часті деплої.
7. Відсутність canary‑релізу → повний збій.
8. Неправильна конфігурація Docker‑image → неуспішний старт.

Cheatsheet

• git push origin main → тригер CI.
• docker build -t app:latest .
• kubectl apply -f deployment.yaml

Повне пояснення

Що це і навіщо

• package-lock.json створюється автоматично при першому виконанні npm install. Він містить дерево залежностей з точними SHA‑1 хешами, що дозволяє відтворювати однозначну структуру node_modules.

Ключові принципи

• Deterministic installs: однаковий lock‑файл → однакова інсталяція.
• Security: зберігає конкретні версії, що допомагає уникнути небажаних оновлень.
• Performance: npm може пропустити перевірку метаданих, якщо lock‑файл актуальний.

Як це працює

• При npm install npm читає package.json, шукає відповідні версії у registry, а потім порівнює їх з package-lock.json. Якщо збігаються, npm просто копіює пакети; якщо ні – оновлює lock‑файл.

Практика й реалізація

• У проекті з package.json:

{
  "name": "demo",
  "version": "1.0.0",
  "dependencies": {
    "express": "^4.18.2"
  }
}

Після npm install створюється package-lock.json, що виглядає так:

{
  "name": "demo",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {"dependencies":{"express":"4.18.2"}},
    "node_modules/express": {"version":"4.18.2", ...}
  }
}

Тестування

• У CI можна перевірити, що package-lock.json не змінився: git diff --exit-code package-lock.json.

Оптимізація запитів

• Не застосовується безпосередньо, але використання lock‑файлу зменшує час інсталяції через кешування.

Безпека

• Замість npm install --save-dev використовуйте --save-prod, щоб уникнути встановлення небажаних dev‑залежностей у продакшн.

Особливості в контексті DevOps

• CI/CD пайплайни часто включають npm ci, що читає лише package-lock.json, пропускаючи пакетний менеджер і забезпечуючи швидку та відтворювану інсталяцію.

Часті помилки

• package-lock.json не синхронізовано з git → різні середовища отримують різні версії.
• Використання npm install --no-package-lock → lock‑файл не оновлюється.
• Застарілий npm (≤5) → lock‑файл не підтримується.

Cheatsheet

• npm install → створює/оновлює package-lock.json.
• npm ci → чиста інсталяція з використанням package-lock.json.
• git add package-lock.json → важливо комітити його в репозиторій.

Повне пояснення

Що це і навіщо

• npm install – загальна команда для встановлення залежностей. Вона читає package.json, шукає потрібні пакети, встановлює їх і оновлює package-lock.json (або npm-shrinkwrap.json). Це корисно під час розробки, коли треба додати нові пакети або оновити існуючі.

• npm ci (clean install) призначений для CI/CD. Команда читає лише package-lock.json і встановлює точні версії, що зберігаються в ньому. Якщо package-lock.json не збігається з package.json, команда завершує роботу з помилкою. Це гарантує, що середовище збігається між різними машинами і часом.

Ключові принципи/терміни

• package-lock.json – файл, що фіксує точні версії залежностей.
• npm ci → чиста інсталяція: видаляє папку node_modules, встановлює залежності з нуля.
• npm install → інсталяція/оновлення: додає нові пакети, оновлює package-lock.json.

Як це працює

• При npm install npm перевіряє package.json, шукає відповідні пакети в реєстрі, встановлює їх і оновлює package-lock.json.
• При npm ci npm перевіряє, що package-lock.json існує і відповідає package.json. Якщо так – видаляє node_modules і встановлює залежності згідно з блоком lockfileVersion.

Практика й реалізація

• У локальній розробці: npm install (або yarn add).
• У CI‑пайплайнах: npm ci після клонування репозиторію.

Тестування

• У Jest‑тестах можна перевірити, що npm ci не змінює package-lock.json: після запуску npm ci файл залишається незмінним.

Оптимізація запитів

• npm ci швидше, бо пропускає кроки перевірки та оновлення lockfile.

Безпека

• Використання npm ci зменшує ризик непередбачуваних оновлень, що може викликати проблеми в продакшн‑середовищі.

Особливості у контексті DevOps

• npm ci підтримується в Docker‑build, GitHub Actions, GitLab CI тощо.

Часті помилки

• npm ci завершує роботу, якщо package-lock.json не синхронізований з package.json. Рішення: запустити npm install локально, закомітити оновлений lockfile.
• Якщо node_modules вже існує, npm ci видаляє його; це може зайняти час у великих проектах.

Cheatsheet

• npm install – розробка, додавання/оновлення.
• npm ci – CI/CD, стабільність, швидкість.

Повне пояснення

Бандлери, такі як Webpack, Rollup або Vite, беруть вихідний код, розбивають його на модулі (ES‑modules або CommonJS), аналізують залежності і формують фінальний бандл. Tree‑shaking видаляє не використаний код, а мінімізація (uglify/terser) зменшує розмір файлу. Source‑map пов’язує мінімізований код із оригінальним, що полегшує налагодження. Бандлери також підтримують лоадери для CSS, SVG, зображень тощо, що дозволяє інкапсулювати всі ресурси в один HTTP‑запит. У сучасних SPA це критично для швидкого старту, зменшення кількості запитів і підтримки кешування.

Повне пояснення

Модульне підключення – це принцип розбиття програми на незалежні частини, що спрощує підтримку і тестування. Бандлери збирають ці модулі в один або кілька файлів, що зменшує кількість HTTP‑запитів і дозволяють застосовувати оптимізації (tree shaking, code splitting). У Vite/webpack можна налаштувати loaders для різних типів файлів (JS, TS, CSS, images) і використовувати plugins для автогенерації HTML або підтримки HMR. Приклад конфігурації Vite показує, як вказати entry‑point і розпакувати залежності у bundle.

Повне пояснення

Що це і навіщо

• git merge об’єднує дві гілки, створюючи коміт‑мердж. Це корисно, коли потрібно зберегти історію розгалужень і бачити точку об’єднання.
• git rebase переміщує коміти однієї гілки поверх іншої, роблячи історію лінійною. Це зручно для чистого журналу перед пушем у спільний репозиторій.

Ключові принципи

• Merge: не змінює існуючі коміти, додає новий коміт‑мердж.
• Rebase: копіює коміти, змінюючи їхні SHA‑1, тому історія стає новою.

Як це працює

• При merge Git знаходить спільного предка, обчислює diff між гілками і створює новий коміт‑мердж.
• При rebase Git перебирає кожен коміт з «підкладної» гілки, застосовуючи його поверх базової гілки.

Практика й реалізація

• git merge feature – створює коміт‑мердж.
• git rebase main у гілці feature – переміщує її коміти поверх main.

Тестування

• Після merge можна перевірити git log --graph – видно вузол‑мердж.
• Після rebase лог стає лінійним, але треба переконатися, що ніхто не працював над тією ж гілкою.

Оптимізація та безпека

• Merge зберігає історію, що допомагає у відстеженні багів.
• Rebase робить історію чистішою, але може викликати конфлікти при спільній роботі.

Особливості в контексті DevOps

• У CI/CD pipelines часто використовують rebase для підготовки PR до merge.
• Merge використовується в GitHub Actions, коли потрібна історія об’єднання.

Часті помилки

• Після rebase не виконати git push --force-with-lease → конфлікти.
• Merge без вирішення конфліктів → некоректна історія.

Cheatsheet

• git merge <branch> – зберігає історію.
• git rebase <base> – лінійна історія, потребує force push.
• git rebase -i – інтерактивний rebase для редагування комітів.

Повне пояснення

Що це і навіщо

• Staging area (інша назва – index) слугує буфером між робочим каталогом і історією репозиторію. Вона дозволяє вибірково підготувати частину змін до комміту, що корисно при розділенні логічних оновлень.

Ключові принципи

• git add <файл> копіює поточний стан файлу у staging area.
• git status показує, які файли «staged» і готові до комміту.
• git reset <файл> видаляє файл з staging area, не змінюючи його у робочому каталозі.

Як це працює

• Git зберігає staging area у файлі .git/index. Кожен запис містить шлях, SHA‑1 хеш вмісту і метадані.
• При git commit Git створює новий tree‑об’єкт, що включає всі елементи з index, а потім commit‑об’єкт, який посилається на цей tree.

Практика й реалізація

• При розробці великого фічі можна додавати частини коду окремо: git add src/part1.js, git commit -m "Add part 1". Потім продовжити роботу і додати решту.
• Для швидкого скидання всього: git reset (soft) або git reset --hard.

Тестування

• У CI‑pipeline можна перевіряти, що git status повертає порожній індекс після виконання тестів: git diff --quiet HEAD.

Оптимізація та безпека

• Staging area допомагає уникнути випадкового комміту неперевірених змін.
• Під час роботи з гілками важливо пам’ятати, що git stash також використовує staging area для тимчасового зберігання.

Особливості в контексті Git

• Відмінність між git add -p (пошагове додавання) і повним git add ..
• Підтримка патчів: git apply --cached додає зміни до index без застосування їх у робочому каталозі.

Часті помилки

• Забудьте про git add → зміни не потрапляють у комміт.
• Використання git commit -a пропускає файли, що ще не були додані.
• Неправильне використання git reset --hard видаляє незбережені зміни.

Cheatsheet

• git add <файл> – додати файл.
• git reset <файл> – видалити з index.
• git status – перевірка стану.
• git commit -m "msg" – створити комміт з staged файлів.

Повне пояснення

Що це і навіщо Code review — це колективна перевірка коду, що допомагає виявляти баги, покращувати читабельність і підтримувати консистентність проекту. Це також інструмент навчання та передачі знань між розробниками.

Ключові принципи

• Об’єктивність: оцінка базується на фактах, а не на особистих вподобаннях.
• Фокус на функціональності: перевірка, чи працює код так, як очікується.
• Безпека: виявлення потенційних вразливостей (SQL‑ін’єкція, XSS тощо).
• Читабельність: код має бути зрозумілим і підтримуваним.
• Документованість: коментарі, опис змін і причини прийняття рішень.

Як це працює

1. Підготовка: автор створює pull request (PR) і додає опис змін.
2. Ревізія: ревьюер читає код, коментує в PR, задає питання.
3. Обговорення: автор відповідає на коментарі, вносить зміни.
4. Затвердження: коли всі коментарі вирішені, PR мержиться.

Способи вирішення конфліктів

• Об’єктивні критерії: посилання на код‑стайл, тестові кейси або вимоги.
• Діалог: відкритий обмін думками, без критики особистості.
• Медіація: залучення senior‑розробника або технічного лідера, якщо суперечка не вирішується.
• Документування рішення: запис у PR, щоб уникнути повторних конфліктів.

Практика й реалізація

• У GitHub/Bitbucket PR‑тема: «Add user authentication with JWT».
• Ревьюер додає коментарі: // TODO: validate email format.
• Автор змінює код, коментує // Fixed: added regex validation і закриває коментар.

Тестування

• Після merge CI запускає unit‑тести (Jest, Mocha) і linting.
• Якщо тест падає, ревьюер вказує на конкретний рядок.

Оптимізація процесу

• Checklists: список критеріїв (наприклад, security, performance).
• Timeboxing: обмежити час на review (наприклад, 1–2 години).
• Automated reviews: статичний аналіз (ESLint, SonarQube) допомагає виявити прості помилки.

Безпека

• Перевірка на SQL‑ін’єкцію, XSS, CSRF.
• Використання параметризованих запитів або ORM‑методів.

Особливості в контексті DevOps

• CI/CD pipeline автоматично перевіряє PR перед merge.
• Якщо конфлікт з мерджем, CI сигналізує про необхідність вирішення.

Часті помилки

1. Перегляд коду без тестів → баги залишаються.
2. Суб’єктивні коментарі → конфлікти.
3. Відсутність документації → непорозуміння.
4. Необхідність повторного merge після зміни PR → затримка релізу.
5. Перевантаження ревьюера → низька якість review.
6. Відсутність чітких критеріїв → різні інтерпретації.
7. Необхідність ручного мерджу → ризик конфліктів.
8. Відсутність автоматичних тестів → збільшення дефектів у продакшн.

Cheatsheet

• Review checklist: functionality, security, performance, readability.
• Conflict resolution: use git merge --no-ff, discuss in PR, document decision.
• Follow‑up questions: "Як ви перевірили безпеку цього endpoint?", "Чи є тест, що охоплює цей кейс?".