Jahresrückblick 2013


Die WordPress.com-Statistik-Elfen fertigten einen Jahresbericht dieses Blogs für das Jahr 2013 an.

Hier ist ein Auszug:

Ein New York City U-Bahnzug fasst 1.200 Menschen. Dieses Blog wurde in 2013 etwa 4.700 mal besucht. Um die gleiche Anzahl von Personen mit einem New York City U-Bahnzug zu befördern wären etwa 4 Fahrten nötig.

Klicke hier um den vollständigen Bericht zu sehen.

BitCoin in der Praxis


Heute einfach nur der Hinweis auf einen kleinen Artikel über meine ersten Gehversuche mit BitCoins auf meinem Partner Blog. Letzterer befasst sich weniger mit technischen als eher mit sozial politischen Themen.

Doch sowie ich die technischen Konzepte von BitCoin besser verstanden habe, werde ich auch über diese hier auf meinem Entwickler Blog berichten.

Huluvu's Blog (de)

Flattr this

Motivation

Schon seit einiger Zeit habe ich BitCoins erworben und suche nach Möglichkeiten diese wieder auszugeben. Ich halte diese Währung nicht für ein Allheilmittel – im Gegenteil – aber ich finde es gut, dass an dem veralteten Währungssystem eine Neuerung vorgenommen wurde, die Dezentralisierung. Viel Leid und Elend auf dieser Welt entsteht durch eine zentrale Kontrolle von Weltwährungen. Obgleich sich jeder demokratische Staat über den Zentralismus in sozialistischen Staaten aufregt so stört es doch keinen, dass das Geld stets zentral vom Staat kontrolliert wird. Sogar weltweit gibt es zentrale Banken von denen in der Regel nicht einmal bekannt ist wer eigentlich die wirklichen Eigentümer (Aktionäre) im Hintergrund sind – siehe Federal Reserve System .

Daher suche ich also ein Geldsystem bei dem ich Geld erwerben, lagern und ausgeben kann ohne das Risiko eingehen zu müssen das man mir morgen erklärt das mein Geld wegen einer Finanzkrise nicht mehr verfügbar…

Ursprünglichen Post anzeigen 845 weitere Wörter

GUIs deklarativ – never ending story


Flattr this

Motivation

Der Traum eine Programmoberfläche möglichst einfach, mit wenig Text und doch mit exakter Anordnung der GUI Elemente beschreiben zu können ist schon sehr alt. Immer wieder tauchten dazu Konzepte auf – doch diese konnten sich am Markt nie wirklich fortsetzen, nicht zu Letzt auch mangels der Unterstützung großer Firmen. Das letzte mir bekannte Exemplar ist JavaFX Script welches nun auch schon fast als ausgestorben bezeichnet werden kann.

Für alle die sich dennoch eine deklarative Sprache für die GUI Entwicklung wünschen zeigt dieser Artikel Projekte und mögliche Fortsetzungen auf.

Thinlet

Das erste mir bekannte Projekt welches seine GUI deklarativ beschrieb war Thinlet. Ich nenne es mal Thinlet one denn der Autor hat das Projekt inzwischen eingestampft und hat unter gleichem Namen ein völlig neues Framework herausgebracht. Letzteres konnte mich aber nicht weiter begeistern.

Das ursprüngliche Projekt war im Prinzip ein Jar mit einer Klasse. In dieser Klasse war die gesamte Logik. In der eigenen Anwendung waren die Oberflächen dann per xml zu beschreiben. Das Framework unterstützte sogar bereits das Binding von GUI Elementen an Java Klassen. Allerdings war das Eventhandling irgenwie nicht optimal gelöst – ich hatte damit jedenfalls Probleme – ich glaube mit der Richtung aus Java Klasse zum GUI Element oder von GUI Element zu GUI Element. Das kann ich leider nicht mehr genau sagen.

