Kontrola wersji z Git cz. 3 – cykl życia plików

Wiemy już jak stworzyć nowe repozytorium oraz jak zatwierdź pierwsze zmiany. Przyjrzyjmy się teraz w jakich stanach mogą znajdować się pliki poddane kontroli wersji.

Każdy plik w katalogu który poddany jest kontroli wersji może być śledzony lub nieśledzony. Pliki śledzone to te które zostały już dodane do repozytorium poprzez wywołanie git add a następnie git commit. Dzielimy je na zmodyfikowane, niezmodyfikowane lub oczekujące w poczekalni. Reszta plików w katalogu to pliki nieśledzone – czyli takie, które nie zostały poddane kontroli wersji.

Podczas zmiany pliku który jest już śledzony Git oznacza ten plik jako zmodyfikowany. Zmodyfikowany plik przed zatwierdzeniem należy dodać do poczekalni (lub od razu wywołać git commit z parametrem -a który pomija poczekalnię, więcej tutaj). Po zatwierdzeniu zmian i ponownej modyfikacji cały proces powtarza się ponownie.

Status plików w repozytorium

W poprzednim wpisie przedstawiłem już tą komendę, ale krótkie przypomnienie: w celu sprawdzenia aktualnego stanu plików w katalog wywołujemy polecenie git status:

$ git status
On branch master
nothing to commit, working directory clean

W powyższym przykładzie widzimy że pracujemy na gałęzi master oraz nie ma żadnych oczekujących zmian do zatwierdzenia. Polecam dodanie kilku plików i wykonanie ponownie tego polecanie w celu sprawdzenia co tym razem otrzymamy.

Dodawanie nowych plików

Aby dodać nowy plik do kontroli wersji wykonujemy polecenie git add nazwa_pliku. Teraz po wykonaniu git status zobaczymy że nasz pliki widnieje pod statusem „Changes to be committed„:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   index.php

W tym momencie plik index.php został przeniesiony do poczekalni.

Jeżeli przed zatwierdzeniem zmian ponownie zmodyfikujemy plik index.php to po wywołaniu git status zobaczymy:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   index.php

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   index.php

Oznacza to, że jeżeli chcemy aby nowe zmiany zostały dodanego do poczekalni, musimy ponownie wywołać git add. W innym przypadku po zatwierdzeniu zmian do historii trafi wersja z przed edycji.

Dodawanie zmodyfikowanych plików

Okazuje się że polecenie git add dodaje również do poczekalni pliki znajdujące się pod kontrolą wersji, które zostały zmodyfikowane. Warto wspomnieć tutaj o możliwości dodanie wszystkich nowych i zmodyfikowanych plików jednym poleceniem:

$ git add .

Zatwierdzanie zmian

Zatwierdzanie zmian zostało już opisane w poprzednim wpisie dostępny tutaj.

Usuwanie plików

Do usuwania plików wykorzystujemy polecenie git rm.

Dopiero zatwierdzenie zmian (git commit) spowoduje usunięcie go z kontroli wersji. Istnieje możliwość zachowanie pliku na lokalnym dysku poprzez dodanie parametru –cached

$ git rm --cached index.php
rm 'index.php'

Przenoszenie plików

W GIT’cie nie ma możliwości bezpośredniego przeniesienia plików, istnieje jednak mechanizm który ułatwie tego typu operacje. Polecenie git mv posłuży nam do zmiany nazwy pliku lub zmiany jego lokalizacji. Poniżej przykład:

$ git mv index.php default.php

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	renamed:    index.php -> default.php

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   default.php

W ten sposób zmieniamy plik index.php na default.php. Teraz wystarczy zatwierdzić zmiany i gotowe.

Ignorowanie plików

Na końcu warto wspomnieć jeszcze o mechanizmie ignorowania plików.  Czasami nie chcemy aby pewne pliki były poddane kontroli wersji np. pliki logów lub cache. W tym celu jeszcze przed rozpoczęciem prac nad repozytorium warto utowrzyć plik .gitignore, który będzie zawierał definicję plików ignorowanych, które zostaną pominięte przy sprawdzania stanu repozytorium. Przykładowy plik .gitignore:

/bootstrap/compiled.php
/vendor
composer.phar
composer.lock
.env.*.php
.env.php

Każda definicja/wzorzec powinien znajdować się w osobnym wierszu. Ogólne zasady formatowana pliku .gitignore:

• linia zaczynająca się od znaku # jest komentarzem
• możemy stosować wyrażenia przetwarzania katalogów zgodnie z tymi z konsoli (np. znak * oznacza dowolny znak)
• dodanie ostatniego znaku „/” oznacza wskazanie katalogu
• istnieje możliwość negowania definicji poprzez wstawienie znaku „!” na początku

To wszystko w dzisiejszym artykule. W kolejnym wpisie przerobimy temat zdalnych repozytoriów. Dziękuję za poświęconą uwagę oraz zapraszam do komentowania.