Git obszar roboczy

Wiemy już, czym jest repozytorium, jak dodawać rewizję czy sprawdzać, w jakim stanie znajduję się nasz/nasze plik/pliki. Teraz dowiemy się, czym jest obszar roboczy w git, jak wyczyścić ten obszar oraz jak przywrócić plik do stanu z ostatniego commita.

Miejsce w naszym folderze gdzie znajdują się wszystkie pliki, nazywamy obszarem roboczym (ang. working area, working directory).

C:\mojeRepo
|-- .git
|-- a.txt //OBSZAR ROBOCZY
|-- b.txt //OBSZAR ROBOCZY
|-- ...   //OBSZAR ROBOCZY
|-- ...   //OBSZAR ROBOCZY

To właśnie w tym miejscu, gdy wykonujesz komendę git status, dostajesz odpowiedź czy w obszarze roboczym są pliki śledzone, czy też nie, czy zostały wykonane jakiekolwiek akcje typu modyfikacja pliku, dodanie pliku, usuniecie pliku. Dodaj do folderu c:\mojeRepo kilka plików i utwórz dwie rewizję, np:

touch a.txt
touch b.txt
touch c.txt

git add a.txt
git commit -m "Dodalem plik a.txt"
git add b.txt 
git commit -m "Dodalem plik b.txt"

Użyjesz komendy do śledzenia pliku i wykonasz komendę, która doda rewizję, otrzymasz wynik, w którym obszar roboczy będzie posiadać nieśledzony jeden plik, dokładniej plik c.txt.
Teraz zmodyfikuj zawartość pliku b.txt. Możesz to zrobić na kilka sposobów albo otworzyć plik w edytorze tekstu lub wykonać polecenie

echo "Modyfikuje plik b.txt dodając ten tekst." > b.txt

Powyższe polecenie wklei napis do pliku. Wykonaj polecenie git status, git zwróci informacje o tym, że plik b.txt został zmodyfikowany i wszystkie zmiany w pliku nie będą uwzględnione przy następnej rewizji. Plik c.txt jest nowym plikiem dla naszej przestrzeni roboczej i git informuje nas o tym, że nic nie wie o tym pliku.

Teraz, aby zapisać zmodyfikowany plik b.txt wystarczy wykonać komendę: git add b.txt i wszystkie zmiany w tym pliku zostaną zapisane i uwzględnione w przestrzeni roboczej, tak, że będą one zaliczane w komicie.

Czyszczenie obszaru roboczego

My rozpatrujemy przypadek, gdzie na nieśliśmy zmiany w pliku, ale nie chcemy ich. Chcielibyśmy, aby zmodyfikowany przez nas plik, wrócił do zmian, jakie występowały w ostatniej rewizji.
W obecnej sytuacji nasz plik b.txt ma wpisany tekst „Modyfikuje plik b.txt dodając ten tekst.”, chcemy, aby ten plik wrócił do stanu z ostatniej rewizji, czyli był pusty. Rezultat osiągniemy używając komendy

git reset --hard

Po wydaniu polecenia sprawdź jak wygląda nasza przestrzeń robocza wydając komende

git status

Zobaczymy, że zmiany na niesione w pliku b.txt zostały cofnięte, plik posiada swoją zawartość z ostatniego komita, czyli jest pusty.
Zamiast komendy git reset —-hard można użyć

git checkout -f

która wykona te same czynności. Przywróci zmodyfikowany plik do postaci z ostatniej rewizji. Inaczej mówiąc, oczyści obszar roboczy z plików, które zostały zmodyfikowane, czyli nastąpiła już w śledzonych plikach zmiana.

Nie zapominamy o naszym pliku c.txt, który nadal jest nieśledzony.

Wspomniałem, że polecenie git reset –hard albo git checkout -f usuwa zmiany z zmodyfikowanych plików i przywraca ich zawartość z ostatniej rewizji. Co zatem dzieję się z plikami nowo utworzonymi? A no właśnie, nie są usuwane.

Usunięcie nowo dodanego pliku, można wykonać na kilka sposobów, ja przedstawię taki:

git add c.txt

git reset --hard 
albo
git checkout -f

Taki zabieg, spowoduję, że git zacznie śledzić nowo dodany plik, który będzie znajdować się w przestrzeni roboczej. Usunie zawartość przestrzeni roboczej wraz ze wszystkimi zmianami naniesionymi na plik oraz z tymi, nowo utworzonymi i dodanymi do obszaru roboczego.

Podsumowanie

git reset —-hard oraz git checkout -f służą do czyszczenia obszaru roboczego tych plików, które były już śledzone oraz na te, które zmodyfikowano. Jeżeli chcemy wyczyścić obszar roboczy z nowo dodanych plików, które nie były wcześniej śledzone, należy zacząć śledzić nowe pliki i wtedy można je usunąć z obszaru roboczego za pomocą git reset —-hard oraz git checkout -f.

Jeżeli chodzi o akcje wykonywane na obszarze roboczym, jest to temat nieco większy. Stopniowo wraz z nowszymi wpisami będę bardziej zagłębiał się w to zagadnienie, aby zrozumieć je, jak najlepiej.

Pozdro 🙂

Git obszar roboczy