Dokumente zum ursprünglichen Projekt lassen sich kaum noch finden – man muss halt ein bisschen googeln denn die URLs wechseln stetig – aber offensichtlich gibt es noch genug Leute welche die Dokumentation retten. Hier ein Beispiel: http://wolfpaulus.com/thinlet/doc/widget/overview.html

Canoo

Diese Firma muss ich hier einfach aufzählen, weil sie mit ULC (Ultra Light Client) das fertiggestellt hat von dem alle Welt träumt. Allerdings proprietär und teuer 😦 Das war der Grund weshalb ihr Framework für den Open Source Bereich nicht in Frage kommt. Aber die Technologie ist genial – Half Object Plus Protocol (HOPP) Entwurfmuster. Das wäre das Ziel nur eben frei und Oracle hat es mit JavaFX eindeutig vermasselt. Hier ein Beispiel wie leicht alles gehen könnte.

GUI4J

Das GUI4J Projekt funktionierte ähnlich wie Thinlet wurde aber von mehr Leuten entwickelt und länger durchgehalten.

Zu guter Letzt gibt es natürlich tausende Projekte die in Richtung XML deklarierte Oberfläche gehen aber keine welches wirklich später dafür relevant wurde. Hier eine von vielen Listen die im Internet findbar sind: http://www.java2s.com/Product/Java/XML/XML-UI.htm

JavaFX

JavaFX in der ersten Version hatte mit JavaFX Script wirklich Potential den Sprung in Richtung Canoo zu schaffen. Doch Oracle hat es getötet aus welchen Gründen auch immer: http://www.heise.de/developer/meldung/Das-endgueltige-Aus-fuer-JavaFX-Script-1444903.html

JavaFX selbst hat Oracle dennoch zur Schlüsseltechnologie erhoben. Bislang steht diese allerdings irgendwo außerhalb des aktiv von Oracle gepushten ADF. ADF selbst setzt weiterhin auf Swing und eine dirty Click and Drop Oberfläche. Letztere hinterlässt in der Praxis nach einiger Zeit auch gern mal korrupte Arbeitsstände. Dann darf der Entwickler wieder zurück auf LOS ohne einen Erfolg einzustreichen. Wie soll man also die Signale aus dem Hause Oracle deuten? Möglicherweise ist sich Oracle intern selbst uneins und setzt später einfach auf die Technologie die sich durchsetzt. Einige Entwickler greifen daher selbst zur IDE und bauen schon wieder ihre eigenen RIA Frameworks:

Captain Casa Framework

Da ich dieses RIA Dilemma schon einige Zeit betrachte setzte ich immer wieder meine Hoffnung auf das Captain Casa Framework. Captain Casa ist eine Firma welche für den lokalen Mittelstand diverse Softwarelösungen erarbeitet hat. Diese basieren alle auf dem Captain Casa Framework. Diese wiederum setzte bis vor einigen Jahren ausschließlich auf Swing, sprang aber nach Erscheinen von JavaFX sofort auf diesen Zug auf. Aktuell steht wieder ein Community Treffen an und ich hoffe das es mir dieses Jahr endlich wieder möglich ist teilzunehmen und meinem kurzfristigen Urlaubsantrag zugestimmt wird. Falls ja werde ich natürlich wieder über das Treffen berichten.

Anbei ähnliche Artikel zum RIA Dilemma

Eigene Bilder schützen


Flattr this

Motivation

Bei der Open Source Projektarbeit werden oft kleine Bildchen benötigt. Um keine Copyright Verletzungen zu begehen stelle ich mir diese selbst mit Gimp oder Blender her. Was mir dabei bislang noch nicht richtig gelang, ist eine Copyright Notiz im Bild zu hinterlegen. Der Bereich den Gimp dafür vorhält ist oft zu klein. Daher war ich auf der Suche nach Methoden wie ich Dateien mit Copyright Notiz ins Bild bekomme. Auf SemperVideo habe ich entsprechende Informationen gefunden.

