fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
8 minut

Notatki z “internal git training”


16.02.2012

Kilka dni temu miałem przyjemność poprowadzić w firmie wewnętrzne szkolenie/wstęp do Gita.

BTW, za swój osobisty sukces uważam fakt, że już po pierwszym miesiącu pracy dostałem szansę “oficjalnego” zaprezentowania zajebistości Gita programistom chłostanym dotychczas bezlitośnie przez TFSową kontrolę wersji witkami z doczepionymi haczykami na ryby po osolonych plecach. Efekt był dość prosty do przewidzenia: podobało się.

Poniżej wrzucam swoją listę tematów do poruszenia. Moim zdaniem są to najważniejsze elementy do pokazania w sensownym czasie nieprzekraczającym połowy dnia pracy, gdzie zostaje jeszcze sporo luzu na eksperymentowanie i demonstrowanie na żywo pewnych najczęściej spotykanych scenariuszy. Może ta lista posłuży komuś do wyjścia w swojej firmie z podobną inicjatywą, czyli zaprezentowania Gita szerszemu gronu? Gitersi wszystkich firm, łączmy się;).

 

Co to jest Git i dlaczego jest lepszy niż TFS:

  • rozproszony system kontroli wersji
  • każdy ma swoje pełne repozytorium
  • diff/log/… – wszystko lokalnie
  • commity – też lokalnie
  • komunikacja z centralnym serwerem (jedna z możliwości podzielenia się kodem z zespołem)
    • pull – pobranie najnowszego kodu
    • push – wysłanie własnych commitów
    • “remotes” – linki do zdalnych repozytorium
  • gałęzie
    • gałąź “główna” – master
    • lokalne gałęzie – całkowita swoboda w poruszaniu się i organizacji pracy
  • żadnych exclusive locks
  • świetny merge
  • śledzi zawartość plików, a nie pliki
    • stąd automatyczne wykrywa np. rename
  • (blog) Git – rozproszony system kontroli wersji (DVCS) – krótkie omówienie i garść linków
  • (blog) W czym Git jest lepszy od TFS?

Komendy do poruszania się po gicie:

  • pull – ściąga kod z centralnego serwera i łączy z naszym
  • push – wysyła nasz kod (lokalne commity) na centralny serwer
  • checkout
    • po podaniu nazwy gałęzi: przełącza working copy między gałęziami
    • z flagą ‘-b’ – tworzy nową gałąź
    • po podaniu nazwy pliku: ściąga plik z podanej wersji (bez podania wersji – ściąga z ostatniego commita -> usuwa “niezacommitowane” zmiany)
  • branch
    • listuje aktualne gałęzie
    • z flagą ‘-d’ – usuwa gałąź o podanej nazwie
  • help: git [command]–help
  • (blog) Git – początek – pierwsze kroki po instalacji gita

Indeks (“staging area”):

  • miejsce między working copy a commitem
  • “cache” zmian, które znajdą się w następnym commicie
  • pozwala na bardzo dokładną kontrolę nad tym co zostanie zacommitowane
  • można dowolnie manipulować zawartością indeksu, np zapisując tam tylko część pliku do commita

Komendy do working copy, indeksu i commitów:

  • add – dodanie zmian do indeksu
    • add -A – dodanie wszystkich zmian do indeksu
    • add -i – interactive add, dokładna kontrola nad tym co zostanie dodane do indeksu
    • add -i -> patch – dodawanie części zmian z danego pliku do indeksu
  • commit – stworzenie commita z aktualnego stanu indeksu
    • pierwsza linijka w commit msg – krótki opis, potem pusta linia, potem ew. dłuższy opis – tip dla narzędzi wyświetlających logi
  • clean – czyszczenie plików ‘untracked’
  • reset – czyszczenie indeksu
    • reset –hard – czyszczenie indeksu i working copy, coś jak “undo pending changes”
  • stash – zachowanie aktualnych zmian na później, poza indeksem i poza commitami (coś jak shelve, tylko lokalnie)

Struktura commitów

  • lokalne commity – lista podzielona na gałęzie
    • każdy commit jednoznacznie identyfikowany SHA1 ID
    • każdy commit można otagować
  • ostatni commit w gałęzi to HEAD
  • merge tworzy “merge commit” będący dzieckiem dwóch commitów
    • można zrobić merge bez tego, ale nie ma sensu w to teraz wnikać
  • można dowolnie nawigować się pomiędzy commitami (znając jego ID, nazwę bądź położenie relatywne do innego znanego commita, np końcówki gałęzi)
    • git checkout master^ – 1 commit przed HEAD master
    • git checkout master~4 – 4 commity przed HEAD master

Modyfikacja historii:

  • commit –amend – modyfikacja ostatniego commita
  • rebase – “nałożenie” jednej gałęzi na drugą gałąź
  • rebase -i – interactive rebase
    • reword
    • edit
    • squash
  • NIE WOLNO modyfikować historii już wysłanej na serwer (!!!)
    • standardowo git nie pozwoli tego zrobić, jeśli wysyłamy do innego repo gita…
    • … ale nie wiem jak zachowa się TFS
  • (blog) Modyfikacja historii w Gicie

