Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit df83b23

Browse files
Merge pull request #8 from DevLoversTeam/develop
Develop
2 parents 3a1d948 + 250932a commit df83b23

File tree

1 file changed

+336
-1
lines changed

1 file changed

+336
-1
lines changed

‎README.md‎

Lines changed: 336 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1405,7 +1405,342 @@ git blame -L 10,20 app.js # лише рядки з 10 по 20
14051405
</details>
14061406

14071407
<details>
1408-
<summary>51. ???</summary>
1408+
<summary>51. Що таке теги в Git і чим вони відрізняються від гілок?</summary>
1409+
1410+
#### GIT
1411+
1412+
- Тег — це фіксована позначка на конкретному коміті, зазвичай для релізів (v1.0,
1413+
v2.1).
1414+
1415+
- Гілка — це рухомий вказівник на останній коміт у лінії розробки, куди
1416+
додаються нові коміти.
1417+
1418+
#### Основні відмінності:
1419+
1420+
| Характеристика | Тег | Гілка |
1421+
| -------------- | ------------------ | ---------------------- |
1422+
| Рухливість | Нерухомий | Рухливий |
1423+
| Використання | Позначення релізів | Розробка нових функцій |
1424+
| Коміти | Не додаються нові | Додаються нові коміти |
1425+
1426+
#### Приклад створення тега:
1427+
1428+
```bash
1429+
git tag v1.0 git push origin v1.0
1430+
```
1431+
1432+
</details>
1433+
1434+
<details>
1435+
<summary>52. Як у Git створювати, видаляти та пушити теги?</summary>
1436+
1437+
#### GIT
1438+
1439+
**Створення тегів:**
1440+
1441+
- Lightweight тег:
1442+
1443+
```bash
1444+
git tag v1.0
1445+
```
1446+
1447+
- Annotated тег (з повідомленням):
1448+
1449+
```bash
1450+
git tag -a v1.0 -m "Release version 1.0"
1451+
```
1452+
1453+
**Видалення тегів:**
1454+
1455+
- Локально:
1456+
1457+
```bash
1458+
git tag -d v1.0
1459+
```
1460+
1461+
- Віддалено:
1462+
1463+
```bash
1464+
git push origin --delete tag v1.0
1465+
```
1466+
1467+
**Надсилання тегів на remote:**
1468+
1469+
- Один тег:
1470+
1471+
```bash
1472+
git push origin v1.0
1473+
```
1474+
1475+
- Всі теги:
1476+
1477+
```bash
1478+
git push origin --tags
1479+
```
1480+
1481+
</details>
1482+
1483+
<details>
1484+
<summary>53. Що таке семантичне версіонування і як його використовують у Git-тегах?</summary>
1485+
1486+
#### GIT
1487+
1488+
- Семантичне версіонування (SemVer) — це система нумерації версій у форматі
1489+
MAJOR.MINOR.PATCH, яка відображає характер змін у релізі:
1490+
1491+
- `MAJOR` — несумісні зміни API.
1492+
1493+
- `MINOR` — додані нові функції, сумісні з попередньою версією.
1494+
1495+
- `PATCH` — виправлення багів без зміни функціоналу.
1496+
1497+
- У Git-тегах використовують SemVer, щоб:
1498+
1499+
- Позначати релізи (v1.2.3).
1500+
1501+
- Легко відстежувати стабільність та сумісність версій.
1502+
1503+
- Інтегруватися з CI/CD для автоматичного деплою конкретних версій.
1504+
1505+
</details>
1506+
1507+
<details>
1508+
<summary>54. Як у Git перейти на конкретний тег?</summary>
1509+
1510+
#### GIT
1511+
1512+
- Теги самі по собі не є гілками, тому перехід на них робить репозиторій у
1513+
detached HEAD стані:
1514+
1515+
```bash
1516+
git checkout v1.0
1517+
```
1518+
1519+
- Або з новішим синтаксисом:
1520+
1521+
```bash
1522+
git switch --detach v1.0
1523+
```
1524+
1525+
📌 У цьому режимі можна переглядати код, збирати чи тестувати, але нові коміти
1526+
не будуть прив’язані до жодної гілки.
1527+
1528+
- Щоб працювати далі з тегу як із гілки:
1529+
1530+
```bash
1531+
git checkout -b release-1.0 v1.0
1532+
```
1533+
1534+
</details>
1535+
1536+
<details>
1537+
<summary>55. Як у Git створити реліз на основі тегу?</summary>
1538+
1539+
#### GIT
1540+
1541+
1. Створити тег на потрібному коміті:
1542+
1543+
```bash
1544+
git tag -a v1.0.0 -m "Release 1.0.0"
1545+
```
1546+
1547+
2. Надіслати тег у віддалений репозиторій:
1548+
1549+
```bash
1550+
git push origin v1.0.0
1551+
```
1552+
1553+
(або всі теги: git push origin --tags)
1554+
1555+
3. У системі керування кодом (GitHub/GitLab/Bitbucket) на основі цього тега
1556+
можна створити реліз:
1557+
1558+
- GitHub: вкладка Releases → Draft a new release → вибрати тег.
1559+
1560+
- Додати опис змін (changelog).
1561+
1562+
- Опублікувати реліз.
1563+
1564+
📌 Реліз із тегу зручний для CI/CD — можна налаштувати автоматичне збирання та
1565+
деплой за певними тегами.
1566+
1567+
</details>
1568+
1569+
<details>
1570+
<summary>56. Що таке Git submodule і в яких випадках його доцільно використовувати?</summary>
1571+
1572+
#### GIT
1573+
1574+
**Git submodule** — це механізм, що дозволяє вбудовувати один репозиторій у
1575+
інший як залежність. Він зберігає посилання на конкретний коміт іншого
1576+
репозиторію.
1577+
1578+
#### Використовують, коли:
1579+
1580+
- Є спільна бібліотека/модуль, який використовується в кількох проєктах.
1581+
1582+
- Потрібно зафіксувати залежність на певному коміті, а не останню версію.
1583+
1584+
- Хочеться уникнути копіювання коду між репозиторіями.
1585+
1586+
#### Приклад додавання підмодуля:
1587+
1588+
```bash
1589+
git submodule add https://github.com/example/lib.git libs/lib
1590+
git submodule update --init --recursive
1591+
```
1592+
1593+
❌ Мінуси: складніший workflow (оновлення вручну), можуть виникати проблеми при
1594+
клонуванні без --recursive.
1595+
1596+
</details>
1597+
1598+
<details>
1599+
<summary>57. Що таке Git hooks і для чого вони потрібні?</summary>
1600+
1601+
#### GIT
1602+
1603+
**Git hooks** — це скрипти, які автоматично виконуються при певних подіях у
1604+
репозиторії (наприклад, перед комітом, після злиття, перед пушем). Вони
1605+
зберігаються у .git/hooks.
1606+
1607+
#### Використання:
1608+
1609+
- Перевірка стилю коду / запуск linter перед git commit (pre-commit).
1610+
1611+
- Заборона пушу у main напряму (pre-push).
1612+
1613+
- Автоматичне оновлення залежностей або документації після злиття (post-merge).
1614+
1615+
- Генерація changelog з повідомлень комітів.
1616+
1617+
#### Приклад: pre-commit для перевірки ESLint:
1618+
1619+
```bash
1620+
#!/bin/sh
1621+
npm run lint
1622+
if [ $? -ne 0 ]; then
1623+
echo "Lint errors found. Commit aborted."
1624+
exit 1
1625+
fi
1626+
```
1627+
1628+
</details>
1629+
1630+
<details>
1631+
<summary>58. Як у Git об’єднати кілька комітів у один (squash)?</summary>
1632+
1633+
#### GIT
1634+
1635+
- **Squash** роблять через інтерактивне перебазування:
1636+
1637+
```bash
1638+
git rebase -i HEAD~N
1639+
```
1640+
1641+
- де N — кількість останніх комітів, які треба переглянути.
1642+
1643+
#### Далі в редакторі:
1644+
1645+
- залишаєш перший коміт як pick,
1646+
1647+
- для наступних змінюєш pick на squash (або s).
1648+
1649+
Після збереження — Git об’єднає коміти, запропонує відредагувати повідомлення.
1650+
1651+
#### Використання:
1652+
1653+
- очистка історії перед злиттям у main,
1654+
1655+
- зручний changelog,
1656+
1657+
- уникнення зайвих "дрібних" комітів.
1658+
1659+
</details>
1660+
1661+
<details>
1662+
<summary>59. Що таке git bisect і як із ним працювати?</summary>
1663+
1664+
#### GIT
1665+
1666+
- `git bisect` — це інструмент Git для бінарного пошуку коміту, який ввів баг.
1667+
Він автоматично звужує діапазон між `"good"` і `"bad"` комітами.
1668+
1669+
#### Використання:
1670+
1671+
1. Запустити:
1672+
1673+
```bash
1674+
git bisect start
1675+
git bisect bad # вказати коміт з багом
1676+
git bisect good <commit_hash> # вказати коміт, де все працювало
1677+
```
1678+
1679+
2. Git переключається на середній коміт. Ви тестуєте і кажете Git:
1680+
1681+
```bash
1682+
git bisect good # якщо багу немає
1683+
git bisect bad # якщо баг є
1684+
```
1685+
1686+
3. Повторює, доки не знайде проблемний коміт.
1687+
1688+
4. Завершення:
1689+
1690+
```bash
1691+
git bisect reset
1692+
```
1693+
1694+
Використовується для швидкого знаходження помилок у великих історіях проєкту.
1695+
1696+
</details>
1697+
1698+
<details>
1699+
<summary>60. Як вручну вирішити конфлікт при злитті в Git?</summary>
1700+
1701+
#### GIT
1702+
1703+
1. Виконати злиття:
1704+
1705+
```bash
1706+
git merge feature-branch
1707+
```
1708+
1709+
- Git зупиниться на конфліктах.
1710+
1711+
2. Відкрити файли з конфліктами — вони містять маркери:
1712+
1713+
```bash
1714+
<<<<<<< HEAD
1715+
код з поточної гілки
1716+
=======
1717+
код з feature-branch
1718+
>>>>>>> feature-branch
1719+
```
1720+
1721+
3. Вручну вибрати або об’єднати потрібні зміни, видалити маркери.
1722+
1723+
4. Позначити файл як вирішений:
1724+
1725+
```bash
1726+
git add <file>
1727+
```
1728+
1729+
5. Завершити злиття:
1730+
1731+
```bash
1732+
git commit
1733+
```
1734+
1735+
(якщо Git не зробив commit автоматично).
1736+
1737+
Порада: можна використовувати інструменти для merge (наприклад, VS Code,
1738+
IntelliJ, Meld).
1739+
1740+
</details>
1741+
1742+
<details>
1743+
<summary>61. ???</summary>
14091744

14101745
#### GIT
14111746

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /