Нова задача не завжди починається тоді, коли попередня робота вже акуратно закомічена.
У локальній branch можуть залишатися незавершені tracked і untracked files, але нову feature branch потрібно створити прямо зараз від актуального origin/master.
У такій ситуації я не використовую reset --hard і не створюю нову branch поверх поточного WIP. Я спочатку безпечно відкладаю зміни, оновлюю remote refs і тільки тоді створюю нову branch.
Спочатку я перевіряю, де знаходиться WIP
git branch --show-currentgit status --shortПеред stash я хочу точно знати назву branch, до якої належить незавершена робота.
git status --short також показує, чи є нові untracked files. Це важливо для наступної команди.
WIP я відкладаю через stash разом з untracked files
git stash push \ -u \ -m "wip-before-new-feature"Ключ -u додає untracked files. Без нього нові файли можуть залишитися в working tree й випадково перейти в нову задачу.
Повідомлення stash теж важливе: через кілька днів зрозуміла назва корисніша за пам’ять про те, що саме лежало в stash@{0}.
Після stash я перевіряю, що working tree чистий
git status --shortgit stash list | headПеред новою branch git status --short має бути порожнім.
Одночасно я перевіряю, що stash справді з’явився в списку. Це проста перевірка перед тим, як перейти до іншої задачі.
Далі я оновлюю origin/master через fetch
git fetch origingit fetch origin дає мені актуальний origin/master, але не змінює історію незавершеної branch.
Для цього сценарію це краще, ніж спочатку намагатися оновити локальний master.
Нову feature branch я створюю прямо від origin/master
git switch \ -c feature/new-task \ origin/masterЦя команда не залежить від того, наскільки актуальний локальний master.
Нова branch починається саме від commit, на який після fetch вказує origin/master.
Я перевіряю, що нова branch справді чиста
git branch --show-currentgit status --short git rev-parse HEADgit rev-parse origin/masterДва однакові SHA підтверджують правильну базу.
Порожній git status --short підтверджує інше: старий WIP не потрапив у нову задачу.
Увесь workflow можна виконати послідовно
git branch --show-currentgit status --short git stash push \ -u \ -m "wip-before-new-feature" git status --shortgit stash list | head git fetch origin git switch \ -c feature/new-task \ origin/master Старий stash не треба застосовувати до нової branch
Stash у цьому workflow потрібен не для перенесення WIP у нову задачу.
Він потрібен, щоб стара робота залишилася окремо. Якщо одразу виконати git stash pop у feature/new-task, чиста межа між задачами зникне.
До старої роботи я повертаюся на її original branch
git switch feature/old-task git stash list git stash apply stash@{0} git diffgit status --short # Only after verification:git stash drop stash@{0}Я віддаю перевагу stash apply перед stash pop, коли повертаю важливий WIP.
Apply залишає stash у списку. Якщо виник конфлікт або я вибрала не той запис, резервна копія ще існує.
Після перевірки diff і status конкретний stash можна видалити окремо.
Чому reset --hard тут не потрібен
git reset --hard призначений для зміни HEAD, index і working tree. Він може знищити незбережені tracked changes.
У цьому сценарії я не хочу знищувати стару роботу. Я хочу тимчасово відкласти її. Тому stash точніше відповідає наміру.
Чому я не зобов’язана спочатку оновлювати локальний master
Після git fetch origin актуальний remote ref уже є локально.
Команда git switch -c feature/new-task origin/master прямо використовує його як базу. Оновлення локального master можна зробити окремо, коли воно справді потрібне.
Чиста branch і чистий diff мають одну мету
У матеріалі про git restore -p і чистий diff я показувала, як прибрати зайві локальні зміни й залишити лише потрібну частину diff.
Тут принцип той самий на рівні задач: одна feature branch повинна містити одну зрозумілу роботу, а незавершені зміни іншої задачі не повинні випадково потрапляти в її історію.
Моя коротка перевірка перед новою feature branch
- Я знаю, на якій branch знаходиться WIP.
- Tracked і untracked changes збережені через
stash -u. - Working tree чистий.
git fetch originуже виконаний.- Нова branch створюється прямо від
origin/master. - HEAD збігається з
origin/masterна момент створення. - Старий stash не застосовується до нової задачі.
Я зберігаю межу між двома задачами
Цей workflow вирішує дві задачі одночасно: старий WIP не губиться, а нова feature branch отримує чисту й актуальну базу.
Stash зберігає стару роботу. Fetch оновлює remote refs. Нова branch стартує прямо від origin/master. Мені не потрібен destructive reset і не потрібно змішувати дві задачі.
Нова задача не повинна успадковувати незавершений diff старої. Я зберігаю WIP окремо й створюю feature branch від конкретного актуального remote commit.