Git-TFS:

  • workflow:
    • [master]
    • git tfs pull – mamy najnowszy kod z repo
    • git checkout -b our-branch-name – tworzymy gałąź do bieżących prac
    • git add/commit… – pracujemy
    • git add/commit… – pracujemy

      git add/commit… – pracujemy

    • git checkout master – powracamy do gałęzi głównej
    • git tfs pull – ściągamy najnowszy kod (w [master]zawsze mamy kod bez swoich modyfikacji)
    • git checkout our-branch-name – wracamy na naszą gałąź
    • git rebase master – “nakładamy” naszą gałąź na najnowszy kod z TFS (ew. radzimy sobie z merge – mi się tutaj jeszcze nie zdarzyło żebym musiał to robić)
    • wysyłamy zmiany do TFS
      • git tfs rcheckin -w [task id]– wypychamy nowe commity z naszej gałęzi do TFSa mówiąc z jakim taskiem ma skojarzyć; commit messages zostaną umieszczone jako komentarz do checkina
        • działanie “pod spodem”: push jednego commita -> pull -> rebase -> …
        • może kilka chwil potrwać
      • git tfs checkintool –build-default-comment
        • łączy wszystkie commity w jeden
    • git checkout master – powracamy do gałęzi głównej
    • git tfs pull – ściągamy do [master]a nasze zmiany (plus ewentualnie inne które wydarzyły się w tym czasie)
    • git branch -d our-branch-name – kasujemy naszą gałąź, nie jest już potrzebna (możemy skasować bo wszystkie zmiany z niej są w masterze, inaczej git by na to nie pozwolił)
  • (blog) git-tfs – lek na prawie całe zło

Narzędzia:

  • git bash (z aliasami gita lub autohotkeys)
  • tortoise git
    • używam do logów i diffów z total commandera
    • dla mnie osobiście najwygodniejsze
  • gitk
    • wbudowany log-viewer
    • pokazuje stan indeksu vs stan working copy
    • dla mnie mimo wszystko żółwik jest wygodniejszy
  • git gui
    • wbudowany ‘okienkowy klient’ do kontaktu z gitem
    • przydaje mi się tylko gdy odpalam raz na jakiś czas żeby zobaczyć czy pora na ‘cleanup’
      • sugeruje uruchomienie git gc jeśli jest taka potrzeba
  • git extensions for visual studio
    • testowałem dawno temu, ale okazało się że tego nie potrzebuję
      • VS jest wystarczająco wolny bez dodatkowych obciążeń
  • git source control provider
    • nie testowałem, ale j/w – nie potrzebuję; poza tym dodaje okna ‘pending changes’ etc… których nie chcę
  • nawigacja po narzędziach – u mnie
    • [win]+1 – total cmd (menu -> l -> enter = view log)
    • [win]+2 – vs
    • [win]+3 – git bash

Wow-factor:

  • git bisect – identyfikacja commita powodującego błąd w systemie, na przestrzeni długiej historii [blog]
  • git cherry-pick – przenoszenie jednego commita pomiędzy gałęziami
  • git reflog – historia WSZYSTKICH operacji

Linki:

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). Powered by ConvertKit
Notify of
Łukasz
Łukasz

Ja osobiście nie lubię bawić sie w komendy co mnie odrzucało od poznania GIT’a. Jednak znalazłem sobie ciekawe połączenie GIT i TortoiseHg, np taka pokazówka:

http://tortoisehg.bitbucket.org/manual/2.1/nonhg.html#hg-git-git
http://jamesmckay.net/2010/06/tortoisehg-as-a-github-client-on-windows/

i mam można śmigać :)

procent

Łukasz,
Do gita też jest tortoise. A linię komend mimo wszystko polecam wypróbować, też się wzbraniałem początkowo.

Piotr
Piotr

Linia poleceń jest niezła, oprócz poruszania się po historii za pomocą strzałek, masz jeszcze takie udogodnienia:
– wpisujesz polecenie, potem Alt-. (które można powtarzać) i wklejany jest ostatni argument poprzednich poleceń
– Wciskasz Ctrl-r i przełączasz się w tryb wyszukiwania w historii poleceń wstecz, wciskasz kilka liter i pojawia się całe polecenie, jeszcze raz ctrl-r i wyświetla kolejne dopasowania
Generalnie takich udogodnień w bashu jest sporo

Tadeusz
Tadeusz

Jak będzie wersja ankhsvn (lub inna darmowa) ale z dobrą obsługą GIT z wnętrza VS (co najmniej tak jak np. z serwerem od VisualSVN), wtedy zapewne, GIT będzie powszechny – a bez tego zapewne pozostanie niszą dla nielicznych.

procent

Tadeusz,
Tak jak napisałem i w tym poście, i w poprzednich, gita MOŻNA zintegrować z VS. Po prostu ja tego nie robię. Ale jest wymieniony we wpisie Source Control Provider ( http://visualstudiogallery.msdn.microsoft.com/63a7e40d-4d71-4fbb-a23b-d262124b8f4c ), są Git Extensions ( http://code.google.com/p/gitextensions/ ). Zachęcam do zapoznania się.
I BTW, git JEST powszechny. Tylko nie aż tak jak powinien być.

somekind

Czarne okno na którym skupia się Maciej, to naprawdę nie jest jedyny sposób na połączenie git i VS. Od paru lat używam Git Extensions i Git Source Control Provider, są to całkiem zgrabne i wygodne narzędzia, dobrze integrujące się z Visual Studio. Wszystko można w nich wygodnie obejrzeć, skonfigurować i wykonać korzystając z przyjaznego interfejsu graficznego. (Ciekawe jak w konsoli przegląda się drzewo plików. :P) Jeśli ja daję radę, to każdy da radę. Nie sądzę, żeby AnkhSVN było w czymś lepsze od GE i GSCP (poza nazwą ;)), a używanie SVN to jakiś masochizm jest. Jeden z setek dni spędzonych… Read more »

Moja książka

Facebook

Zobacz również