Sie sind auf Seite 1von 2

fournova

GIT CHEAT SHEET



presented by TOWER Version control with Git - made easy

REPOS ERSTELLEN BRANCHES & TAGS MERGE & REBASE


Clonen eines bestehenden Repos Alle Branches auflisten Merge von <branch> in aktuellen HEAD
$ git clone ssh://user@domain.com/repo.git $ git branch -av $ git merge <branch>

Neues, lokales Repo erstellen Aktuellen HEAD-Branch wechseln Aktuellen HEAD auf <branch>rebasen
$ git init $ git checkout <branch> Kein Rebase von Commits, die published sind!
$ git rebase <branch>
Neuen lokalen Branch erstellen
LOKALE NDERUNGEN (basierend auf dem aktuellen HEAD) Rebase abbrechen
$ git branch <new-branch> $ git rebase --abort
Vernderte Files in der Working Copy
$ git status Neuen lokalen Branch auf Basis eines <remo- Rebase nach Konfliktlsung fortsetzen
te/branch> erstellen $ git rebase --continue
nderungen an versionierten Files
$ git checkout --track <remote/branch>
$ git diff Konflikt in externem Mergetool lsen
Lokalen Branch lschen $ git mergetool
Alle lokalen nderungen zum nchsten Com-
$ git branch -d <branch>
mit hinzufgen Konflikt als resolved markieren nach manu-
$ git add . Tag auf aktuellem Commit erstellen eller Konfliktlsung im Editor
$ git tag <tag-name> $ git add <resolved-file>
Teile der nderungen in <file> zum
nchsten Commit hinzufgen $ git rm <resolved-file>

$ git add -p <file> UPDATE & PUBLISH


Alle lokalen nderungen an bereits Alle konfigurierten remote Repos listen UNDO
versionierten Files direkt committen $ git remote -v Alle lokalen nderungen in der Working Copy
$ git commit -a verwerfen
Infos ber ein <remote> anzeigen
Zur Staging Area hinzugefgte $ git reset --hard HEAD
$ git remote show <remote>
nderungen committen
Weiteres remote Repo anbinden  Lokale nderungen in <file> verwerfen
$ git commit
$ git checkout HEAD <file>
$ git remote add <shortname> <url>
Den letzten / neuesten Commit ndern
Alle nderungen von <remote> runterladen, Commit rckgngig machen durch neuen
Keine bereits verffentlichten Commits ndern!
aber nicht in HEADintegrieren Commit mit gegens. nderungen
$ git commit --amend
$ git revert <commit>
$ git fetch <remote>

nderungen herunterladen und direkt in HEAD-Zeiger auf einen frheren Commit


COMMIT LOG setzen und
HEADintegrieren / mergen
Alle Commits chronologisch anzeigen $ git pull <remote> <branch> alle nderungen seither verwerfen
$ git log $ git reset --hard <commit>
Lokale nderungen auf Remote pushen
nderungen an einem speziellen <file> ber $ git push <remote> <branch> alle nderungen behalten
versch. Versionen hinweg anzeigen $ git reset <commit>
$ git log -p <file>
Remote Branch lschen
$ git branch -dr <remote/branch> noch nicht committete lokale
Wer vernderte was & wann in <file> nderungen behalten
$ git blame <file>
Tags verffentlichen
$ git reset --keep <commit>
$ git push --tags

30 Tage kostenlose Testversion unter


www.git-tower.com Version control with Git - made easy
fournova

VERSION CONTROL
BEST PRACTICES

THEMATISCH PASSEND COMMITTEN TESTEN VOR DEM COMMITTEN BRANCHES VERWENDEN


