<p id="link-to-png">Jeśli obrazy nie wyświetlają się poprawnie, może skorzystać z wersji <a href="?no-svg">Non-SVG</a>.</p>

<li><code>git reset -- <em>files</em></code> usuwa pliki z przechowalni (stage); oznacza to, że komenda ta kopiuje <em>pliki</em> z ostatniego commita do przechowalni (stage). Używa się jej do "cofania" komendy <code>git add <em>files</em></code>. Komendy <code>git reset</code> można użyć również do całkowitego usunięcia wszystkich zmian.</li>

<p>Możesz użyć <code>git reset -p</code>, <code>git checkout -p</code>, lub

<code>git add -p</code> zamiast (lub oprócz) wyszczególniania konkretnych elementów. Wówczas możesz wybrać je w sposób interaktywny.</p>

<p>Możliwe jest również bezpośrednie przeskoczenie do historii commitów i sprawdzenie plików bezpośrednio, bez konieczności przeniesienia ich do przechowalni (stage).</p>

<li><code>git commit <em>files</em></code> tworzy nowy commit, który zawiera całą zawartość ostatniego commita oraz migawkę (snapshot) wybranych <em>plików</em>. Oczywiście <em>pliki</em> kopiowane są do przechowalni (stage).</li>

<p>W dalszej części tego dokumentu będą używane grafiki w następującej formi.</p>

<p>Commity pokazane są w zielonych polach jako pięcio znakowe identyfikatory, które wskazują na swoich rodziców (wcześniejsze commity). Gałęzie (branche) pokazane są w pomarańczowych polach i wskazują na aktualne commity. Aktualne gałęzie (branche) można zidentyfikować dzięki specjalnemu oznaczeniu <em>HEAD</em>, które rzeczywiście jest "przyczepione" do gałęzi (brancha), w której się aktualnie znajdujemy. Na pokazanej grafice widzimy pięć ostatnich commitów, spośród których <em>ed489</em> jest najbardziej aktualnym.

<p>Kiedy zatwierdzasz (commitujesz) zmiany, Git tworzy nowy obiekt używając plików znajdujących się w przechowalni (stage), jednocześnie wskazując jako swojego rodzica ostatni istniejący commit. Następnie aktualna gałąź (branch) zaczyna wskazywać na właśnie wykonany commit. Na grafice umieszczonej poniżej, aktualna gałąź (branch) to <em>master</em>. Zanim komenda została wykonana, gałąź (branch) <em>master</em> wskazywała na commit <em>ed489</em>. Po jej wykonaniu nowy commit oznaczony jako <em>f0cec</em> został utworzony z rodzicem w postaci <em>ed489</em>, a następnie gałąź (branch) <em>master</em> została przeniesiona na nowy commit.</p>

<p>Kiedy <em>nie</em> zostanie podana nazwa pliku tylko nazwa gałęzi (branch) w lokalnym repozytorium, <em>HEAD</em> zostanie przeniesione do podanej gałęzi (branch) - oznacza to "przełączenie się" do danej gałęzi (branch). Przechowalnia (stage) oraz katalog roboczy (working directory) zawierają wówczas elementy commita z aktualnej gałęzi (branch). Każdy z plików wchodzących w skład nowego commita (<em>a47c3</em> poniżej) zostanie skopiowany; każdy plik wchodzący w skład starego commita (<em>ed489</em>), ale nie istnieje w nowym, zostanie usunięty; każdy z plików wchodzący w skład innych commitów zostanie zignorowany.</p>

<p>Kiedy ani nazwa pliku ani nazwa gałęzi (branch) z lokalnego repozytorium <em>nie</em> zostanie podana &mdash; zamiast tego może zostać podant tag, gałąź zdalnego repozytorium, SHA-1 ID lub coś w rodzaju <em>master~3</em> &mdash; otrzymamy anonimową gałąź (branch) zwaną <em>detached HEAD</em>. Jest ona przydatna do skakania po całej historii commitów. Powiedzmy, że chcemy skompilować wersję 1.6.6.1 gita. Możemy wykonać komendę <code>git checkout v1.6.6.1</code> (jest to tag, nie nazwa gałęzi (branch)), skompilować, zainstalować gita, a następnie wrócić do głównej gałęzi master, wydając komendę <code>git checkout master</code>. Mimo wszystko, commitowanie z wykorzystaniem detached HEAD działa trochę inaczej niż zazwyczaj; zostało to opisane <a href="#detached">poniżej</a>.</p>

