Zarządzanie projektami informatycznymi

Zarządzanie projektami informatycznymi
Zdalne repozytoriami, obsługa wielu gałęzi, ignorowanie plików
Zdalne gałęzie są gałęziami z lokalnego repozytorium mającymi odniesienie do stanu gałęzi w
zdalnym repozytorium. Są to gałęzie w lokalnym repozytorium, na które nie możemy się przełączyć
poleceniem git checkout. Są one modyfikowane automatycznie za każdym razem, kiedy
wykonujemy jakieś operacje zdalne (fetch, pull, push). Zdalne gałęzie zachowują się jak zakładki,
przypominają, gdzie znajdowały się gałęzie w twoim zdalnym repozytorium ostatnim razem kiedy
się z nim łączyłeś. Nazwy gałęzi zdalnych mają format:
nazwa_zdalnego_repozytorium/nazwa_gałęzi
Przykładowe nazwy gałęzi zdalnych:
origin/master
– gałąź master w zdalnym repozytorium o aliasie origin
progit/rozdzial5 – gałąź rozdzial5 w repozytorium progit
git push
Polecenia git push używamy do tworzenia nowych gałęzi na serwerze, a także do ich usuwania.
Pełna składnia tego polecenia:
git push [zdalne_repozytorium] [lokalna_gałąź]:[zdalna_gałąź]
Można podać inne nazwy gałęzi lokalnej i zdalnej oddzielone dwukropkiem.
Aby usunąć gałąź na serwerze trzeba wysłać brak gałęzi! W miejscu nazwy gałęzi lokalnej
pozostawiamy puste miejsce:
git push [zdalne_repozytorium]
:[zdalna_gałąź]
Jest to dość nietypowa składnia polecenia usuwania gałęzi zdalnych.
Przykłady użycia polecenia git push:
git push origin zpi
Wysyła lokalną gałąź zpi na zdalne repozytorium origin pod taką samą nazwą.
git push origin master:inna
Tworzy/uaktualnia w zdalnym repozytorium origin gałąź o nazwie inna z gałęzi lokalnej
master. Czyli wypycha nam na serwer gałąź master pod nazwą inna.
git push origin :inna
Wysyła na serwer brak gałęzi w miejsce gałęzi inna, czyli usuwa gałąź inna ze zdalnego
repozytorium origin.
Przykłady innych poleceń pracujących na gałęziach zdalnych:
git log origin/zpi --oneline --decorate
Pokazuje log zdalnej gałęzi zpi, pobranej z repozytorium origin.
git remote show origin
Pokazuje więcej informacji o konkretnym zdalnym repozytorium, tutaj origin.
git merge origin/master
Dodaje/łączy zmiany z gałęzi zdalnej origin/master do gałęzi, w której jesteśmy. Jeśli nie
jesteśmy lokalnie w gałęzi master to zmiany zostaną scalone do innej gałęzi.
git checkout -b problem237 origin/blad237
Tworzy nową gałąź lokalną problem237 ze zdalnej gałęzi blad237, na której będzie można
teraz pracować i automatycznie przełącza nas do niej. Nie ma możliwości pracować bezpośrednio
na gałęziach zdalnych, choć są one już w naszym lokalnym repozytorium. Lokalna gałąź
problem237 będzie śledzić zdalną gałąź origin/blad237.
Ignorowanie plików
Nie wszystkie pliki znajdujące się w katalogu roboczym projektu będziemy chcieli śledzić
i zachowywać w repozytorium. Niektóre z nich trzeba ignorować. Wśród takich plików można
wymienić:
• skompilowanie pliki binarne lub obiektowe (*.o, *.obj), skompilowane pliki języka java z
rozszerzeniem *.class,
• pliki dokumentacji wygenerowane automatycznie z plików źródłowych (*.html, *.pdf, ...),
np. za pomocą programu doxygen,
• inne automatycznie generowane pliki z plików źródłowych,
• pliki tymczasowe i zapasowe kopie plików generowane przez edytory tekstowe czy inne
narzędzia programistyczne, których używamy,
• ...
Wszystkie te pliki nie są potrzebne innym programistom do pracy nad projektem. Jednak dla
naszej wygody, czy przyzwyczajeń dobrze jest mieć je w katalogu roboczym. Co robimy?
Ignorowanie plików w systemie git (git help gitignore)
Określamy wzorce plików, co do których chcemy, żeby specjalnie nie były śledzone. Takie
określenie plików, które mają być ignorowane nie działa na pliki już poddane śledzeniu.
Oczywiście można zawsze przestać śledzić plik znanym już poleceniem git rm --cached.
Ignorowanie plików stosujemy, żeby mieć pewność, że pewne pliki, które nie mają być śledzone,
takimi do końca pozostaną.
Pliki, które mają być ignorowane, podajemy za pomocą wzorców. System git ma cztery
źródła wzorców, ułożone hierarchicznie, według których szuka plików, które nie będą śledzone. I
tak od najważniejszych:
1. wzorce przekazane w linii poleceń, tych oczywiście, które takie wzorce dopuszczają,
2. wzorce w pliku .gitignore będącego w tym samym katalogu co plik albo w katalogu
nadrzędnym dla tego pliku (który to jednak katalog powinien być częścią repozytorium);
jeśli jest kilka plików .gitignore w kilku katalogach i są w nich wzorce dotyczące tych
samych plików to stosowany ostatecznie jest ten wzorzec będący najniżej w hierarchii
katalogów, czyli taki, który jest najbliżej pliku, którego dotyczy; zwykle projekt posiada
jeden plik .gitignore;
3. wzorce zapisane w pliku $GIT_DIR/info/exclude
4. wzorce przeczytane z pliku określonego w zmiennej core.excludesfile.
Kiedy stosujemy każde z tych rozwiązań?
Plik .gitignore
Jest to chyba najważniejszy plik. Zapisujemy w nim wzorce, które będą przenosić się wraz z
całym repozytorium, np. poleceniem git clone. Są to więc wzorce dotyczące plików, które
wszyscy programiści będą mieli i wszyscy będą chcieli je ignorować. Przykładem mogą być pliki
binarne skompilowanych programów, pliki obiektowe (*.o), inne.
Plik exclude
Stosujemy ten plik, kiedy chcemy wykluczyć pliki, które są nie potrzebne tylko nam, tylko w
tym konkretnym repozytorium. Inni ludzie pracujący nad tym projektem mogą tych plików w
ogóle nie mieć.
Zmienna programu git core.excludesfile
Zmienna ta zawiera nazwę pliku, w którym mamy wzorce określające jakie pliki mają być
wyłączone ze śledzenia. To rozwiązanie wykorzystujemy zwykle kiedy chcemy wykluczyć ze
śledzenia pliki, które my sobie za każdym razem wykluczamy. Nie dotyczy to jakiegoś
konkretnego projektu ale bardziej naszych własnych indywidualnych upodobań.
Na przykład jeśli jakiś nasz ulubiony edytor tworzy pliki zapasowe czy tymczasowe to
oczywiście nie będziemy ich śledzić, ale nikt inny takiego edytora może nie używać więc
odpowiednie wzorce umieszczamy w własnym pliku, którego nazwę ustalamy w zmiennej
core.excludesfile.
Dla przykładu stworzyłem sobie w katalogu domowym plik nie_sledzic i umieściłem w
nim wzorzec *.swp (pliki tymczasowe edytora vim). Ustawiłem wartość zmiennej poleceniem:
git config core.excludesfile "~/nie_sledzic". No i działa.
Format wzorców
Pusta linia nie dopasowuje żadnego pliku, może służyć jako separator dla poprawy czytelności.
Linia zaczynająca się od znaku # służy jako komentarz.
Znak ! neguje wzorzec. Jeśli jakiś plik zostanie dopasowany tym wzorcem a wcześniej był przez
inny wzorzec wyłączony ze śledzenia to będzie ponownie śledzony.
Wystąpienie znaku / we wzorcu oznacza, że musi być dopasowana odpowiednia ścieżka,
odpowiednia struktura katalogów, a nie tylko nazwa pliku.
Przykłady:
foo/
Dopasuje katalog foo i pliki w nim zawarte ale nie dopasuje zwykłego pliku foo czy linku o
takiej nazwie.
Documentation/*.html
Dopasuje plik Documentation/git.html ale nie dopasuje pliku
Documentation/ppc/ppc.html albo tools/perf/Documentation/perf.html.
/*.c
Dopasuje plik cat-file.c, ale nie plik src/main.c.
Więcej w pomocy: git help ignore
Przykładowa zawartość pliku .gitignore:
#
#
#
#
#
#
git ls-files --others --exclude-from=.git/info/exclude
Linie zaczynające się znakiem '#' stanowią komentarz.
Dla projektów napisanych w języku C przydatnymi wzorcami plików,
które mają być ignorowane mogą być (usuń komentarz w celu użycia ich):
*.[oa]
*~
# pliki obiektowe z katalogu obj i plik wykonywalny
obj/*.o
bin/SGP
# dokumentacja html wygenerowana przez program doxygen
# czyli zawartość katalogu doc/html
doc/html/*
# wszystkie pliki graficzne z rozszerzeniem *.jpeg i *.png
# z wyjątkiem plików *.png w katalogu /doc/graph/PB/
*.jpeg
*.png
!/doc/graph/PB/*.png
Ćwiczenia:
Praca ze zdalnym repozytorium:
1. W celu przetestowania powyższej teorii tworzymy własne repozytorium na serwerze github
(można zamieścić na serwerze dowolny własny projekt).
2. Zdalne repozytorium modyfikujemy lokalnie i wysyłamy modyfikacje na serwer.
3. W sprawozdaniu należy umieścić kilka screen'ów z własnych działań wraz z nazwą swojego
konta na serwerze.
Praca z wieloma gałęziami (https://github.com/student-zpi/historyjka)
1. Kopiujemy projekt (na swoje konto na github – przycisk FORK)
[email protected]:student-zpi/historyjka.git
2. W pliku README jest instrukcja co robić dalej.
3. Wykonujemy zadania z pliku.
4. Wszystkie pytania i odpowiedzi na github zamieszczamy w sprawozdaniu.
Wspólna praca na jednej gałęzi (https://github.com/sabina1986/git-pytania.git)
1. Kopiujemy projekt (na swoje konto na github – przycisk FORK)
https://github.com/sabina1986/git-pytania.git
2. W pliku README jest instrukcja co robić dalej.
3. Wykonujemy zadania z pliku.
4. Wszystkie pytania i odpowiedzi zamieszczamy w sprawozdaniu.