Dateien verketten

Die einfachste Variante ist das anketten zusätzlicher Informationen. Dazu wird ganz simple der copy Befehl genutzt. Das Bild und seine Header Daten landen im Anfangsbereich. Die Zusatzinformation wird als Zip angehangen und landet im Ende Bereich. Bilddarstellungsprogramme lesen die Bildinfos auf Grund des Headers und Entpacker lesen die Pack Infos aus dem Ende Bereich. Damit können in einer scheinbaren Bilddatei die Bilddaten und die Zusatzdaten zeitgleich parallel existieren. Nachteil dieser Methode ist ganz klar, die Zusatzdaten lassen sich völlig unkompliziert wieder von den Bilddaten trennen. Daher ist diese Methode nur sinnvoll wenn das Bildformat kein einbetten von Dateien unterstützt.

Und so wird es unter Windows gemacht.

>copy /b image.jpeg +copyright.zip newimage.jpg

Quelle: Das Ganze habe ich aus folgendem SemperVideo indem es super erklärt wird.

Dateien einbetten

Zunächst müssen wir unsere Copyright Notiz (welche wieder als zip Archiv vorliegen sollte) mit uuencode „verschlüsseln“. Mit dem Exif Tool wird die Datei dann in den Kommentarbereich der Bilddatei eingeschleust.

>uuencode copyright.zip copyright.uue
>exiftool -Comment“<=“copyright.uue image.jpeg

Diese Info sollte solange erhalten bleiben bis jemand die EXIF Daten und dabei speziell den Kommentar verändert.

Quelle: Das Ganze habe ich aus folgendem SemperVideo indem es super erklärt wird.

Eclipse Committer werden


Flattr this

Motivation

Warum will man eigentlich Eclipse Committer werden? Da kann es mehrere Gründe geben:

  • Man will an einem Projekt welches unter Verwaltung der Eclipse Foundation steht mitarbeiten
  • Man hat an den Quellen eines Projektes der Eclipse Foundation lokal oder auf einem Fork Änderungen vorgenommen und möchte diese ins Hauptprojekt einbringen. Bei Verwendung von Git ein sogenannter Pull Request.
  • Weil es einfach Inn ist von sich behaupten zu können man entwickle an einem offiziellen Eclipse Projekt mit 😉

Jeder der von einem der obigen Motive angesprochen wird, möchte früher oder später auch seine Änderungen committen. Doch bevor er das darf muss die Eclipse Gemeinde ihm die Rechte dazu einräumen.

Auf Sourceforge.net war das letztlich oft das K.O. Kriterium weshalb viele Entwickler gar nicht erst versucht haben Kontakt mit dem Projektowner aufzunehmen. Die nervigen Aufnahme Rituals, oft mussten zunächst die Änderungen per tgz file für das Review per Mail versendet werden und ähnliches. Das alles nahm wesentlich mehr Zeit in Anspruch als die paar Kleinigkeiten einfach einzuarbeiten und das Projekt selbst auf der eigenen Homepage entsprechend den Lizenzvorgaben weiter zu hosten.

Dessen ist sich die Eclipse Foundation offensichtlich auch bewußt und hat ihren Prozess dahingehend optimiert und teilweise automatisiert. Doch die tausenden Wiki Seiten und hilfreichen Links zu allerlei Einsteiger Themen versperren oft den Blick auf die Links die wirklich notwendig sind.

Wie werde ich Committer in einem Eclipse Projekt?

Im Prinzip ganz einfach. In der Praxis müssen scheinbar 3 Dinge erfüllt sein:

  1. Man muss jemanden kennen der ein Interesse daran hat, das man aufgenommen wird.
  2. Jeder Commit muss mit einer Signed-by Zeile versehen werden
  3. Man muss die CLA gelesen, akzeptiert und rechtsverbindlich unter schrieben haben.

 

Punkt 1

