Git – bardzo duża zmiana/migracja/grzebanie w gównie – jak sobie poradzić

Posted on 21 April 2016 Updated on 21 April 2016

Zaletą GITa jest commitowanie lokalne krok po kroku. Taki powtarzający się w kółko schemat:

– kodujemy kawałek
– sprawdzamy czy działa
– commitujemy (dodatkowo dając coś mówiący opis)

Gdy to coś co zmieniamy jest duuuże i trudno ogarnialne bo będą występować sytuacje gdzie:
– doszliśmy do miejsca, które jest ślepą uliczką – trzeba się wrócić kilka commitów bo w ten sposób “się nie da”
– inna rzecz się wywaliła która nie powinna – wtedy możemy przejść wstecz historię lokalnych commitów i zobaczyc w którym miejscu coś się wywala (jeszcze lepsze jest szukanie połówkowe git-bisect)

Use cases

Podniesie do kolejnej wersji GoogleMaps – kolega miał kiedyś coś takiego. Na starej stronie było GoogleMaps api w wersji 1, a Google zarzucił już wsparcie. Trzeba było podnieść do wspieranej wersji. Kod był taki, że można się ciąć – zero reużywalności kodu, logika JavaScript zawarta na stronach ASP.NET Web Forms (brak oddzielnych plików *.js). Coś napisanego ponad dekadę temu, nieużywanego od lat o czym wszyscy chcieli zapomnieć, a tu klientowi się wysypało i trzeba zrobić. Bez chodzenia krok po kroku, commit po commicie nie wyobrażam sobie tego zadania.

Migracja do Entity Framework Code First – też krok po kroku, wiele rzeczy może nie zadziałać, Research, poprawanie, etc.

Z jakim kodem zakończyć?

Na koniec gdy juz mamy ostateczny efekt możemy zrobić kilka rzeczy
– zrobić z tego jeden wielki commit – wygląda na brute force, ale nie jest to taka zła opcja. Oczywiście przeglądamy taki commit czy nie powinniśmy czegoś poprawić czy wyrzucić.
– powiązać commity w sensowe kilka commitów zmieniających jakieś oddzielne componenty – jest to trudniejsze, bo wymaga wprawy w operowaniu gitem.