<p>Kiedy <em>HEAD</em> zostanie odłączone, commity działają tak samo jak zazwyczaj, z tą różnicą, że żadna istniejąca i nazwana gałąź (branch) nie zostanie zaktualizowana. Można powiedzieć, że commit pojawi się w anonimowej gałęzi (commit).</p>

<p>W momencie, w którym HEAD zostanie przeniesiony w dowolne inne miejsce, takie jak na przykład gałąź (branch) <em>master</em>, nic już nie wskazuje na dany commit, w związku z czym commit przepada. W poniższym przykłądzie widać, że po wydaniu komendy nie ma żadnego dowiązania do commita <em>2eecb</em>.</p>

<p>Jeśli zostanie podany commit, ale nie zostaną podane nazwy plików, aktualna gałąź (branch) zostanie przeniesiona do podanego commita, a przechowalnia (stage) zaktualizowana o jego zawartość. Jeśli zostanie dodany przełącznik <code>--hard</code> zaktualizowany zostanie również katalog roboczy (working directory). Przełącznik <code>--soft</code> służy do przeniesienia gałęzi (branch), ale bez aktualizacji przechowalni (stage) oraz katalogu roboczego (working directory).</p>

<p>Jeśli commit nie zostanie podany, domyślnie gałąź (branch) wskazuje na <em>HEAD</em>. W takim przypadku nie nastąpi zmiana gałęzi (branch) - przechowalnia (stage) zostanie zresetowana do zawartości ostatniego commita (jeśli zostanie użyty przełącznik <code>--hard</code> resetowi ulegnie również katalog roboczy (working directory).</p>

<p>Scalanie (merge) tworzy nowy commit, który łączy w sobie zmiany zawarte w innych commitach. Przed wykonaniem scalania (merging), przechowalnia (stage) musi zawierać aktualny commit, do którego będzie następowało scalanie. Najprostszym przypadkiem jest taki, w którym inny commit jest przodkiem commitu, do którego chcemy scalać. Następnym prostym przypadkiem jest taki, w którym aktualny commit jest przodkiem innego commita, który chcemy scalić z aktualnym. Oba przypadki kończą się scalaniem (merge) poprzez <em>fast-forward</em> Wskaźnik zostaje przeniesiony w prosty sposób na nowy commit.</p>

<p>Istnieje również komenda z przełącznikiem <code>git rebase --interactive</code>, która pozwala na wykonywania bardziej skomplikowanych operacji niż tylko same powtarzanie commitów. Niestety nie istnieje żadna oczywista grafika, która w sposób jasny pomogłaby wyjaśnić jej działanie; więcej szczegółów można znaleźć pod tym linkiem: <a

href='http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_interactive_mode'>git-rebase(1)</a>

for more details.</p>

<p>Zawartość plików nie jest tak naprawdę trzymana w pliku index (<em>.git/index</em>) lub w obiektach będących commitami. Tak naprawdę każdy plik trzymany jest w bazie obiektów (object database) (<em>.git/objects</em>) jako obiekt zwany <em>blob</em>, który można zidentyfikować za pomocą hasha SHA-1. Plik index zawiera listę plików wraz z ich identyfikatorami przypisanymi do obiektów blob, a oprócz tego zawiera również inne dane. Na potrzeby commitów stworzony został inny typ danych, znany jako drzewa (<em>tree</em>), który również można zidentyfikować z wykorzystaniem hashy. Drzewa (trees) powiązane są z katalogami w katalogu roboczym (working directory) i zawierają listę drzew oraz obiektóœ typu blob, które połączone są z nazwami plików w danym katalogu. Każdy commit posiada identyfikator swojego "top-level tree", który z kolei zawiera wszystkie obiekty typu blob oraz inne drzewa (trees) powiązane z danym commitem.</p>

<p>Podczas wykonywania commita z odłączonym HEAD (detached HEAD), ostatni commit tak naprawdę posiada coś, co na niego wskazuje: reflog HEADa (historia wykonywanych zmian na headach). Mimo wszystko wskazanie to wygasa po krótkiej chwili, w związku z tym commit może zostać zutylizowany, podobnie do commitów porzuconych przez komendy <code>git commit --amend</code> oraz <code>git rebase</code>.</p>