Dieser ergibt sich meist von selbst indem man auf github ein interessantes Projekt der Eclipse Foundation (https://github.com/eclipse) oder eines Ihrer Mitglieder sucht und von diesem einen Fork erstellt. Auf diesem Fork – der ja nun der eigene ist – kann man alle Features seines Herzens einarbeiten und nach Fertigstellung einen Pull Request an den Projekt Owner stellen.

Punkt 2

Jeder Commit muss unterzeichnet werden. Dazu gibt es klare Vorgaben und am besten fährt man, wenn man in Eclipse folgende Einstellungen vornimmt:

Windows/Preferences/Team/Git

  • Commit Dialog: Insert Signed-off-by aktivieren
  • Configuration: In die Felder email und name die richtigen Werte eintragen (diese werden später beim Unterschreiben der CLA benötigt)

Punkt 3

  1. Die weiteren Schritte sind nur sinnvoll wenn Du die CLA akzeptieren willst.
  2. Registrieren unter: https://dev.eclipse.org/site_login/createaccount.php
    (mit dem Namen und der eMail aus den Signed-off-by Einstellungen)
  3. Unterschreiben der CLA unter https://projects.eclipse.org/user/login/sso

Das wars – ihr habt es geschafft.

Also dann viel Spaß beim Mitarbeiten:)

Eclipse konfigurieren


Flattr this

Motivation

Mit jeder neuen Eclipse Version die man installiert oder mit einem neuen Workspace fängt man wieder an die immer gleichen Einstellungen vorzunehmen, welche man für sich entdeckt hat. Das geht Ihnen vermutlich genauso wie mir. Von daher wollte ich mir einfach mal aufschreiben welche Einstellungen ich immer so vornehme und warum bzw. was ich daran als Vorteil oder Nachteil sehe.

Hat man seine Settings einmal festgelegt können diese übrigens über File/Export/Generell/Preferences exportiert bzw. über File/Import/Generell/Preferences auch wieder im neuen Workspace importiert werden. Wichtig ist aber, dass vor dem Import die entsprechenden Plugins installiert wurden.

Einstellungen unter Windows/Preferences

Diese Einstellungen wirken sich auf die installierten Plugin’s aus. Da die Plugins ihre Daten im .metadata Verzeichnis des aktuellen Workspace ablegen, sind sie im nächsten Workspace wieder neuzukonfigurieren.

Encoding

Generell/Workspace->Text file encoding auf UTF-8 setzen. Unterstützt die plattformübergreifende Arbeit inWindows und UnixUmgebungen.

Text Editoren

Generell/Editors/TextEditors

  • Show Print Margin aktivieren und auf 80 Zeichen setzen. Damit wirdbarrierefreies entwickelnunterstützt.
  • Show LineNumbersaktivieren.
  • Insert Spaces for tab aktivieren. Damit wird die plattformübergreifende Arbeit unterstützt. Deltas im SCM mit Unix undWinCommittern.

Git Support

Team/Git/CommitDialog

  • Insert Signed off by aktivieren. Manche Projekte z.B. die der Eclipse Foundation akzeptieren nurunterschriebeneCommits.
  • Include selected untracked files. Damit beim check in nixvergessenwird.

Team/Git/Configuration

  • email und name aktualisieren. Notwendig z.B. für Commits in offiziellen Eclipse Projekten.
    (in meinem Fall: funthomas424242@gmail.com und Thomas Schubert )

Code Style

Java/CodeStyle/Organize Imports

  • Number of static imports needed to .* auf 1 setzen. Das bringt den Vorteil das bei JUnit nicht immer assertEquals wieder zu Assert.assertEquals beim Organisieren der Imports gewandelt wird. Da man statische Imports ohnehin selten nutzen sollte kommt man gut damit zurecht.

Save Actions

