Kontrola Wersji

Jesteś w trakcie zmian w trzech plikach na feature branchu, nic jeszcze nie zacommitowane, gdy kolega pisze o null-pointerze, który wywala produkcję. Standardowy ruch to git stash, checkout na main, poprawka, push, a potem git stash pop w nadziei, że nic w twojej niedokończonej funkcjonalności nie zależało od plików, od których właśnie odszedłeś. git worktree pomija całą tę żonglerkę. Robi checkout brancha z hotfixem do drugiego folderu, obok twojego feature brancha, a oba korzystają z tego samego repozytorium. ...

Testy są zielone od trzech tygodni. Dziś npm test pada na asercji, która nie ma nic wspólnego z tym, co właśnie zmieniłeś, a git log v1.4.0..HEAD pokazuje 340 commitów od czterech osób od ostatniego release’a, o którym ktoś był pewien, że działa. Przeczytanie każdego diffa kosztuje cały dzień. Losowe przełączanie się między commitami idzie szybciej, ale wciąż nie jest planem. git bisect zamienia to w wyszukiwanie binarne. Podajesz mu jeden commit, o którym wiesz, że jest dobry, i jeden, o którym wiesz, że jest zepsuty; narzędzie robi checkout commita w połowie drogi między nimi i czeka, aż przetestujesz właśnie ten commit i zgłosisz wynik. Każda odpowiedź zmniejsza zakres o połowę. 340 commitów da się rozstrzygnąć w maksymalnie 9 testach, bo 2^9 = 512. ...

Robisz pull najnowszego main, a Git zatrzymuje się z CONFLICT (content): Merge conflict in checkout.js. Rozwiązujesz konflikt, a w logu pojawia się commit o nazwie Merge branch 'main' into feature/checkout, leżący na trzech commitach, które faktycznie napisałeś. Cztery commity, jedna prawdziwa zmiana. Kolega, który za miesiąc przeczyta tę historię, nie ma szans rozpoznać, który jest który. git merge i git rebase odpowiadają na to samo pytanie: jak zaktualizować swój branch o zmiany zrobione gdzieś indziej. Zostawiają za sobą bardzo różne ślady, a wybranie złego na wspólnym branchu robi realną szkodę. ...