Mini poradnik o gicie na podstawie własnego używania i świetnej książki:
https://git-scm.com/book/en/v2Git jest sposobem na zarządzanie wersjami softu/projektu. Najprostszy git jest lokalny, nie wymaga żadnego serwera i można sobie robić wersjonowanie bez łaski. Najprostszy git nie polega na żadnych klientach graficznych i hostingach. Jest całkowicie lokalny i używany z linii komend. Ja dodatkowo katalogi z projektami trzymam na dropboxie, więc mam z automatu backup i archiwizację.
Uwaga: poradnik dla początkujących. Nie ma tu o pracy w zespole, repozytoriach rozproszonych, zarządzaniu wielkimi projektami.
Cel: wersjonowanie małego, własnego projektu w C, Eagle, Kicadzie, asemblerze, tak, żeby nie wyrywać sobie włosów z głowy jak coś pójdzie nie tak.
Dlatego polecam nauczenie się podstawowej składni command-line, bo używa się jej wtedy swobodnie przy każdym projekcie. Poznanie składni spowoduje, że praca w środowisku graficznym będzie łatwiejsza. Nigdy nie używałem nakładek graficznych na git-a. Uważam, że to przerost formy nad treścią.
Uważam, że to, co tu napisałem wystarcza do zarządzania 90% projektów.
Do dzieła!
Instalacja na systemach debianowych, jak ubuntu:
$ sudo apt-get install git-all
Na windzie jest inaczej, ściągamy instalkę stąd:
https://git-scm.com/download/winWiększość tego co jest poniżej, działa tak samo na linuxie i na windzie.
Po instalacji należy koniecznie zainicjować trzy rzeczy, imię, mail i edytor (można dać notepad.exe lub inny ulubiony) :
$ git config --global user.name "Tomek sq5rix"
$ git config --global user.email
ciacho@cukiernia.pl $ git config --global core.editor vim
I to tyle w temacie inicjalizacji.
Help też jest i działa tak:
$ git help config
Oczywiście można zamiast config dać dowolną komendę.
Teraz idziemy sobie do katalogu, gdzie siedzi sobie nasz projekt eclipse, eagle lub kicad, lub np. artykuł, praca na zaliczenie - cokolwiek, co piszemy i zapisujemy na dysk co jakiś czas.
Np.
$ cd avreclipse/migacz
$ git init
Powstaje katalog .git w naszym katalogu projektu, który trzyma wszystko. Jak nam baaaardzo nie pójdzie to można .git skasować.
Następnie dodajemy sobie te pliki, które chcemy śledzić. Powstaje wtedy gałąź master
$ git add .
Czyli wszystko chcemy śledzić, dokładamy wszystkie pliki na gałąź master.
Można sobie śledzić tylko wybrane pliki i katalogi np.
$ git add *.[ch]
Dodawanie jest rekurencyjne, więc pliki z katalogów nam wejdą jako śledzone. Nie dodajemy do śledzenia wynikowych plików binarnych, np. katalogu Release nie śledzimy.
Załóżmy, że ten projekt jest już w jakimś stanie, no powiedzmy beta 0.1
Komitujemy taką pierwszą wersję jako master. Ten master (nie mylić z majstrem z naszego forum) to jest początek pierwszej gałęzi.
Git w odróżnieniu od innych systemów, jak svn, nie ma pnia i gałęzi, pień lub gałąź główna nie jest główna, jest taka sama jak inne. Przyjęło się, źe pierwsza gałąź to master.
Komitowanie to takie jakby przycięcie gałęzi, żeby dalej nam mogła rosnąć, zapamiętanie stanu projektu, lub po to aby powstało tam rozgałęzienie.
$ git commit
Pojawia się nam edytor, w którym w pierwszej linijce dajemy opis naszych dokonań i potem zapisujemy. Można też bez edytora, tak:
$ git commit -m "to wersja pierwsza, beta"
Można jeszcze zatagować, tag to taki wskaźnik na jakieś miejsce na drzewie.
Tag pełny, który nam zapamięta cały stan:
$ git tag -a v-0.2 -m "wersja z dwoma diodami"
Lub tag lekki, pamięta tylko dane miejsce.
$ git tag v-0.2
Żeby zobaczyć swoje tagi:
$ git tag
Polecam również tworzenie sobie aliasów, żeby przyspieszyć stukanie:
$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status
Oczywiście te wszystkie rzeczy robimy podczas normalnej pracy eclipse'a czy tam Kicada. Eclipse sobie działa, normalnie tam kompilujemy itd.... Obok odpalamy zwykły terminal w którym sobie piszemy komendy gita.
Jak sobie popracujemy, i coś tam zmienimy, to możemy sobie zrobić drugi commit, lub poprawić stary (z tym to ostrożnie, bo nadpisujemy stary commit i nasze zmiany nadpisują stary tekst - nie będzie można się cofnąć)
Dołożenie plików do commita jest chyba pojęciowo najtrudniejsze - otóż istnieje taka przestrzeń "stage area"
Jak to działa:
Coś sobie piszemy w main.c i potem dodajemy do stage area.
$ git add main.c
Dokładamy plik main.c do stage area - w tym momencie! Jak coś tam jeszcze zapiszemy, zrobimy jakieś zmiany, to jeśli nie ponowimy git add main.c to te ostanie zmiany diabli wezmą.
Dlatego ja komituję zawsze tak:
$ git commit -a -m "dołożenie migającej diody"
To -a dokłada do commita wszystkie pliki, które są śledzone.
Nadpisanie poprzedniego, jakby przeniesienie commita, na przykład jak zapomnę dodać jakiegoś pliku, albo zrobię nieznacząca zmianę w pliku.
$ git commit --amend
W tym momencie przychodzi nam do głowy, żeby stworzyć drugą gałąź. Np. do jakiejś nowej funkcjonalności w naszym migaczu.
$ git branch druga_dioda
To nic nie robi poza stworzeniem kolejnej gałęzi. Cały czas jesteśmy na gałęzi master.
Możemy sobie dalej pracować na master i komitować.
Ale, kiedy nam przyjdzie do głowy popracować nad drugą diodą, to robimy:
$ git commit -a -m "wersja 0.2"
Co oznacza dołożenie drugiego commita z dodaniem wszystkich zmienionych plików, po to żeby zostawić porządek w plikach na gałęzi master.
Zwróćcie uwagę, że nowa gałąź druga_dioda wyrasta z wcześniejszego miejsca niż obecnie jesteśmy. Czyli będziemy pracować na kodzie poprzedniego commita, z momentu powstania gałęzi druga_dioda.
Teraz przełączymy gałąź na drugą diodę:
$ git checkout druga_dioda
To checkout stosujemy bardzo często, do przełączania się w inne miejsce na drzewie.
Zamiast dwóch komend, wystarczy jedna:
$ git checkout -b druga_dioda
Tworzy nową gałąź i od razu do niej przechodzi. Ja tego wolę używać, bo wtedy jestem na gałęzi identycznej z ostatnim commitem.
Dodamy do niej pliki, których chcemy pilnować:
$ git add *.c *.h
W tym czasie w eclipse będzie widać zmianę - pojawią się pliki, oczywiście jeśli są otwarte, ze stanem z momentu powstania gałęzi druga_dioda
Po zrobieniu zmian można je sobie skomitować.
$ git commit -a -m "odpalona druga dioda"
I tak dalej i tak dalej. Funkcja checkout przenosi wskaźnik HEAD na odpowiedni fragment drzewka, i można sobie pracować na kodzie z dowolnego miejsca. Ponieważ gałązki są bardzo "lekkie" można tworzyć ich dużo, i do woli merge'ować.
A merge'ujemy tak:
$ git checkout master
$ git merge druga_dioda
W ten sposób wszystkie zmiany wejdą do naszej "głównej" gałęzi i tam już pozostaną.
Oczywiście można merge'ować dowolne gałęzie. Czasem git zgłosi miszmasz w naszym merge'owaniu i wtedy trzeba mu pomóc skapować się które zmiany chcemy pozostawić. O tym też w książce dokładniej, a w skrócie:
$ git diff
Pokazuje zmiany, które powodują konflikty. Tu się czasem łamię, ale rzadko, i w ciężkich chwilach używam graficznego narzędzia diffmerge stąd:
https://sourcegear.com/diffmerge/Działa na wszystkim.
Zobaczenie, jak wygląda nasze drzewko, to dwie ważne komendy:
$ git status
$ git log
Warto sobie popatrzeć, co pokazują - status to stan bieżący, log to historia... Funkcja checkout pozwala na chodzenie po tej historii, po tagach i commitach.
Na tym koniec. To wszystko, co jest potrzebne do lokalnego używania gita i używania własnego wersjonowania kodu. Jest to łatwe i przyjemne, daje możliwość lepszego panowania nad swoim softem.
Zobaczcie dalej w książce, która jest podana na początku, jest tam o wiele dokładniej, również o pracy z serwerami zewnętrznymi.
Jeśli są pytania do prostej, lokalnej pracy w command line, to proszę bardzo o pytania i komentarze.
Kanał - ATNEL tech-forum
Zaloguj
Zarejestruj
Informacje o cookies
FAQ
Szukaj
?
