Schlagwort-Archive: Repository

Kennst du schon Gitflow und SourceTree?

Auf Community Treffen stelle ich immer wieder fest, dass viele, mich eingeschlossen, das Gefühl haben, dass sie Git nicht ausreizen und viele Möglichkeiten, die ein dezentrales Versionskontrollsystem bietet, nicht nutzen. Manchmal wird es unter vorgehaltener Hand, im Vertrauen oder unter dem Deckmantel der Anonymität geäußert. Auf dem Open Space Leipzig gab es hierzu sogar eine eigene Session. Ich mache es an dieser Stelle öffentlich und sage: Ich möchte mehr wissen!

Nachdem ich mich vor Monaten einmal mit Gitflow beschäftigt habe, stehe ich aktuell an dem Punkt es bei uns einzuführen. Dabei handelt es sich um einen Aufsatz für Git, mit welchem diverse Branching Workflows automatisieren und standardisieren werden können. Es ist eine angenehme Abstraktionsschicht zu einem Set an Befehlen, welche sonst von Hand durchgeführt werden müssten. Eine gute Illustration gibt es hier. Atlassian nennt es den Gitflow Workflow. Mein Entwicklerkollege beschreibt dazu in unserem Team Blog die Installation für msysgit.

Jetzt trifft es sich gut, dass ich kürzlich durch unseren Webentwickler auf SourceTree aufmerksam wurde, welches dem Gitflow Modell eine intuitive Oberfläche verleiht. Bisher habe ich einen Bogen um UI Tools gemacht. Damit nehme ich jetzt meinen ersten Anlauf weg von der Konsole. Martin Fowler schreibt dazu:

A shout out to developers of SourceTree – a nice GuI for git and hg. Useful even for a command-line fan like me.

Über diesen Blogeintrag möchte ich mir Rückmeldungen einholen. Nutzt ihr die vorgestellten Programme bereits? Zur Umfrage geht es hier. Wie geht es euch bei Git? Denkt ihr auch, dass ihr Wissenslücken habt, die geschlossen werden müssen? Gebt hier Antwort.

Und wenn ihr gutes Infomaterial habt, z.B. Online Videos, dann postet es als Kommentar dazu.

Advertisements

Meine tägliche Portion Git – Passwort Eingabe deaktivieren

Wer nicht bei jeder Git Operation wie dem Pushen oder Pullen ein Passwort eingeben will, der muss dazu den Private Key im Verzeichnis %userprofile%\.ssh\ ändern. Dazu führt man in der Git Bash folgenden Befehl aus:

ssh-keygen -f id_rsa -p

Enter old passphrase:

Key has comment ‚id_rsa‘

Enter new passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved with the new passphrase.

 

Wer erst noch ein Schlüsselpaar erzeugen muss, kann natürlich von Anfang an das Passwort auslassen. Eine sicherere Alternative ist es einen SSH Agent zu installieren, der den Key entschlüsselt vorhält.

Meine tägliche Portion Git – Remote Branches synchronisieren

Über

   1: git branch -a

kann man sich alle lokalen und remote Branches anzeigen lassen. Den lokalen löscht man über

   1: g branch -D <branch name>

während der Remote Branche über

   1: git push --delete origin <branch name>

entfernt wird.

Nun kann es im letzten Beispiel zu folgendem Fehler kommen:

error: unable to delete ‚branch_name‘: remote ref does not exist

error: failed to push some refs to ‚git@ci:comwork‘

 

Das liegt daran, dass die angezeigt Liste aus dem ersten Beispiel nicht mit dem Server abgeglichen und somit nicht mehr existierende Remote Branches ausgegeben wurden. Der Befehl

   1: git remote prune origin

korrigiert diesen Missstand. Falls also auf dem Server Branches gelöscht wurden, werden diese aus dem lokalen Repository bzw. aus dem Cache ebenfalls entfernt.

Meine tägliche Portion Git – Tags

Wer vor der Aufgabe steht alle bestehenden Tags aus Git zu löschen, kann dies wie folgt bewerkstelligen:

   1: git tag | xargs git push --delete origin

   2: git tag | xargs git tag -d

Über “git tag” holt man sich alle vorhandenen Tags, welche durch ‚”|” an den nächsten Befehl weitergereicht (Pipe) werden. “xargs” besagt, dass die übergebenen Werte per Schleife durchlaufen und ans Ende des Befehls angefügt werden. Somit werden zunächst alle Remote Tags gelöscht (Zeile 1) und im Anschluss alle lokalen Tags (Zeile 2). Mit

   1: git tag

kann mich sich zur Verifizierung nochmals alle Tags ausgeben lassen. Das Ergebnis sah bei mir im Testszenario dann so aus:

image

Meine tägliche Portion Git – Ambiguous Refname

Kürzlich habe ich aus versehen einen Branch namens “Head” angelegt. Im Anschluss bekam ich immer folgende Warning von Git:

warning: refname ‚HEAD‘ is ambiguous.image

Über “git show-ref” habe ich mir alle Referenzen anzeigen lassen. Folgerichtig war dieser dort auch aufgelistet. Head ist allerdings ein reservierter Name, der immer dem Pointer des aktuell verwendeten Branches entspricht. In diesem Artikel habe ich bereits dazu gebloggt.

Das Problem hat übrigens jemand bereits hier beschrieben. Um das Ganze abzukürzen. Wenn ihr den Branch über “git branch -d head” löscht, ist alles wieder in Butter.

Meine tägliche Portion Git

Heute habe ich auf Grund einer Unachtsamkeit einen falschen Merge getätigt. Die Folge war, dass mein Stand nach dem Rebase fehlte. Konkret kann euch dies passieren, wenn ihr beispielsweise an einer Klasse entwickelt, die Änderungen eincheckt und euch dann das aktuelle Repository über einen Pull zieht. Hat nun ein anderer Entwickler ebenfalls etwas an dieser Datei geändert, so schlägt das Mergen fehl und ihr seid in eurem Branch abgezweigt. In der Regel löst man dies, indem man manuell mergt. Danach führt man über “git rebase –continue” das Zusammenführen des Remote Repository und eures lokalen Repository zu Ende. Stell ihr nun fest, dass ihr falsch gemergt habt, könnt ihr nicht ohne weiteres eure Datei wiederherstellen.

In dem Falle ruft ihr “git reflog” auf. In dem Falle seht ihr alle je getätigten Commits.

image

Nun könnt ihr über “git reset –hard SHA” auf den commit zurück, den ihr vor dem Rebasing hattet. SHA entspricht dabei dem SHA eures Commits. Danach könnt ihr erneut pullen und korrekt mergen.

Meine tägliche Portion Git

Wer eine Änderung gepusht hat und diese rückgängig machen will, sollte wie folgt vorgehen:

  • Gleich alle Entwickler informieren, dass sie nicht mehr pullen sollen (idealerweise hat noch niemand den neuen Stand gepullt!)
  • Über den Befehl “git reset —hard head~1” (geht eine Revision zurück) oder über “git reset —hard  fa0f23d” (wobei fa0f23d dem SHA des Commits entspricht, auf den man zurück will), könnt ihr zunächst lokal den gewünschten Stand wiederherstellen. Über git log könnt ihr auch die Historie anschauen.
  • Danach setzt ihr mit “git push -f origin master” das öffentliche Repository zurück

Anmerkung: Das funktioniert z.B. nicht, wenn der entsprechende Developer nicht die benötigten Rechte hat oder Git so eingestellt ist, dass es “git push -f” nicht zulässt. Wie ihr dieses Problem löst und einen alternativen Weg findet ihr hier (Eintrag 2 anschauen!).

%d Bloggern gefällt das: