We are building our branch portal software discoverize on top of the mature Orchard CMS and incorporate important changes from the Orchard sources into our own software. Today, I wanted to add the CacheManagerExtensions class to discoverize to take advantage of some optimizations to the cache population strategy. The first commit contained changes to no less than 27 files. Manual work: go away! So I thought to myself: I'll just get the patch for this commit and apply it to my working directory :-) Well, guess what? There's no magic patch button on the commit page anywhere. Google and this blog post to the rescue… Download a Commit as a Patch It turns out to be as easy as adding .patch to the end of the commit url – and you get a beatiful text screen that you can save to a .patch file. Applying as much of a patch as possible Use git apply --reject abc.patch to apply all of the patch that can be applied to your current working directory – for the rest of the differences in the commit, reject files (.rej) will be created to not loose track of them. And that's all. Happy patching!

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   Ruft man nun aus der git gui “run merge tool” oder von git bash “git mergetool” auf, dann erscheint:     :-)

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