Schlagwort-Archive: Git

Git History Commit Redos für Workshops

Mit diesem Snippet, das ich in meinen Workshops verwende, könnt ihr die Commits eines Branches vom ersten bis zum letzten Interaktiv durchsteppen, um so jede Änderung mit den Teilnehmern zu besprechen. Das ist vor allem dann nützlich, wenn das Live Coding mehr ablenkt oder die Zeit ein wenig knapp ist:

 

Beim ersten Commit gibt es noch eine kleine Fehlermeldung, da versucht wird auf den vorherigen Commit zuzugreifen, den es beim 1 Commit logischerweise nicht geben kann.

Git History Commit Redo

Git History Commit Redo- First Commit

 

Ab dem zweiten Commit werden dann sowohl die Commit Message als auch alle alle geänderten Dateien angezeigt.

Git History Commit Redo

Git History Commit Redo – Next Commit

 

Am Schluss kommt noch diese Meldung.

Git History Commit Redo

Git History Tracking – Finished

 

Beachtet bitte, dass dies nur bei einer linearen Historie funktioniert, da es sich um einen Rebase handelt und dass ihr hierfür am besten einen Test-Branch abzweigt, um nicht ggf. Änderungen noch einzubauen, die dann im Master-Branch landen.

Advertisements

Gitolite Berechtigungssystem

In diesem Video gebe ich einen Einblick in das Berechtigungssystem von Gitolite. Ich spreche über Zugriffsgruppen, über das Vererbungssystem, über Wild Repos, über mögliche Einsatzszenarien und einiges mehr. Eine ausführliche Dokumentation findet ihr hier.

Die 2 im Video genannten Befehle waren

  1. Prüfung der Berechtigungen für ein Repository (zur Doku): Im Beispiel wird geprüft, ob der User ‚uli.armbruster‘ Berechtigung zum Löschen des ‚master‘-Branch im Repository ‚co-it/homepage‘ hat.gitolite access -s co-it/homepage uli.armbruster D refs/heads/master 
  2. Übersteuern von Berechtigungen am Repository selbst: In dem Beispiel würde mir Gregor auf sein userspezifisches-Repository ‚users/gregor.woiwode/spike1‘ Lesezugriff geben.ssh git@ci.heco.de perms users/gregor.woiwode/spike1 + READERS uli.armbruster

 

Bei Fragen einfach nutzt die Kommentarfunktion oder kontaktiert mich direkt.

Meine tägliche Portion Git

Bei uns arbeiten wir mit Feature Branches, welche nach Abschluss auf den Develop Branch gemergt werden. Der typische Feature-Branch-Workflow also. Wer nun regelmäßig seinen Feature-Branch mit dem Stand des Develop Branch abgleichen will, der muss dazu wie folgt vorgehen:

git checkout develop

git pull //sollte immer ein fast-forward sein

git checkout feature/MyCurrentFeature

git merge develop

Mit offenem Visual Studio ist das natürlich eine nervige Geschichte, weil dann Dateien geändert werden und VS das erkennt. Hinzu kommt, dass ich es beispielsweise täglich mehrfach durchführe und dementsprechend Zeit verliere.

Das lässt sich vereinfachen, indem ihr in eure .gitconfig unter [alias] folgendes eintragt:

medev = !git fetch && git merge origin/develop

In Zukunft könnt ihr dann über git medev euren Feature Branch aktualisieren ohne obiges Prozedere durchzuführen. Alternativ in der Bash folgendes ausführen:

git config alias.medev ‚!git fetch && git merge origin/develop‘

Vorsicht mit den einfachen Anführungszeichen, da die im Blog umgeschrieben werden. Die müsst ihr beim Einfügen von Hand korrigieren.

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.

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

%d Bloggern gefällt das: