Unterschiede
Hier werden die Unterschiede zwischen der gewählten und der aktuellen Version gezeigt.
| java-tools:git 2014/10/28 10:29 | java-tools:git 2020/01/22 20:59 aktuell | ||
|---|---|---|---|
| Zeile 4: | Zeile 4: | ||
| (Es wird dabei von einem lokalen Repositoy und einem entfernten Repository ausgegangen)\\ | (Es wird dabei von einem lokalen Repositoy und einem entfernten Repository ausgegangen)\\ | ||
| Git arbeitet mit drei Stufen:\\ | Git arbeitet mit drei Stufen:\\ | ||
| - | * Arbeitsverzeichnis/-kopie (Working directory) | + | * Arbeitsverzeichnis/-kopie (Working directory); hier werden die Dateien vom Entwickler bearbeitet |
| - | * Index (Stage) | + | * Index (Stage); hier wird sich der Zustand einer Datei gemerkt, in welchem der commit erfolgt |
| - | * HEAD | + | * Repository; Die "Datenbank" der Versionsverwaltung |
| - | //git add// überführt die Dateien in den Index, //git commit// setzt den HEAD auf den letzten commit.\\ | + | //git add// macht die Dateien dem Index bekannt, //git commit// überführt die Dateien, welche im Index sind, ins Repository und setzt den HEAD auf den letzten commit.\\ |
| + | Achtung! Wenn eine Datei nach einem //add// noch verändert wurde und dann ein //commit// durchgeführt wird, so landet die Datei in dem Zustand im Repository, in welchem dass //add// durchgeführt wurde, also nicht(!) im Neusten!\\ | ||
| \\ | \\ | ||
| \\ | \\ | ||
| Zeile 20: | Zeile 21: | ||
| </code> | </code> | ||
| \\ | \\ | ||
| - | Einen Branch ausschecken (dabei werden Änderungen, welche noch nicht commited wurden, verworfen):\\ | + | Einen Branch ausschecken (dabei werden Änderungen, welche noch nicht committed wurden, verworfen):\\ |
| <code> | <code> | ||
| git checkout <branch> | git checkout <branch> | ||
| + | </code> | ||
| + | \\ | ||
| + | Lokale Änderungen verwerfen, welche bereits committed wurden:\\ | ||
| + | <code> | ||
| + | git reset --hard <origin/branch> | ||
| </code> | </code> | ||
| \\ | \\ | ||
| Zeile 32: | Zeile 38: | ||
| <code> | <code> | ||
| git add . | git add . | ||
| + | </code> | ||
| + | Genauere Liste der Änderungen anzeigen und Möglichkeit der Auswahl,\\ | ||
| + | welche Änderungen in die staged-area zum Commit übernommen werden sollen\\ | ||
| + | und Anzeige einer Befehlsliste für das weitere Vorgehen (auch beenden ohne zu add-en) | ||
| + | <code> | ||
| + | git add -i | ||
| </code> | </code> | ||
| \\ | \\ | ||
| Zeile 37: | Zeile 49: | ||
| <code> | <code> | ||
| git commit -m "<Beschreibung des commit>" | git commit -m "<Beschreibung des commit>" | ||
| + | </code> | ||
| + | \\ | ||
| + | Hat man bei einem commit eine Datei vergessen, so kann man diese dem commit nachträglich hinzufügen:\\ | ||
| + | <code> | ||
| + | git commit -m 'Mein commit bei dem eine Datei fehlt' | ||
| + | git add <fehlende Datei> | ||
| + | git commit --amend | ||
| </code> | </code> | ||
| \\ | \\ | ||
| Zeile 49: | Zeile 68: | ||
| </code> | </code> | ||
| \\ | \\ | ||
| - | Dafür sorgen, dass sich die bereits gemergten Teile gemerkt werden:\\ | + | Die lokalen Änderungen einer Datei rückgängig machen:\\ |
| - | (**re**use **re**corded **re**solution)\\ | + | |
| <code> | <code> | ||
| - | git config --add rerere.enabled true | + | git checkout -- <file> |
| + | </code> | ||
| + | \\ | ||
| + | Alle lokalen Änderungen rückgängig machen:\\ | ||
| + | <code> | ||
| + | git checkout -- . | ||
| </code> | </code> | ||
| \\ | \\ | ||
| Zeile 63: | Zeile 86: | ||
| <code> | <code> | ||
| git branch | git branch | ||
| + | </code> | ||
| + | \\ | ||
| + | Änderungen anzeigen (staged, unstaged, untracked):\\ | ||
| + | (siehe auch => git add -i) | ||
| + | <code> | ||
| + | git status | ||
| </code> | </code> | ||
| \\ | \\ | ||
| Zeile 74: | Zeile 103: | ||
| <code> | <code> | ||
| git log | git log | ||
| + | </code> | ||
| + | \\ | ||
| + | Das Log lässt sich auch grafisch aufbereiten: | ||
| + | <code> | ||
| + | gitk | ||
| + | </code> | ||
| + | \\ | ||
| + | Aktuelle Dateiversion mit letzer Version vergleichen: | ||
| + | <code> | ||
| + | git log -p [--follow] [-1] myFile | ||
| </code> | </code> | ||
| + | ==== Git konfigurieren ==== | ||
| + | Dafür sorgen, dass sich die bereits gemergten Teile gemerkt werden:\\ | ||
| + | (**re**use **re**corded **re**solution)\\ | ||
| + | \\ | ||
| + | <code> | ||
| + | git config --add rerere.enabled true | ||
| + | </code> | ||
| + | \\ | ||
| + | Die eigene Identität festlegen (global): | ||
| + | <code> | ||
| + | $ git config --global user.name "Peter Mayer" | ||
| + | $ git config --global user.email peter.mayer@example.com | ||
| + | </code> | ||
| + | \\ | ||
| + | Ein Diff-Tool (hier: vimdiff) festlegen (global): | ||
| + | <code> | ||
| + | $ git config --global merge.tool vimdiff | ||
| + | </code> | ||
| + | \\ | ||
| + | ==== Beispielhafter Workflow mit zwei Entwicklern ==== | ||
| + | Nennen wir die beiden A-User und B-User.\\ | ||
| + | Diese arbeiten auf einem gemeinsamen Branch namens //develop//.\\ | ||
| + | A-User macht Änderungen an einer Datei und commited diese. | ||
| + | B-User macht ebenfalls Änderungen, aber an einer anderen Datei. | ||
| + | B-User commited und pushed. | ||
| + | A-User möchte nun commiten, der Versuch wird aber //rejected//, obwohl B-User an anderen Dateien gearbeitet hat. Daher muss A-User erst mit einem <code>git fetch origin</code> | ||
| + | sein Repository auf den neusten Stand bringen. Anschließend führt er einen Merge mit | ||
| + | <code>git merge origin/develop</code> | ||
| + | durch. Nun kann A-User seine Änderungen | ||
| + | <code>git push</code> | ||
| + | ins remote Repository übertragen,. | ||
