Git - co zrobić gdy się scommituje za dużo zmian?

Posted by Piotr Sarnacki Tue, 07 Apr 2009 09:40:00 GMT

Jak zauważył słusznie Radarek w komentarzu taki sam efekt można uzyskać poleceniem git reset --mixed HEAD~1. W tym wypadku można by treść całego posta wyrzucić do kosza, ale zostawię dla potomnych, żeby można było zobaczyć jak trzeba się nagimnastykować jeżeli się nie zajrzy do dokumentacji ;-)

Czasami podczas pracy nad jakimiś większymi zmianami warto rozbić pracę na mniejsze commity. Zdarza mi się czasami dodać przełącznik -a z rozpędu, który commituje wszystkie zmiany. Najgorzej jest gdy wrzucam przy okazji nową wersję jakiegoś plugina do railsów. W takim wypadku zmiany w aplikacji są przeplatane zmianami w pluginie. Później gdy trzeba spojrzeć na coś w logach gita, może to dość znacznie utrudnić pracę.

Na szczęście git jest bardzo elastyczny i łatwo jest takie coś odwrócić.

Wyobraźmy sobie taką sytuację:


  # przechodzę do nowej gałęzi, żeby zaimplementować nowy feature
  git checkout -b feature_200

  #....
  # tutaj dużo zmian, między innymi dodanie 
  # nowego pluginu, uaktualnienie innego, 
  # zmiany w samym kodzie itp. itd.

  # a teraz chcemy scommitować tylko zmiany w 
  # danym pluginie:
  git add vendor/plugins/acts_as_foobar
  git commit -m "Nowa wersja acts_as_foobar kompatybilna z railsami 2.3" -a
  # oj... dodałem -a, scommitowały się też 
  # zmiany w kodzie

Co teraz? Nic trudnego :)


  # tworzymy patche względem mastera
  git format-patch master

W tym momencie powinno pojawić się sporo plików o nazwach na przykład:


0001-Nowa-wersja-acts_as_foobar-kompatybilna-zrailsami-2.3.patch
#... ewentualnie więcej
Teraz trzeba wyrzucić “zepsuty” commit: 

  git rebase -i HEAD~3

Teraz powinien otworzyć się edytor, w którym widnieją linijki zaczynające się od słowa pick. Kasujemy linijkę z niechcianym commitem (tutaj uwaga – jeżeli nie jesteście pewni, że wszystko gra, to najlepiej zrobić backup repo, po takim zabiegu commit po prostu zniknie). Po zapisaniu zmian commit powinien zostać wyrzucony z drzewka i można zaaplikować wcześniej stworzonego patcha:


git apply 0001-Nowa-wersja-acts_as_foobar-kompatybilna-zrailsami-2.3.patch

W tym momencie wszystko powinno wyglądać tak jak przed commitem – można teraz poprawić swój błąd.

Wiem, że to może się wydawać skomplikowane (szczególnie rebase), ale w praktyce zajmuje krótką chwilę, a dzięki takiemu zabiegowi nie ma bałaganu w repozytorium.

A może Wy macie jakieś ciekawe metody na rozwiązywanie problemów z gitem? Może inny sposób na powyższy problem?

Posted in  | Tags , ,  | 2 comments | no trackbacks

2 przydatne rzeczy w gicie

Posted by Piotr Sarnacki Tue, 03 Jun 2008 09:04:00 GMT

Usuwanie gałęzi ze zdalnego repozytorium:


git push {repository} :heads/{your_branch_here}

Usuwanie pliku z indexu bez usuwania go z systemu plików (przydatne gdy dodamy do .gitignore plik, który już istnieje):


git-update-index --force-remove sciezka/do/pliku

Taki szybki pościk ;-)

Posted in  | Tags , , , ,  | no comments | no trackbacks

Git

Posted by Piotr Sarnacki Tue, 08 Apr 2008 12:50:00 GMT

Jeżeli ktoś jeszcze nie zauważył społeczność frameworków Ruby on Rails i Merb przesiada się powoli na rozproszony system kontroli wersji Git. Na gita przechodzą Railsy, przeszedł już Merb, Rspec, sporo koderów wypuszczających popularne pluginy. Jednym słowem coś w tym musi być.

I rzeczywiście coś w tym jest.

O co chodzi? Jarosław Zabiełło na swoim blogu przedstawił kilka rozproszonych systemów kontroli wersji.

Jakie są zalety gita?

  • każdy posiadający kopię aplikacji posiada też całe repozytorium. Coś się rozwaliło? Trzeba zmienić serwer? Serwis,a na którym hostowałeś SVN’a padł? Smuteczek. Ale nie z gitem – repozytorium, które masz na dysku wystarczy.
  • Git jest dużo szybszy od SVNa
  • “Mobilność” – bardzo ważna dla mnie kwestia. Często wyjeżdżam i zdarza mi się pracować bez dostępu do netu. W przypadku SVNa musiałem wrzucić jeden mega commit z pierdylionem zmian. W przypadku gita commity lecą do repozytorium na dysku i później można je ewentualnie pchnąć (push) do publicznego repo.
  • Bardzo łatwa obsługa gałęzi. Pracując z gitem najlepiej wyrobić sobie nawyk tworzenia gałęzi przy każdej zmianie, lub grupie połączonych ze sobą zmian. Dzięki temu można pracować równolegle nad wieloma rzeczami nie zaśmiecając aplikacji. Później tylko łączymy gałęzie, które rzeczywiście są potrzebne, jeżeli coś nie wyjdzie można po prostu daną gałąź wyrzucić i po krzyku
  • dużo łatwiejsze wrzucanie zmian do projektów open source’owych, szczególnie z pomocą githuba (ale o tym za chwilę).

Ale kod leżący cały czas na dysku będzie mało przydatny. Dlatego można założyć sobie publiczne repozytorium. Stwierdziłem jakiś czas temu, że w trosce o swój czas, którego zawsze za mało, będę musiał ograniczyć wszelkie prace, których mogę stosunkowo łatwo uniknąć. Dlatego nie bawiłem się nawet w tworzenie swojego własnego publicznego repozytorium. Wygodniej skorzystać pracy innych ludzi ;-)

Obecnie najbardziej popularne (jedyne?) serwisy oferujące hosting repozytoriów gita to: GitHub i Gitorius. Gitorius jest w pełni darmowy, ale nie można na nim trzymać prywatnych repozytoriów. Na githubie za darmo można trzymać publiczne repozytoria (ogranicza nas 100mb – jeżeli chodzi o gita to bardzo dużo), za prywatne trzeba będzie zapłacić. Na razie można jeszcze korzystać za darmo, bo serwis jest w fazie beta.

Zarejestrowałem się na Githubie kilka dni temu i przeniosłem tam 2 ze swoich projektów. Github to bardzo fajny pomysł na stworzenie społeczności koderów (napisany oczywiście w railsach). Co daje taki serwis?

  • dostęp do rss’ów poszczególnych użytkowników, projektów, feed z wiadomościami z obserwowanych projektów
  • można jednym kliknięciem zrobić kopię aplikacji (fork) – jakie są tego korzyści opisał na blogu jeden z developerów merba Michael Ivey :Contributing to merb
  • można wysłać znajomym “pull request” – czyli prośbę o uaktualnienie, na przykład po ważnej aktualizacji

Dodatkowo dostajemy wszystkie zalety gita.

No to co? Przesiadka na jasną stronę mocy, z tego fuj fuj obleśnego i niefajnego SVNa, który tak chwaliłem kiedy się z nim zapoznałem ;-)

Posted in  | Tags , , , ,  | no comments | no trackbacks