Dziś przytrafiła mi się bardzo niemiła niespodzianka podczas pracy.
Kiedy na zakończenie dnia chciałem pchnąć zmiany do tfs za pomocą komendy
git tfs rcheckin
po uprzednim ściągnięciu wszystkiego za pomocą
git tfs pull
i rebase, nagle z niewiadomych przyczyn rcheckin zwrócił mi kod błędu 1 i wszedł w interaktywny rebase. Za nic nie wiedziałem co jest nie tak – brak też informacji o jaki pliki chodzi (albo ja ślepy tego nie zauważyłem). Tak czy siak, skończyło się na tym, że za pomocą:
git tfs checkintool
wrzuciłem to co trzeba i wykonałem merge na plikach w TFS (dziwne, że problem leżał w merge przy checkin).
Następnie na wszelki wypadek:
git tfs pull
otwarcie pliku solution w VS i sprawdzenie czy testy i wszystko działa. Ku memu zdziwieniu z pokrycia kodu 70% spadłem do 10%. Przy build dostawałem wyjątki, że brak plików itp. Solution się do nich odwoływało ale ich fizycznie nie było.
Więc szybko wykonałem komendę
git log –pretty=oneline
by znaleźć mój commit i jego SHA-1, ku mojemu zdziwieniu, mój ostatni commit był w logu trzy razy. Odpaliłem więc tool, który mi bardziej graficznie all pokaże – gitk.
Zacząłem szukać, który z tych trzech commitów, jest ten który zawierał moje zmiany. Żadnego takiego nie znalazłem (oczywiście, część zmian była wymieniona, ale nie te, które mnie interesowały, tak jakby w ogóle nie istniały). Popatrzyłem w historie command line i znalazłem swój commit i jago SHA-1. Odpaliłem ponownie git log i dalej swojego ID znaleźć nie mogłem. Zacząłem więc się zastanawiać co się z nim stało. A dokładniej co się stało z plikami, które zostały wtedy dodane.
Z pomocą przyszła komenda:
git log –all — **/fileName.ext
dopiero wtedy GIT pokazał mi commit, który znalazłem w historii command line – dziwne, że git log jak i gitk go nie wyświetlało, i nie rozumiem dlaczego :( może ktoś z was będzie wstanie pomóc.
Reszta – przywrócenie brakujących plików – poszła z górki i wszystko jest już w TFS.
Post jest bardziej ku pamięci w jaki sposób wybrnąć z takiej sytuacji, w szczególności, że nie udało mi się tego powtórzyć (zreprodukować błędu). Sam dalej nie wiem dokładnie jak to się stało, że takie coś zaszło – i to mnie trochę przeraża. Wolałbym osobiście wiedzieć dlaczego i czy to ja popełniłem błąd czy to jest bug w soft.
Tak czy siak, może się komuś ten post przydać. Mi dojście do tego zajęło ekstra 2h :(
Po 1) git reflog jest najlepszym przyjacielem zioma któremu coś "nie działa w git" :).
Po 2) błąd taki może się wydarzyć z kilku powodów, ja zaobserwowałem u siebie trzy: albo pliki są otwarte w VS albo masz problem z HDD albo skończył się RAM
Po 3) zawsze w takiej sytuacji możesz spróbować zrobić to "od nowa" czyli: git tfs fetch (tylko ściąga kod do tfs/default) a zaraz potem git rebase tfs/default (przebudowuje akutalny branch który chcesz pchnąć na podstawie najnowszych commitów zaaplikowanych przed wystąpieniem błędu)
dzieki :) o reflog jak zawsze zapominam, nie wiem czemu :( prawie nigdy go nie uzywam :)
co do 2 to w tym wypadku mhhh jak 16gb ram i 256ssd to za zamalo i za wolno to juz nie wiem jaki komp do tego potrzebuje ;)
zas co do 3, dzieki za wytlumaczenie tego, tak na wszelki wypadek by innym powiedziec.
najpierw abort na rebase -i
potem fetch
potem rebase
potem naprawic historie, moze byc potrzebny reset hard
jeszcze raz dzieki :)
Comments are closed.