Ein Commit sollte zusammengehrige nde- Bevor etwas nicht getestet ist, sollte es nicht Einfaches und schnelles Branching war von
rungen sammeln. Z.B. sollte das Beheben von committen werden. Risiken und Nebenwir- Anfang an eine zentrale Anforderung an Git.
zwei unterschiedlichen Bugs in zwei getrenn- kungen sollte man ausfhrlich testen, um Und tatschlich sind Branches eines der bes-
ten Commits passieren. Kleine Commits hel- sicherzustellen, dass das Feature wirklich ten Features in Git: sie sind das perfekte Tool,
fen anderen Entwicklern, die nderungen zu sauber abgeschlossen ist. Vor allem bevor um verschiedene Kontexte im Entwicklungs-
verstehen und sie ggf. rckgngig zu machen man die eigenen nderungen mit Teamkol- alltag sauber getrennt zu halten.
falls etwas fehlschlug. legen teilt, sollte man sicher sein, keinen Moderne Workflows sollten Branches intensiv
Mit Tools wie der Staging Area und der Mg- halbgaren Code committet zu haben. nutzen: fr neue Features, Bugfixes, Ideen
lichkeit, einzelne Teile einer genderten Datei oder Experimente.
zu stagen, lassen sich in Git sehr einfach
granulare Commits erstellen.

HUFIG COMMITTEN GUTE COMMIT MESSAGES EINHEITLICHER WORKFLOW


Oft zu committen hilft dabei, die einzelnen Eine Commit-Message sollte mit einer kurzen Git ermglicht die verschiedensten Work-
Commits klein und thematisch passend zu Zusammenfassung der nderungen begin- flows: langlebige Branches, themenbasierte
halten. Zustzlich knnen dadurch die nde- nen (nicht lnger als 50 Zeichen). Nach einer Branches, Merge oder Rebase, git-flow, ...
rungen fter verffentlicht werden. Dadurch Leerzeile sollten dann folgende Fragen durch Wofr man sich entscheidet, hngt von
wird es fr alle im Team einfacher, nderun- die Message beantwortet werden: verschiedenen Faktoren ab: dem Projekt, den
gen regelmig zu integrieren und Merge- Was war der Grund fr die nderung? generellen Entwicklungs- und Deployment-
Konflikte zu vermeiden. Workflows und (vielleicht am wichtigsten)
Wie unterscheidet sie sich von der frheren
Wenn man hingegen wenige groe Commits auch von den persnlichen Prferenzen und
Implementierung?
nur selten verffentlicht, sind Konflikte vor- denen des Teams. Aber egal, fr welche Ar-
programmiert. Mit Imperativ und Gegenwartsform (change beitsweise man sich entscheidet, gilt immer:
anstatt changed oder changes) bleibt alle Teammitglieder sollten sich auf einen
man konform mit automatisch generierten gemeinsamen Workflow einigen und ihn
Messages wie z.B. nach git merge. einhalten.

NICHTS HALBFERTIGES COMMITTEN VERSIONSKONTROLLE IST KEIN HILFE & DOKUMENTATION


Man sollte nur fertigen Code committen. Das
BACKUP SYSTEM Hilfe auf der Kommandozeile
bedeutet nicht, dass man wochenlang nicht Ein schner Nebeneffekt der Versionskont- $ git help <command>
committen sollte, bis ein groes Feature fer- rolle ist, dass man ein Backup seiner Files auf
tig ist. Vielmehr sollte die Implementierung in einem Remote-Server hat. Dennoch sollte
logische Hppchen aufgeteilt und committet man sein VCS nicht benutzen als sei es ein KOSTENLOSE INFOS IM WEB
werden. Allerdings sollte man nicht commit- Backup-System.
ten, nur um vor dem Feierabend noch etwas http://www.git-tower.com/learn
Bei der Versionskontrolle sollte man darauf http://rogerdudler.github.io/git-guide/
im Repo zu haben.
achten, thematisch passende nderungen
Auch muss man nicht committen, nur um http://www.git-scm.org/
zusammenzufassen (s.o.) - und nicht einfach
eine saubere Working Copy zu bekommen nur irgendwelche Dateistnde zusammen
(um einen Branch zu wechseln etc.). Hierfr zu wrfeln.
ist der Stash in Git ideal.

30 Tage kostenlose Testversion unter


www.git-tower.com Version control with Git - made easy