Java/Editor/Save Actions

  • Perform selected action on save aktivieren. Dadurch werden beim Speichern bestimmte Schritte durchgeführt, die letztlich wenn es alle im Team aktiviert haben dazu führen, dass ein einheitlicher Kodestyle ganz von selbst entsteht. Somit gibt es in der Regel keine Differenzen im SCM nur Aufgrund unterschiedlicher Formattierungen. Vorraussetzungen sind natürlich die teamweite Nutzung der gleichen Formatierungsregeln.
  • Format source code / format all lines aktivieren. Nach dem Speichern sollte stets die ganze Datei formatiert werden. Geschützte Bereiche lassen sich dann immernoch mit //@formatter:off erzeugen und mit //@formatter:on die Formatierung im Kode wieder einschalten.
  • Organize imports aktivieren. Ganz wichtig die Importe sollten immer bereinigt werden. So werden ungenutzte Importe beim Speichern entfernt und die * Importe nach den gültigen Regeln aufgelöst.
  • Additional actions sollten auch aktiviert werden. Dadurch wird der Quellkode gesäubert. Einmalig initialisierte Variablen erhalten ein final, fehlende Override und Deprecation Annotationen werden ergänzt und unnötige Casts werden entfernt.

Einstellungen in den Projekteigenschaften

Diese Einstellungen hängen am Projekt und werden innerhalb des Projektes im .settings Ordner gespeichert. Sie funktionieren somit Workspace übergreifend, man muss nur das Projekt in denWorkspaceimportieren.

Auch diese Einstellungen lassen sich über File/Export/Generell/Preferences exportiert bzw. über File/Import/Generell/Preferences auch wieder im importierten.

 

Der Artikeln wird nach und nach ergänzt. Wer Tipps hat, bitte als Kommentar anfügen.

eGIT – eclipse plugin


Flattr this

Motivation

Statt ständig den Artikel über die Konfiguration der Eclipse Arbeitsumgebung anzupassen habe ich mich entschlossen lieber die von mir verwendeten oder evaluierten Plugins kurz zu beschreiben.

Heute habe ich ein Eclipse Plugin gesucht um ein Gitrepository auf Github einzubinden.

Zum Plugin

Das Plugin eGit Team Provider steht im Eclipse Marketplace zur Installation bereit. Es eignet sich hervorragend um ein Git Repository zu klonen und zu bearbeiten. Die Installation läuft wie bei Eclipse üblich – nach einem Neustart der IDE steht die neue Team Perspektive zu Verfügung. Man kann damit im Prinzip genauso wie vorher mit der CVS oder der SVN Perspektive arbeiten.

Wünschenswert

Das Plugin verfügt leider über keine Revert Funktion. Das ist für Umsteiger von SVN durchaus gewöhnungsbedürftig. Daher habe ich mir auf meinem lokalen PC noch TortoiseGit und das Git mit GitGUI und GitBash installiert. In der Kombination lässt es sich prima arbeiten. Was in Eclipse nicht geht wird mit TortoiseGit erledigt und eine Shell habe ich parallel auch offen um ab und an ein git status abzusetzen.

Markdown Text Editor – eclipse plugin


Flattr this

Motivation

Statt ständig den Artikel über die Konfiguration der Eclipse Arbeitsumgebung anzupassen habe ich mich entschlossen lieber die von mir verwendeten oder evaluierten Plugins kurz zu beschreiben.

Nachdem die letzte Suche ein Plugin brachte welches nicht ganz meine Ansprüchen genügte habe ich heute nun ein Plugin gefunden welches sowohl eine gute Preview einer Markdown datei im Editorbereich leistet wie auch noch einen einfachen Editor bereitstellt.

Zum Plugin

Das Plugin lässt sich generell im Marketplace der Eclipse „Kepler“ finden und zwar unter „Markdown Text Editor“. Allerdings ist es von dort nicht installierbar. Über „more Info“ gelangt man auf die Projektseite und dort findet man den eigentlichen URL für den Eclipse Update Site Manager:

http://winterstein.me.uk/projects/tt-update-site/

Diesen also für die Installation im Update Site Manager eingeben und schon kurz darauf ist das Plugin installiert.

Wenn wir nach dem obligatorischen Neustart der Eclipse ein md File öffnen wird automatisch schon der neue Markdown Editor benutzt. Allerdings sieht er auf den ersten Blick nicht anders aus als ein Texteditor und laut Beschreibung hat er auch nicht viel mehr Feature (allerdings soll er falten und ähnliches unterstützen).

Letztlich finden wir auch eine neue Markdown View. In dieser können wir die Preview eines md Files betrachten. Die View lässt sich mit etwas motorischem Geschick auch im Editor Panel als Tab anbringen.

Somit ist alles gut und wir haben das Plugin gefunden mit dem wir zukünftig unsere Markdown Dateien für Github bearbeiten.

GitHub Flavored Markdown Viewer – eclipse plugin


Flattr this

Motivation

Statt ständig den Artikel über die Konfiguration der Eclipse Arbeitsumgebung anzupassen habe ich mich entschlossen lieber die von mir verwendeten oder evaluierten Plugins kurz zu beschreiben.

Heute habe ich ein Eclipse Plugin gesucht um eine Datei im Markdown Format bereits am Rechner im endgültigen Layout sehen zu können. Bislang musste ich die Datei immer erst auf Github hochladen um das Ergebnis zu sehen. Aber diese kleinen, einzelnen Commits machen natürlich keinen Sinn. Daher einfach einen Viewer installiert.

Zum Plugin

Das Plugin „GitHub Flavored Markdown viewer plugin (update site)“ lässt sich einfach über den Marketplace in der Eclipse „Kepler“ installieren. Nach dem obligatorischen Neustart der Eclipse sucht man bei der Selektion eines *.md Files allerdings vergeblich im OpenWith nach einen neuen Eintrag.

Zunächst muss man unter Windows/Preferences/GFMViewer seine Login Daten für Github eintragen. Anschließend kann man jedes *.md auch über den Eintrag „Show in GFM view“ im Kontextmenü öffnen. Jetzt wird das Markdown File tatsächlich frisch gerendert dargestellt.

Allerdings merkt man gleich, dass es sich um keinen Editor handelt denn das Panel lässt sich nicht in an die Stelle des Editors platzieren. Jetzt kann man sich für eine waagerechte oder senkrechte Teilung entscheiden aber letztlich ist beides schlecht. Als Tab im Editorbereich lässt es sich einfach nicht einfügen und so bleibt nicht mehr viel Platz für den eigentlichen Editor.

Ergo wenn man die View braucht – öffnen und danach sofort wieder schließen.

Was lernen wir daraus? Eigentlich suchen wir ein Editor Plugin welches (wie der Plugin Wizard) eine Tab für die Darstellung des Kodes und eine für die Preview Ansicht besitzt.

Github – Pull Requests aktuell halten


Flattr this

Motivation

Auf Github kann jeder Nutzer auf einfachster Weise einen Fork von seinem Lieblingsprogramm erstellen und nach Lust und Laune auf diesem die gewünschten Features selbst implementieren. Sind diese fertiggestellt werden sie als Pull Request an den eigentlichen Projektowner gesendet.

In der Regel war dieser aber auch nicht untätig und hat sein Projekt auch weiterentwickelt. Oder er ist gerade mitten in der Entwicklung eines neuen Features und so bleibt der Pull Request eine ganze Weile liegen. In der Zeit häufen sich die Commits des Projektowners und der Stand auf dem der Pull Request basiert ist hoffnunglos veraltet.

Jetzt erst sieht der Projektowner den Pull Request und versucht in zu integrieren – doch leider hat sich das Projekt soweit weiter entwickelt, dass viele Versionskonflikte auftreten. Das möchte sich der Owner nicht antuen und fordert vom Ersteller des Pull Requests das er diesen bitte zunächst mit dem aktuellen Versionsstand abgleicht. Doch wie geht das? Genau das soll hier kurz beschrieben werden.

