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:

Blog Post

GIT_EDITOR=true git rebase -i --root -x 'git diff --name-only HEAD~1..HEAD;git show --oneline --no-patch; printf "Return for next commit"; read;clear'

view raw git-history-commit-redos.md hosted with ❤ by GitHub

 

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- First Commit

 

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

Git History Commit Redo – Next Commit

 

Am Schluss kommt noch diese Meldung.

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.

Werbung

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:

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.

Ü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.

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

Here are some Git Aliases of mine. Just insert them in the "[alias]” section into your global .gitconfig, usually placed in your home directory.

   1: review = log -1 --patch

   2: unstage = reset head

   3: aa = add --all

   4: au = add --update

   5: s = status

   6: p = pull

   7: l = log --oneline -10

   8: k = !gitk --all & --all &

   9: aua = !git add --update && git commit --amend --reuse-message=HEAD

  10: aaa = !git add --all && git commit --amend --reuse-message=HEAD

  11: amend = commit --amend --reuse-message=HEAD

  12: aac = !sh -c 'git add --all && git commit -m \"$1\"' -

  13: aucp = !sh -c 'git add --update && git commit -m \"$1\" && git push' -

  14: aacp = !sh -c 'git add --all && git commit -m \"$1\" && git push' -

From now on, you can type in your git bash

git aacp “commit message”

in order to add all, commit and push your respository.

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!).

Meine tägliche Portion Git

Wer eigene Merge Tools in Git verwenden will, der muss ein paar Kleinigkeiten beachten:

1. %userprofile%\.gitconfig anpassen: Neuer Abschnitt für das Mergetool der eigenen Wahl anlegen

[mergetool "P4"]
    cmd = /Pfad/p4merge-merge.sh \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"
    trustExitCode = true

Gegebenenfalls auch unter [merge] dieses als Standard definieren:

[merge]
    tool = P4
    log = true

 

2. Shell-Skript schreiben und dort ablegen, worauf ihr in der .gitconfig verwiesen habt

#!/bin/sh
script_dir=/Pfad

local="$($script_dir/cygpath –mixed –absolute "$2")"
base="$($script_dir/cygpath –mixed –absolute "$1")"
baseUnixFormat="$($script_dir/cygpath –unix –absolute "$1")"
remote="$($script_dir/cygpath –mixed –absolute "$3")"
result="$($script_dir/cygpath –mixed –absolute "$4")"
tool="/Pfad/P4Merge/p4merge.exe"

if [ ! -f "$baseUnixFormat" ]
then
    base="$($script_dir/cygpath –mixed –absolute $script_dir/p4merge-empty.txt)"
fi

"$tool" "$local" "$remote" "$base" "$result"

 

Achtet genau auf die Pfade! Für Teams bietet sich an, dass man alle Tools und Skripte ins Repository mit aufnimmt. Danach erstellt man ein symbolisches Verzeichnis auf der Platte, welches bei jedem Entwickler auf den Pfad des Repository verweist. Wir haben uns z.B. darauf verständigt, dass jeder Entwickler ein Verzeichnis D:\Development\Repository haben muss. Bei mir zeigt das dann beispielsweise auf G:\heco\comwork. Bei dem Kollegen wiederum auf einen anderen Pfad. Aber da wir mit dem symbolischen Verzeichnis arbeiten, können wir alle die Skripte und Tools verwenden ohne sie anpassen zu müssen. Da die Git\.gitconfig wiederum pro Entwickler konfiguriert wird, kann trotzdem jeder das Merge Tool seiner Wahl als Standard einstellen.

Noch zwei wichtige Punkte:

• Im Pfad muss eine p4merge-empty.txt liegen, sonst schmeißt das Skript einen Fehler. Die Dateien wird verwendet, wenn es beim Merge keine gemeinsame Basis gibt, also statt /dev/null. Damit haben die meisten Programme und Windows Probleme.
• Ich verwende das Kommandozeilentool cygpath (Teil von cygwin), um Windows Pfade in Unix Pfade zu konvertieren. Wenn ihr dieses nicht verwendet, dann müsst ihr die Befehle abändern und alle Pfadangaben im Unix Format angeben.

Weiterführender Link zum Blogeintrag von agross.

Meine tägliche Portion Git

Gehen wir davon aus, dass wir lokal 2 Branches haben mit den Namen Branch1 und Branch2. Dann sind beide Branches unter zwei Namen zu erreichen.

