- Programy↵
- Zewnętrzne repozytorium↵
- Komendy↵
- Jak zacząć↵
- Dodawanie zmian / tworzenie branchy↵
- Mergowanie (łączenie branchy)↵
- Tagowanie (oznaczanie wersji)↵
- Dokumentacja↵
- Ciekawostka↵
Programy wróć↵
- http://git-scm.com/downloads- używam i polecam
- https://code.google.com/p/tortoisegit
- http://www.sourcetreeapp.com
- http://www.syntevo.com/smartgit
Zewnętrzne repozytorium wróć↵
- https://bitbucket.org
- https://github.com
- lub jakiś własny gitlab, ale to już wyższa szkoła jazdy, no i potrzeba tutaj serwera
Komendy wróć↵
- git init - inicjalizacja gita w istniejącym katalogu, inaczej tworzenie repozytorium lokalnego
- git clone ŹRÓDŁO ŚCIEZKA - kopiuje już istniejące repozytorium z jakiegoś serwera
- git status - pokazuje status plików w katalogu z repozytorium, czyli czy coś zostało zmienione/dodane
- git add NAZWA_PLIKU - dodaje plik/i tak jakby na stos, które potem zostaną dodane do komita. Jak w nazwie pliku da się . lub --all to doda wszystkie zmiany
- git commit -m 'Krótka treść komita, czyli chociażby co zostało zmienione' - dodaje zmiany do lokalnego repozytorium
- git remote add NAZWA_WŁASNA ŹRÓDŁO - przypisuje repozytorium zewnętrzne do jakiejś nazwy, nazwa najczęściej używana to chyba "origin", ale tutaj nie ma ograniczeń, dodatkowo da się też pod jedną nazwę dodawać kilka repozytoriów
- git push NAZWA_WŁASNA NAZWA_BRANCHU - wypycha naszego brancha ze wszystkimi zakomitowanymi zmianami do repozytorium zewnętrznego, czyli tak jakby merguje nasze zmiany do repozytorium zewnętrznego
- git pull - aktualizuje branch na którym aktualnie jesteśmy do tego co jest na repozytorium zewnętrznym, czyli tak jakby merguje to co jest na zewnętrznym repozytorium do tego co mamy u siebie
- git checkout NAZWA_BRANCHA - przerzucamy się na inny branch, jeśli oczywiście taki będzie istniał w naszym repozytorium, ale jeśli dodamy do komendy -b, to wtedy w razie czego utworzy nam branch o podanej nazwie
- git branch - wyświetla listę branchy
- git tag - wyświetla listę tagów
- git tag NAZWA_TAGU - dodaje tag do brancha (a nawet bardziej do komita) na którym aktualnie jesteśmy
- git push NAZWA_WŁASNA NAZWA_TAGU - wypycha tag na zewnętrzne repozytorium, komenda dokładnie taka sama jak przy wypychaniu brancha
- git merge NAZWA_BRANCHU - merguje (czyli łączy) jakiś branch do brancha na którym aktualnie jesteśmy
- git remote prune NAZWA_WŁASNA - czyści zbędne nazwy branchy z repozytorium lokalnego, przydatne gdy często podpowiada nam (TAB w konsoli) branche, które już od dawna nie są nam potrzebne
- git reset --RÓŻNE_OPCJE - cofa zmiany do wskazanego miejsca (komita), w temacie nie będzie nic o tym, ale tutaj macie http://git-scm.com/docs/git-reseti http://git-scm.com/b...a-Cofanie-zmian
====================================================================
Jak zacząć wróć↵
Nowe repozytorium
- Tworzymy nasze repozytorium lokalne, czyli
git init
- Teraz w zależności od tego czy mamy już jakieś pliki:
- jeśli mamy: dodajemy je wszystkie lub część komendą
git add NAZWA_PLIKU
przypomnę, że jeśli chcemy dodać wszystkie pliki, które znajdują się w repozytorium, należy napisaćgit add .
lub teżgit add --all
teraz możemy przejść do kolejnych punktów - jeśli nie mamy: nic nie robimy, dopóki czegoś nie napiszemy, dodamy, itp. i tutaj w zasadzie kończy się to co możemy zrobić
- jeśli mamy: dodajemy je wszystkie lub część komendą
- Po dodaniu plików należy je zakomitować
git commit -m 'Jakiś opis, np. Pierwszy komit'
- Teraz możemy już zapchać nasze repozytorium razem ze wszystkimi zmianami na zewnętrzne repozytorium, ale żeby to zrobić, musimy najpierw je utworzyć na jakimś serwerze (patrzy tutaj↵), a następnie przypisać je do jakiejś nazwy, czyli
git remote add NAZWA_WŁASNA ŹRÓDŁO
- I teraz wystarczy
git push NAZWA_WŁASNA NAZWA_GŁÓWNEGO_BRANCHA
aby zapchać. Oczywiście da się też zapychać wszystkie branche, ale to już sami poszukajcie
Tutaj wywołujemy jedynie komendę
git clone ŹRÓDŁO ŚCIEŻKAgdzie źródłem jest link do zewnętrznego repozytorium, a ścieżka to po prostu położenie folderu w naszym komputerze, do którego ma skopiować repozytorium, nie podając ścieżki git sam utworzy nazwę folderu.
====================================================================
Dodawanie zmian / tworzenie branchy wróć↵
Z poprzedniego punktu już mniej więcej wiadomo jak się komituje
git add . git commit -m 'Opis'jest też krótsza wersja
git commit -am 'Opis'ale należy zawsze pamiętać o tym, że nie zawsze chcemy komitować wszystkich zmian, a wtedy przydaje się komenda
git statusktóra wyświetla nam wszystkie zmiany (razem z nazwami plików) jakie zostały wprowadzone od ostatniego komita.
Dobrą praktyką jest częste komitowanie, bo dużo łatwiej jest dobrać opis jeśli dodamy, zmienimy, czy też usuniemy kilka linijek, które były za coś tam konkretnie odpowiedzialne, niż jakbyśmy dali jednego komita na cały dzień.
Gdy chcemy dodać jakieś zmiany to dobrą praktyką jest także tworzenie nowego brancha. Nie jest to wymagane, szczególnie jeśli piszemy coś sami, a jeszcze tym bardziej, jeśli piszemy coś nowego, chociażby ja pisząc pracę inżynierską (wszystko nowe) nie robię branchy, bo nie widzę takiej potrzeby.
Nowe branche tworzymy za pomocą komendy
git checkout -b NAZWA_BRANCHAktóra utworzy nowy branch, a następnie przerzuci nas do niego. Można też
git branch NAZWA_BRANCHA git checkout NAZWA_BRANCHAale po co?
Przy tworzeniu brancha należy zwrócić uwagę na to gdzie jesteśmy, czyli na którym branchu jesteśmy aktualnie, bo w tym momencie będzie się tworzyć nowa "gałąź" ze wszystkimi plikami, które są w tym branchu (na którym aktualnie jesteśmy).
====================================================================
Mergowanie wróć↵
Jeśli przy zmianach tworzyliśmy nowy branch, to po zakończeniu pracy nad daną zmianą, należy zmergować brancha ze zmianami do naszego głównego brancha, a można to zrobić przynajmniej na dwa sposoby, czyli:
- mergujemy lokalnie nasze zmiany do głównego brancha, czyli najpierw przenosimy się na ten główny branch
git checkout NAZWA_GŁÓWNEGO_BRANCHA
a następniegit merge NAZWA_BRANCHA_ZE_ZMIANAMI
teraz git zazwyczaj wykona robotę samodzielnie i nasze zmiany będą już na głównym branchu, ale czasami zdarzają się konflikty, które trzeba już samemu rozwiązać (patrz dalej↵). Po mergu wystarczy terazgit push NAZWA_WŁASNA NAZWA_GŁÓWNEGO_BRANCHA
- mergujemy na zewnętrznym serwerze, czyli najpierw wysyłamy nasz branch ze zmianymi
git push NAZWA_WŁASNA NAZWA_BRANCHA_ZE_ZMIANAMI
a potem tworzymy na serwerze pull/merge requesta, który oczywiście trzeba będzie zaakceptować, ale zanim zaakceptujemy możemy dokładnie przejrzeć jakie zmiany zostały wprowadzone. Przeglądać zmiany można także lokalnie, ale to już nie wygląda tak ładnie, ale w każdym razie robimy to komendągit diff NAZWA_BRANCHA
Jeśli tutaj będą jakieś konflikty, to trzeba będzie je rozwiązać lokalnie, czyli najpierw przerzucamy się na główny branchgit checkout NAZWA_GŁÓWNEGO_BRANCHA
aktualizujemy gogit pull
następnie znowu przechodzimy do brancha ze zmianami i wtedy mergujemy go z głównym, czyligit merge NAZWA_GŁÓWNEGO_BRANCHA
i teraz zapewne wywali nam konflikty, które będziemy musieli rozwiązać (patrz dalej↵). Po rozwiązaniu konfliktów jeszcze raz wypychamy naszego brancha ze zmianami do repozytorium zewnętrznego i ponawiamy mergowanie na serwerze.
Do rozwiązywania konfliktów są różne narzędzia, ale najdokładniej zrobimy to chyba ręcznie, dlatego też krótko opiszę jak to się robi.
Jeśli naszym oczom ukaże się jakiś konflikt, to najważniejsze, żeby nie panikować, bo to nic strasznego. Pierwsze co robimy, to wywołujemy komendę
git statusi tutaj (na czerwono) pod "Unmerged paths:" ukarzą nam się pliki, które mają konflikt. Otwieramy kolejno każdy plik z konfliktem i szukamy linijek ze znakami
<<<<<<<to co jest pod tą linijką i nad najbliższą
>>>>>>>to jest kod, który należy edytować. Po środku tych linijek mamy
=======co oddziela nam dwie różne wersje. Zazwyczaj rozwiązanie konfliktu sprowadza się do wybrania kodu nad lub pod
=======czyli tego, który jest najbardziej aktualny, ale czasami konflikt jest bardziej złożony, wtedy trzeba po prostu te dwa kawałki kodu ze sobą odpowiednio połączyć, oczywiście tutaj już każdy przypadek należy traktować indywidualnie, dlatego nie ma na to jednego rozwiązania.
Po rozwiązaniu konfliktów należy dodać pliki, które edytowaliśmy
git add .a potem zakomitować
git commit -m 'Merge'i na tym koniec konfliktów.
====================================================================
Tagowanie wróć↵
O tagowaniu będzie krótko, bo sam używam tego tylko w pluginach, żeby tagować wersje. Tagowanie to generalnie dodatkowy opis jakiegoś komita. Najprostszy sposób na dodanie tagu, to po prostu
git tag NAZWA_TAGUi to przypisze nam tag do aktualnego miejsca gdzie jesteśmy w naszym repozytorium. Teraz aby tag był widoczny także na repozytorium zewnętrznym, to wypychamy go dokładnie w taki sam sposób, jak to się robi przy branchach, czyli
git push NAZWA_WŁASNA NAZWA_TAGU====================================================================
Dokumentacja wróć↵====================================================================
Ciekawostka wróć↵
Jak może już wiecie, każdy komit ma jakiś swój numer i tutaj zauważyłem pewną rzecz, że komit zachowuje się praktycznie tak samo jak branch, można z nim robić chyba wszystko to co z branchem, czyli chociażby wywołać komendę
git checkout NUMER_KOMITAzresztą dokładnie to samo jest z tagami. Ogólnie fajna opcja, można porównywać, mergować, czy przeglądać każdy komit, tag, branch.
Aliasy
https://git.wiki.ker...dex.php/Aliases
http://stackoverflow...commands-in-git
====================================================================
Jeśli macie jakieś pytania, to pytać śmiało, postaram się odpowiadać jak tylko będę umiał. Od razu zaznaczam, że nie jestem jakimś pro ogarem z gita, ale mniej więcej tyle co tutaj opisałem, wystarcza.