Macht das Leben leichter:

Die GIT GUI in deutsch macht oft nicht sonderlich viel Sinn:

Am einfachsten bekommt man eine englische Version, in dem man die Sprachdatei löscht oder umbenennt. Die Sprachdateien der GIT-GUI befinden sich bei mir unter: C:\Program Files (x86)\Git\share\git-gui\lib\msgs

Danach machen die Begriffe auch wieder Sinn :-)

Nach einer Default Installation mit msygit steht kein graphisches DIFF/Merge Tool bereit. Möchte man nun einen Konflikt lösen,

erscheint diese Fehlermeldung:

Abhilfe

Es gibt eine Vielzahl von unterstützten Merge Tools. Mir persönlich hat p4merge am Besten gefallen. Es folgt in kurzen Schritten das einrichten und konfigurieren von p4merge:

1:) Download

P4Merge  kann hier: http://www.perforce.com/perforce/downloads/latest.html heruntergeladen werden.

2:) Konfigurieren von GIT.

Der Pfad der Konfigurationsdatei ist für die Default Installation:  "C:/Users/[YourUsername]/.gitconfig".

Die .gitconfig muss so erweitert werden:

[merge]    

    tool = p4merge

[mergetool "p4merge"]

    cmd = \"C:\\Program Files\\Perforce\\p4merge.exe\" $PWD/$BASE $PWD/$LOCAL $PWD/$REMOTE $PWD/$MERGED

    trustExitCode = false  

    keepBackup = false    

3:) Freude

Wir hatten gerade eine Diskussion zum Nutzen von “Feature-Branches”, “Long-Running Branches” und “Topic Branches”. Das Gespräch bezog sich auf die Nutzung mit GIT. Zunächst eine kurze Klärung der Begriffe:

• “Feature-Branches”, für ein Feature wird eine neuer Entwicklungszweig genutzt
• “Branch-per-Configuration”, es wird kein physischer branch erzeugt, sondern die Entwicklung erfolgt im Hauptzweig. Ein entwickeltes Feature läst sich per Konfiguration ein und ausschalten.
• “Long-Running Branches”, Ein Branch der länger als ein paar Tage genutzt wird
• “Topic Branch”, Ein Branch der kurzlebig ist. Kurzlebig sind ein paar Minuten oder Stunden.

Aus meiner Perspektive sind Feature-Branches und Long-Running-Branches - wenn möglich - zu vermeiden. Ideal ist sind “Branches per Configuration”, die bei der Entwicklung ein modulares Arbeiten und damit eine gute Architektur erzwingen. Aufwände für das mergen werden vermieden. “Topic Branches“ sind durchweg positiv, wenn sie lokal bleiben und nicht zu entfernten Repositories gepushed werden.

Branch per Refactoring

Es kam auch kurz das Gespräch auf das Thema “Branch per Refactoring” bzw. eine Refaktorisierung wurde als “Feature Branch” bezeichnet. Aus meiner Sicht deutet das auf einen CodeProcess-Smell hin. Die Refaktorisierung ist zu groß.  Refaktorisierungsschritte sollten klein sein und ein Arbeitsschritt direkt wieder in den Hauptentwicklungszweig einfließen können.

Unser “.gitignore” File für die Verwendung mit Visual-Studio und Resharper.

_svn/
.svn/
obj/
[Bb]in/
[Dd]ebug/   
[Rr]elease/   
_Re[Ss]harper.*
*.resharper
*.resharper.user
*.suo
*.cache
*~
*.swp