Git house keeping

Über die Entwicklungszeit eines Projektes sammeln sich im Git viele Feature Branches, die man oft vergisst wegzuräumen. So geht es:

Löschen von lokalen Branches:

1. git checkout master
2. git branch -l | grep --color=never -v master | xargs git branch -D

Löschen von remote Branches:

1. git branch -r | grep --color=never -v master | xargs git push origin --delete

Zurück auf den alten Stand mit Git

Wenn man z.B. den Master oder einen wichtigen Branch zerstört hat und auf einen funktionierenden Softwarestand zurückkehren möchte muss man folgende zwei Schritte durchführen:

1) Den HEAD auf den entsprechenden funktionierenden Commit zurücksetzen und diese Änderung auf den Master pushen:
git revert --no-commit 14y6c335..HEAD
git commit
git push
Jetzt funktioniert der Master und Head wieder.


2) Lokal sind noch die alten, also die defekten Daten vorhanden, die kann man jetzt ggf editieren oder einen neuen Branch erzeugen oder einfach zurücksetzen. Dann ist die lokale Kopie wieder identisch mit dem Master und Head.
git reset HEAD --hard

Sicherheitsproblem API Token

API Token sind eine einfache Möglichkeit um den Zugriff auf z.B. Rest API zu steuern. Ein API Token ist in der Regel ein längerer String mit zufälligem Inhalt, der dem Programmierer den Zugriff auf das API erlaubt. Der Benutzer bzw. Programmierer wird identifiziert sich mittels des API Tokens. Wie Kristopher Sandoval in seinem Blog Artikel ausführt, sollten man kritisch auf die scheinbare Sicherheit der API Token schauen. Zum Umgang mit API Token hier ein paar Tipps:

1. Einen API Token sollte man wie privaten SSH Key behandeln. 
2. Man sollten ihn auf keinen Fall innerhalb des Projektes, egal ob in einer plain Textdatei oder im Code haben. 
3. Im einfachsten Fall sollte man den API Token im hoffentlich gesicherten User Verzeichnis ablegen, auf dem hoffentlich verschlüsseltem Disk Volumen.
4. Bei Rest APIs sollte der API Token nur per sicherem HTTPS benutzt werden.
5. Der API Token sollte nie in öffentliche Code Repos wie Github gepostet werden. Das Entfernen von solchen Git Pushes ist kein Spass. Hier kann ein Git Hook (pre-commit) hilfreich sein, der den Code nach verdächtigen Strings oder Dateien durchsucht.
6. Auch sollten sie nicht in Wikis abgelegt werden.

Links:

1. http://nordicapis.com/why-api-keys-are-not-enough/
2. http://www.programmableweb.com/news/why-exposed-api-keys-and-sensitive-data-are-growing-cause-concern/analysis/2015/01/05

Neues Java Projekt gelauncht: Simple Guitar Tuner

Ich habe auf Github ein kleines Projekt simpleguitartuner gelauncht und das erste Release gebaut. Mit ihm kann sehr einfach die Saiten einer Gitarre stimmen. Im Gegensatz zu den anderen Tuningprogrammen ist dieses sehr präzise bezüglich der Frequenzen. Das Programm wird gestartet: java -jar simpleguitartuner-0.0.1.jar und gestoppt mit CTRL + C. Einfacher geht es nicht. Nach dem Start gibt die Saite an, die man stimmen möchte, dann spielt man die Saite und bekommt das Ergebnis und den Sollwert sehr genau angezeigt. Das geht so lang, bis man das Programm beendet.

Hier die Daten:

• GPL, based on http://sourceforge.net/projects/guitartuner
• Pure Java, current Java 7
• Maven + Git
• No depedencies

HOWTO: Releasing a new Software Version with Maven and Git.

Ausgangslage:

• Versionsverwaltung mit Git und Feature Branches
• Ich befinde mich auf dem Branch development 
• Alle Fehler auch Javadoc Fehler sind beseitigt
• Alle Änderungen commitet und gepushed
• Java
• Maven 3 und SNAPSHOTS
• Nexus

Wie mache aus meiner einer aktuelle Entwicklung ein Release?

1. mvn deploy, um die letzte Development Version als SNAPSHOT im Nexus zu veröffentlichen
2. mvn versions:resolve-ranges, um Dependencies mit Range Angaben zu konkreten Versioen aufzulösen, sonst scheitert der Release-Vorgang
3. mvn versions:use-latest-releases, um die Dependencies zu aktualisieren auf deren letzten Release-Stand
4. git commit, um die Änderungen an der pom.xml in Git Repository zu übertragen
5. git checkout master
6. git merge development
7. mvn release:prepare
8. mvn release:perform
9. git commit, um die Änderungen an der pom.xml in Git Repository zu übertragen
10. git checkout development
11. git merge master

Das beschreibt den kompletten Weg ein Release zu erstellen vom Development Branch und wieder zurück. Ach ja, und natürlich das Testen nicht vergessen.

Wenn etwas schief geht:

1. Entfernen von Tags aus Git:
1. git tag listet alle Tags auf
2. git tag -d tagname entfernt den entsprechenden Git Tag aus dem lokalen Git Repo
3. git push --delete origin tagname entfernt den entsprechenden Git Tag aus dem entfernten Git Repo
2. Test im Release Prozess wirklich überspringen: mvn release:perform -Darguments="-DskipTests"