Vorraussetzungen

Bevor man einen Pull Request auf Github stellen kann, hat man in der Regel das Original Repository auf Github geforkt und davon einen Klone auf seinen lokalen Rechner gezogen.

Will man nun ein neues Feature implementieren sollte unbedingt ein neuer Branch für die Entwicklung des Features abgespalten werden. Dies hat den Vorteil, das man zeitgleich an verschiedenen neuen Features arbeiten kann ohne von der Fertigstellung oder der erfolgreichen Integration eines Features abhängig zu sein. Außerdem hält man sich so auch den master für eine stets lauffähige aktuelle Version frei. Letzteres ist gut, da es immer wieder mal Situationen gibt in denen man die gerade implementierte Lösung nach Fehlern durchsucht und dann ein Vergleich mit einer aktuellen, lauffähigen Version sehr hilfreich sein kann. Generell gilt aber auch auf Github pro Branch ist nur ein Pull Request möglich.

Aktualisierung des Branches

Die Lösung besteht im Prinzip darin bei der Entwicklung möglichst frühzeitig die neuen Änderungen des Owners in den eigenen featurebranch zu integrieren. Hierzu erzeugen wir uns einen Alias upstream im lokalen Git Repository.

(alles in eine Zeile schreiben, der Browser zeigt hier gern 2 Zeilen an)

git remote add –track master upstream git://github.com/owner/projectname.git

evtl. reicht auch die einfachere Variante

git remote add upstream git://github.com/owner/projectname.git

Als Werte für owner und projectname werden die Angaben des originalen Repositories verwendet von dem wir selbst unseren fork gezogen haben. Damit steht uns ein Alias für den Fetch bereit und diesen nutzen wir auch gleich. Wir befinden uns also aktuell im lokalen Projektverzeichnis und arbeiten auf dem Branch (also der Branch ist lokal ausgecheckt und in der Regel von uns auch schon editiert). Jetzt holen wir uns die Neuigkeiten vom Original Repository:

git fetch upstream

Wenn das funktioniert hat und das sollte immer funktionieren oder ihr habt Euch vorhin verschrieben oder das Internet ausgeschaltet, dann mergen wir die Neuigkeiten in unseren lokalen branch mit:

git merge upstream/master

oder die Variante ohne Auto Commit

git merge upstream/master –no-commit –no-ff

So jetzt noch ein bischen Konflikte lösen 😉 committen und falls nötig den Pull Request aktualisieren bzw. bitte auch dokumentieren. Kommunikation ist alles und hilft dem Projektowner bei der Bewertung und Einarbeitung Eures Pull Requests.

Also Happy Pulling 🙂

Und falls doch mal was schief geht und der ganze Branch zurück auf „Null“ – dem Stand des originalen Repositories – gebracht werden soll? Dann sollten diese Befehle helfen

git remote add upstream git://github.com/wp-cli/wp-cli.git (nur wenn wir den alias oben nicht schon angelegt haben)
git fetch upstream
git branch backup
git reset –hard upstream/master
git push –force

Damit habt ihr den aktuellen Branch zurück gesetzt.

Bei neueren Git Versionen scheint das Rücksetzen auf den upstream (er muss schon mit git remote add gesetzt wurden sein) wie folgt zu funktionieren:

git rebase –onto upstream/master

Diese Variante würde ich immer vorziehen, weil damit auch bereits veröffentlichte Dinge bearbeitet werden können.

 

Für Hinweise, Tipps, Anmerkungen und Kommentare bin ich stets dankbar.

 

Quellen:

http://gun.io/blog/how-to-github-fork-branch-and-pull-request/

http://scribu.net/blog/resetting-your-github-fork.html

http://www.senaeh.de/git-prinzip-beispiele/