Dem eigentlichen Alias, sprich der Branch Name, z.B. Branch1. Außerdem unter dem eindeutigen SHA. Sprich folgende Befehle sind syntaktisch gleich:

• git checkout Branch1
• git checkout 56789

Mit git checkout wechselt man zwischen Branches. Steht man aktuell auf Branch1, so ist dieser noch unter einem dritten Alias erreichbar: HEAD.

Wenn ich nun über git checkout Branch2 mache, so wechselt der HEAD Pointer auf Branch2, sodass Branch1 nur noch unter 2 Namen erreichbar ist, wohingegen Branch2 nun 3 Namen hat: Den SHA, Branch2 und HEAD.

Gut zu wissen: Über git reflog kann man sich die komplette Historie von HEAD anzeigen, sprich alle Änderungen die man auf jedem Branch, auf dem man jemals war, anzeigen lassen und ggf. darauf wechseln.

Lokale Branches lässt man sich über git branch anzeigen, Remote Branches über git branch –r (git branch –a listet lokale und remote Branches auf). Wichtig zu wissen: Per Default sind Branches, die man anlegt, lokal. Über git push origin branchname -u (funktioniert immer, egal wo man steht) kann man den Branch veröffentlichen. Wird ein Branch veröffentlicht, so wird er auch in die .git/config (sprich die Repository spezifische config) eingetragen! Bei lokalen ist dies nicht der Fall. Wenn ein Kollege einen Branch veröffentlicht hat, so kann man diesen sich lokal ziehen:

• git fetch (lädt erst mal eine lokale Kopie des Origin Repository runter)
• git checkout –b lokalername –track origin/remotename

ziehen.

Mit git checkout –b name erzeugt man übrigens einen lokalen Branch.

Git Bash Standardpfad ändern

Standardmäßig startet die Git Bash, wenn man sie startet, im Benutzerverzeichnis. Dies lässt sich ändern, wenn man dort eine Datei namens “.bashrc” anlegt (Dateierweiterungen müssen aktiviert sein!). Dort kann man dann einen cd-Befehl eintragen, z.B.:

cd /d/development/comwork

Danach startet die Bash immer in diesem Verzeichnis. Wenn das Verzeichnis nicht existiert, dann wird wieder das Benutzerverzeichnis genommen.

Übrigens könnt ihr hier auch Aliase eintragen, wie z.B.

alias g=’git’

So spart ihr euch täglich mehrfach das Tippen von 2 Buchstaben. Da kann einiges zusammenkommen, wenn man sehr Bash-affin arbeitet

 

Zu guter Letzt noch einen Vorschlag: Statt die .bashrc ins Benutzerverzeichnis zu legen, würde ich einen symbolischen Link einrichten. Dazu macht ihr die Windows Kommandozeile auf und tragt folgendes ein:

mklink .bashrc D:\DevelopmentSettings\.bashrc

Persönlich verwende ich das auch für ReSharper und Git Settings. So kann ich mir meine Settings über mehrere Plattformen synchronisieren.

Meine tägliche Portion Git – Cleaning

Wer Änderungen, welche noch nicht ins Repository commited wurden, rückgängig machen will, kennt vielleicht den Befehl

• git checkout .

oder

• git reset –-hard head

welcher Änderungen an Dateien, die bereits im Repository enthalten sind, rückgängig macht.

Wer aber untracked files hat oder Dateien, die über gitignore ausgeschlossen und somit nicht Teil des Repository sind, der benötigt den Befehl

• git clean –xdf

Meine tägliche Portion Git – Revert vs. Reset

Wenn man eine Änderung, die man bereits gepusht hat, rückgängig machen will, hat man 2 Optionen:

• Revert: git revert head
• Reset: git reset –-hard head~1 gefolgt von git push –f

Hintergrund ist folgender:

Client und Server befinden sich auf dem gleichen Ausgangsstand zum Zeitpunkt 0. Der Client macht ein commit und push die Änderung, sodass sowohl Client, als auch Server auf dem neuen Stand 1 stehen. Als konkretes Beispiel soll das hinzufügen der Datei ‘test.cs’ dienen, welche dem Repository hinzugefügt wurde.

Nun kann man einen sogenannten Negativ-Commit machen, bei dem der letzte Commit negiert wird. In unserem Beispiel mit der Datei test.cs wäre das ein Delete der Datei. Als Grundlage dient somit bei Client Stand 1, sodass problemlos der Commit auch gepusht werden kann, da auf dem Server ebenfalls Stand 1 vorliegt.

Bei einem Reset wird der letzte Commit rückgängig gemacht, sodass beim Client Stand 0 der aktuelle Stand ist. Wenn der Client nun auf den Server pushen will, dann versucht er Stand 0 gegen Stand 1 zu pushen, was der Server verweigert. Deshalb muss man mit git push –f explizit sagen, dass der Server den Push akzeptieren soll. Das entspricht also dem Verschieben des head-Zeigers in der Timeline.

Accessing Git without VPN/LAN connection

Setting up your Git repository while you’re in your company domain will bring up some trouble because the connection string is stored in your config. Follow these steps:

• Navigate into the invisible directory “.git” of your repository
• Open the “config”-File with notepad
• Search for “[remote "origin"]”
• Change the value of “URL”

For example, in my case it was git@ci:comwork which works fine, if i have VPN access. If i want to sychronate over the internet, i need to use git@repository.heco.de:comwork.git (notice: the suffix .git is optional; replace repository.heco.de with your address).

Adding a new developer to your Git Repository

First of all, this is just a walkthrough for Windows!

 

1. Download and install Git. I prefer the installation without msysGit

2. Install Git. Make sure you have admin rights (for example if you’re using the UAC). Here are my recommended settings:

 

 

3. Setup your git config. You should set at least the following two configuration settings:

git config -–global user.name “your name”

git config -–global user.email “your email”

You have to enter this commands in the Git Bash! After finishing, there should be a “.gitconfig” file in your user directory.

Here are some recommendations of mine. Feel free to just copy and paste it:

[alias]
    review = log -1 –patch
    unstage = reset head
    aa = add –all
    au = add –update
    s = status
    p = pull
    l = log –oneline -10
    k = !gitk –all & –all &
    aua = !git add –update && git commit –amend –reuse-message=HEAD
    aaa = !git add –all && git commit –amend –reuse-message=HEAD
    amend = commit –amend –reuse-message=HEAD
    aucp = !sh -c ‚git add –update && git commit -m \"$1\" && git push‘ –
        aacp = !sh -c ‚git add –all && git commit -m \"$1\" && git push‘ –
[branch]
    autosetupmerge = true
    autosetuprebase = always
[color]
    ui = auto
    wtf = true
[color "diff"]
    old = bold red
    new = bold green
    meta = bold yellow
[color "branch"]
    current = black green
    local = bold green
    remote = yellow
    plain = bold yellow
[color "status"]
    added = bold red
    changed = bold green
    untracked = bold cyan
    nobranch = red reverse
[color "interactive"]
    prompt = bold green
    error = bold red

4. Generate the RSA Keys by entering the following command in the bash shell:

ssh-keygen –C “your name” –t rsa –v

Be careful: Don’t enter a filename as it won’t generate the needed .ssh directory in your user dir! Read more in this article.

If the operation was successful, you will find the private and public keys in your user directory in the invisible direcotry “.ssh”. It’s important that the filenames are “id_rsa” and “id_rsa.pub” because Git is using by convetion these files to access the server.

5. Copy the “known_hosts” file from a co-worker and put it into your .ssh directory.

6. Add your public key to the remote git server. In my case, i have a local copy of the gitolite-admin directory on the server.  So all i have to do is adding the new public key to the “keydir” directory and edit the “gitolite.conf” file in the “conf” directory:

 

7. Create a local copy of the development repository:

git clone git@ci:WebDevelopment.git

WebDevelpment.git is the name of the repository and ci is the server name. Make sure you are in the directory where you want to create the clone!

 

8. Some more references

http://help.github.com/win-set-up-git/

http://kylecordes.com/2008/git-windows-go

 

9. Think about using symbolic links for the “.ssh” dir and the “.gitconfig” file. You can use the mklink command from windows. I use this way to sync all my machines.

Meine tägliche Portion Git

Wir haben kürzlich von Subversion auf Git gewechselt, sodass ich täglich Neues lerne. Jeder Entwickler kennt es: Man möchte etwas testen und legt sich dazu einen neuen Branch an. Auf diesem entwickelt man dann seine Änderung/ sein Feature bis man das Ergebnis wieder in den Master Branch mergen will. Genau das nehme ich nun als Ausgangssituation:

Zuerst lasse ich mir nochmal alle Branches auflisten:

• git branch –a

 

Ich habe den neuen Code auf dem Branch ‘PersistenceRefactoring’ entwickelt. Nachdem ich alle Änderungen eingecheckt habe, wechsle ich auf den Master Branch zurück:

• git checkout master

Danach aktualisiere ich mir erst einmal meine lokale Version über:

• git pull

In der Regel sollte hier ein FastForward möglich sein. Nun wird gemergt:

• git merge PersistenceRefactoring

Idealerweise könnt ihr mergen ohne Konflikte zu bekommen. Alternativ könnt ihr beim Merge auch angeben, welche Seite gewinnt (in diesem Beispiel mein Developer Branch):

• git –s recursive –X theirs PersistenceRefactoring

Nützliche Git und Bash Shell Tipps

In dem Artikel Git Aliase habe ich kurz die “.gitconfig” erwähnt. Da so gut wie jeder Entwickler mehrere Maschinen nutzt und normalerweise gerne mit den gleichen Einstellungen arbeitet, gilt es die benötigten config-Files zu synchronisieren. Neben der zuvor erwähnten Datei sollte man auch noch die “.bashrc” (ebenfalls im Homeverzeichnis des Users) sichern, die die Einstellungen für die Bash Shell enthält. Ich für meinen Teil habe das so gemacht, dass ich die Dateien in einem Verzeichnis, welches ich über alle meine Maschinen synchronisiere, abgelegt und mit hard links darauf referenziert habe. Windows bietet dafür den Befehl “mklink” an. Für die ganz faulen Tipper unter euch, poste ich hier den Inhalt aus meinen 2 config-Files:

.gitconfig

[alias]
    review = log -1 –patch
    unstage = reset head
    aa = add –all
    au = add –update
    s = status
    p = pull
    l = log –oneline -10
    k = !gitk –all & –all &
    aua = !git add –update && git commit –amend –reuse-message=HEAD
    aaa = !git add –all && git commit –amend –reuse-message=HEAD
    amend = commit –amend –reuse-message=HEAD
    aucp = !sh -c ‚git add –update && git commit -m \"$1\" && git push‘ –
    aacp = !sh -c ‚git add –all && git commit -m \"$1\" && git push‘ –

.bashrc

alias g=’git‘

Außerdem will ich noch kurz auf Einstellungen für die Bash Shell verweisen, welche ich sinnvollerweise von Alexander Groß übernommen habe:

 

Öffnet dafür die Bash Shell, klickt rechts auf dem Rahmen und geht in Standardwerte. Schaut euch insbesondere die Fensterpuffergröße und die Bearbeitungsoptionen an. Um auch diese Einstellungen einfach auf alle Maschinen zu bringen, könnt ihr euch den Registry-Schlüssel “HKEY_CURRENT_USER\Console” exportieren.

Git Aliase

Wer wie ich nicht immer die gleichen 3 Befehle zum Hinzufügen, Commiten und Pushen von Änderungen zum Git Repository ausführen will, kann sich sogenannte Aliase definieren. Der folgende Screenshot zeigt 2 Aliase, die ich mir in meine benutzerbezogene “.gitconfig” eingetragen habe. Zeile 1 fügt lediglich geänderte Dateien hinzu, während Zeile 2 alle Änderungen hinzufügt:

 

Hier noch textuell:

!sh -c ‚git add –update && git commit -m \"$1\" && git push‘ –

!sh -c ‚git add –all && git commit -m \"$1\" && git push‘ –

Alternativ sollten auch folgende Zeilen funktionieren:

"!f() { git add –-update; git commit -m \"$1\"; git push; }; f"

"!f() { git add –all; git commit -m \"$1\"; git push; }; f"

 

Beachtet, dass ihr die Aliase nicht über den entsprechenden Git Befehl anlegen solltet, da es sonst ggf. Probleme mit den Hochkommata gibt. Editiert stattdessen die besagte .gitconfig in eurem Homeverzeichnis. Das könnt ihr über den Befehl

vim .gitconfig

machen, wenn ihr euch im richtigen Pfad befindet.

Danke an dieser Stelle an Alexander Groß für seine Hilfe dabei.