Dzisiaj wstawię kilka najczęściej używanych zbiorów poleceń związanych z operowaniem na repozytoriach Gita. Szczerze przyznaję, że wpisuję je tutaj przede wszystkim dla siebie, żeby w razie czego mieć ściągawkę. A więc zaczynamy.

Zakładanie repozytorium

Założyć repozytorium możesz w lokalnym katalogu, w którym znajdują się Twoje pliki. Ten katalog stanie się wtedy tzw. kopią roboczą lub drzewem roboczym. Powstanie w nim też podkatalog .git, w którym zostanie założone repozytorium. Inne rozwiązanie to założenie samego repozytorium. Ponieważ nie będzie mu towarzyszyła żadna kopia robocza, a na początku będzie ono puste, to nazywa się je surowym, gołym, samoistnym lub bosym repozytorium (ang. bare). Takie repozytorium zazwyczaj zakłada się na jakimś komputerze, który będzie służył jako systtem kontroli wersji pozwalający wymieniać się kodem osobom, których komputery nie są cały czas podłączone do sieci, a chcą publikować wersje dla innych. Nic nie stoi na przeszkodzie, żeby utworzyć to repozytorium lokalnie – wtedy możesz synchronizować z nim repozytorium przypisane do Twojej kopii roboczej. Taka sytuacja może wystąpić, gdy mamy w systemie kilka osób, które powinny nad czymś wspólnie pracować i wszystkie mają założone konta.

Inicjowanie repozytorium w lokalnym katalogu z kodem

 cd katalog_projektu
 [ $(ls -1A | wc -l) -eq 0 ] && touch README
 git init
 git add .
 git commit -a -m 'Initial revision'

Inicjowanie pustego repozytorium

  git --bare init
  git update-server-info
  chmod ug+rx hook/{post-receive,post-update}

Uwaga: W razie gdyby usługa (np. Apache z modułem DAV) działała wykorzystując uprawnienia grupowego właściciela plików i katalogów, to wywołanie update-server-info pomaga synchronizować zmiany (bez niego klienci mogą ich nie zobaczyć, gdy zrobisz push do repozytorium), jednak przeszkadza, bo ustawia niedobre uprawnienia. Aby to naprawić trzeba do skryptu hook/post-receive dodać:

  git update-server-info
  chmod -R g+rwX branches info objects refs HEAD

Zdalne repozytorium

Zdalne repozytorium to takie samo repozytorium jak lokalne. Różnica jest tylko taka, że zazwyczaj nie jest do niego przypisana kopia robocza, no i oczywiście można się do niego dostać używając jakiegoś protokołu komunikacyjnego, np. SSH, DAV czy “czystego” protokołu Gita.

Klonowanie

Klonowanie pobiera całe repozytorium na Twój komputer, przy okazji tworząc kopię roboczą zawierającą najnowsze wersje zbiorów przypisane do zdalnej gałęzi o nazwie master. Gałęzie to po prostu alternatywne linie rozwoju zawartości repozytorium. Dzięki nim można pracować nad kodem czy inną treścią nie zakłócając rozwoju oryginalnego projektu. W stworzonej gałęzi programista może testować jakieś usprawnienia, a gdy okażą się dobre, może włączyć zmiany poczynione w gałęzi do głównej linii. Domyślnie istnieje zawsze jedna, podstawowa gałąź, której nazwa to właśnie master. Przykłady:

  git clone user@host:projekt.git              # over SSH
  git clone ssh://user@host/~user/projekt.git  # over SSH używając URI
  git clone http://user@host/~user/projekt.git # over DAV
  git clone git://host/projekt.git             # over Git

Gdy klonujesz jakieś repozytorium, to zakładany jest katalog z kopią roboczą, a wewnątrz niego katalog z lokalnym repozytorium o nazwie .git, w którym znajdziesz między innymi plik z ustawieniami o nazwie config. Zauważysz, że narzędzie wstawiło tam informacje dotyczące lokalizacji zdalnego repozytorium – chodzi o sekcje remote i branch. W sytuacjach, w których nie jest robione klonowanie takie informacje trzeba wpisywać ręcznie, a w zasadzie półautomatycznie (pomaga w tym polecenie Gita o nazwie config). Po co one są, po co są one? Ano po to, aby wykonując synchronizację, nie trzeba było za każdym razem podawać lokalnej i/lub zdalnej gałęzi.

Ustawienie namiarów na zdalne repozytorium

Git over SSH:

 git config remote.origin.url git@nazwadomeny.org:/katalog/projekt.git/
 git config branch.master.remote origin
 git config branch.master.merge refs/heads/master

DAV over HTTP:

 git config remote.origin.url http://user:hasło@nazwadomeny.org/katalog/projekt.git/
 git config branch.master.remote origin
 git config branch.master.merge refs/heads/master

PS: Oczywiście pola user i hasło można pominąć, jeśli nie jest wymagana autoryzacja.

Wysyłanie zmian z lokalnego do zdalnego repozytorium

 git commit
 git push origin master

Pobieranie zmian ze zdalnego repozytorium do drzewa roboczego

 git pull

PS: Gdy programistów jest więcej, to prawdopodobnie nie jest to o co Ci chodzi. Ta komenda wrednie nadpisze Twoją pracę.

Przygotowanie do łatwego użycia fetch i potem merge

 git config branch.master.remote origin
 git config branch.master.merge refs/heads/master

PS: Przydaje się to zrobić po wrzuceniu czegoś na Githuba. Zakładam, że nazwa namiaru na zdalny serwer to konwencjonalne remote.

Pomocne ustawienia globalne

# aliasy poleceń w stylu SVN
git config --global alias.st status
git config --global alias.ci commit
git config --global alias.co checkout
git config --global alias.br branch

# informacje o użytkowniku
git config --global user.name "Imię Nazwisko"
git config --global user.email twoj@adres.e-mail

# ulubiony edytor
git config --global core.editor vim

# kolorowe komunikaty
git config --global color.interactive auto
git config --global color.status auto
git config --global color.branch auto
git config --global color.diff auto

Ustawienia haseł

Dla bohaterów, którzy dobrze chronią pliki w katalogu domowym.

  echo "machine <nazwa_serwera>" >> ~/.netrc
  echo "login <nazwa_użytkownika>"  >> ~/.netrc
  echo "password <hasło>"  >> ~/.netrc
  chmod 600 ~/.netrc

Podobne

• System kontroli wersji Git
• System Git pod kontrolą dewelopera