← До списку лабораторних по Git
Повний опис / сценарій лабораторної:
Meta: навчитися обирати між git reset і git revert у залежності від того чи гілка вже поширена між розробниками.
Krok 1. Створити новий репозиторій для моделювання production.
Komandy: cd ~; mkdir prod73; cd prod73; git init; echo "stable" > app.txt; git add app.txt; git commit -m "Stable release"
Krok 2. Зробити коміт який додає функцію.
Komandy: echo "feature" >> app.txt; git add app.txt; git commit -m "Add feature that breaks"
Krok 3. Уявити що цей коміт уже запушений у загальний репозиторій.
Poyasnennya: зміну вже отримали інші розробники.
Krok 4. Показати log.
Komanda: git log --oneline
Krok 5. Застосувати git reset --hard HEAD~1 і подивитися на історію.
Komanda: git reset --hard HEAD~1; git log --oneline
Poyasnennya: коміт з функцією зник, але тільки локально.
Krok 6. Пояснити чому push такого reset у спільну гілку небезпечний.
Poyasnennya: колеги вже мають посилання на старий хеш і отримають конфлікт історії.
Krok 7. Відновити репозиторій і повторити сценарій з git revert.
Komandy: git reset --hard HEAD@{1}; git log --oneline; git revert HEAD
Poyasnennya: revert створює новий коміт який відміняє зміни попереднього.
Krok 8. Переглянути log після revert.
Komanda: git log --oneline
Poyasnennya: історія зберігається, додається коміт відкату.
Krok 9. Записати правило: для вже опублікованих гілок використовувати revert, а reset залишати для локальних гілок.
Krok 10. Mini zvit.
Zavdannya: наведи приклад коли все ж таки потрібно робити force push з reset у спільну гілку і як це координувати.