Git: Unterschied zwischen den Versionen

Aus Entität e.V.
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „Auf dieser Seite wird der Umgang mit Git Repositories erklärt. ==Git-Kommandos== ===log=== Mit dem Befehl git log kann man sich die Commits im aktuellen…“)
 
KKeine Bearbeitungszusammenfassung
 
Zeile 181: Zeile 181:


==Weblinks==
==Weblinks==
* http://gitready.com/
* http://try.github.io/
* http://try.github.io/
* http://git.or.cz/course/svn.html
* http://git.or.cz/course/svn.html
* http://seeseekey.net/blog/108604

Aktuelle Version vom 17. Februar 2015, 11:17 Uhr

Auf dieser Seite wird der Umgang mit Git Repositories erklärt.

Git-Kommandos

log

Mit dem Befehl

git log

kann man sich die Commits im aktuellen Branch anzeigen lassen. Mit

git log <branchname>

kann man auch die Commits von anderen Branchen auflisten.

clean

Mittels

git clean . -f

kann ein Repository von allen Dateien befreit werden, welche nicht zu diesem gehören.

checkout

Mit

git checkout <branchname>

kann man einen bestimmten Branch auschecken. Allerdings kann man auch die Repository Version einer verlorenen Datei wiederholen:

git checkout folder/or/file/to/reset

z.B.

git checkout .

Um alle gelöschten Dateien im aktuellen Verzeichnis und darunter wieder herzustellen (sie müssen natürlich im Git Repository vorhanden sein).

rebase

Rebase ist ein sehr mächtiges Tool. Mit ihm kann man zum Beispiel alte Commits ändern, Commits zusammenführen, ihre Commitnachrichten bearbeiten oder sie komplett löschen. Dazu startet man das Tool am besten im interaktiven Modus:

git rebase -i <commit>

Der <commit> ist dann der Commit, vor dem ersten Commit den man bearbeiten möchte. Die restliche Nutzung sollte eigentlich selbsterklärend sein.

Mittels:

git rebase -i HEAD~5

könnte man sich z.B. die letzten fünf Commits anzeigen lassen um einen dieser Commits rückgängig zu machen.

git rebase -i HEAD^^

würde

git rebase -i HEAD~2

entsprechen.

Eine weitere Möglichkeit rebase zu nutzen ist, um einen Branch auf einem anderen basieren zu lassen. Als Beispiel nehmen wir folgende Situation:

  • Branch master ist der Hauptentwicklungsbranch
  • von dort wird nun der Branch featureX abgezweigt
  • es werden Commits in den Branch featureX gepusht
  • währenddessen werden allerdings auch Commits in den master Branch gepusht

Nun hat man das Problem, dass sich featureX und master sich auseinander entwickelt haben. Als Lösung möchten wir nun die Commits aus master in unseren Branch featureX übernehmen und die Änderungen aus featureX auf diese oben drauf packen. Dazu checken wir den Branch featureX aus:

git checkout featureX

Und lassen diesen auf dem master basieren:

git rebase master

Wenn Konflikte auftreten müssen diese natürlich behoben werden. Danach haben wir in featureX fein säuberlich alle Commits aus dem master + oben drauf unser tolles neues Feature aus dem Branch featureX.

remote

Ein remote kann man so erzeugen:

git remote add name git://foo/bar.git

Um mit ihm zu arbeiten sollte man es auf den neusten Stand bringen:

git fetch name

Remote Repositories können wie ein lokaler Branch behandelt werden. Man kann von ihre logs aufrufen, von ihnen pullen, cherry-picken oder einen rebase auf sie machen.

Patches

Patches erstellen

Bevor man einen Patch erstellt sollte man darauf achten das der Name und die eMail Adresse korrekt eingestellt sind. Mittels

git config -l

kann man dabei sehen ob schon etwas eingetragen wurde. Einstellen kann man das ganze mittels

git config --global user.name "Nutzername"
git config --global user.email example@example.org

Möchte man ein Patch erstellen so verändert man erst die entsprechenden Dateien und commited das ganze dann mittels

 git commit -a

Dort trägt man dann auch einen Commit Kommentar ein. Mittels

git push

kann das ganze in ein Repostory hochgeladen werden oder aber ein Patch mittels

git format-patch HEAD^

erstellt werden. In dem Verzeichnis liegt dann eine .patch Datei. Hat man nun noch einen Fehler entdeckt den man beheben möchte so kann man mittels

git commit -a --amend

diese Änderungen zum Commit hinzufügen und anschließend den Patch neu erstellen. Wenn das ganze pushen möchte so muss der Befehl mit der Option --force ergänzt werden (dies sollte aber nur bei lokalen Forks genutzt werden):

git push --force

Nachdem man den Patch erstellt hat und an die Entwickler gesandt hat sollte man sein Repository mit

git reset --hard HEAD^

zurücksetzten, so das alles wieder auf dem Stand der aktuellen Revision ist.

Vor dem pushen sollte man noch ein

git pull --rebase

ausführen, damit man keine Probleme mit neuen Commits bekommt.

Patches testen

Möchte man einen Patch testen so muss man ihn ersteinmal herunterladen (mittels wget z.B.)

wget http://example.org/test.patch

Anschließend kann der Patch mittels

git am <Dateiname>

angewendet werden. Möchte man das git repository wieder in den Ursprungszustand bringen so funktioniert das ganze mittels:

git reset --hard HEAD^

bewerkstelligen.

Wurde der eigene Patch vor dem Einspielen in das Hauptrepository noch leicht verändert muss dieser Commit natürlich übernommen werden. Am einfachsten geht dies wenn keine nicht commiteten Änderungen lokal vorhanden sind.

In diesem Fall kann man einfach mittels

git log

Den Hash des Commits vor dem eigenen heraussuchen. Dann resettet man das Repository auf diese Version und "pullt" vom Hauptrepository.

git reset --hard <hash>
git pull mainline master

Sonstiges

Commits zählen

Um die Anzahl der Commits anzugeben reicht ein:

git log --pretty=oneline|wc -l

Git Anwendungen

Linux

Konsole

  • git

GNOME

KDE

Mac OS X

Windows

Weblinks