Entwicklungsumgebung

Es gibt vielearrow-up-right integrierte Entwicklungsumgebungen/IDEsarrow-up-right. Zwei werden sich für das Development von Adempiere favorisiert. Unabhängig davon für welche IDE man sich entscheidet, die Wahl des Versionsverwaltung ist nicht frei, denn die zentrale Ablage für das Adempiere Projekt ist git, genauer GitHubarrow-up-right.

Konfigurationsmanagement

zum Softwarekonfigurationsmanagement/SCMarrow-up-right gehört die Versionsverwaltung von Ergebnissen, Quellen und Dokumenten, Change-Management und Änderungsverfolgung, Build und Deployment.

Die zentrale Versionsverwaltung und das Change-Management befinden sich auf GitHub unter https://github.com/adempiere/adempierearrow-up-right.

Versionsverwaltung

Es gibt unzählige Version Control Systeme/VCSarrow-up-right. Neben lokalen Systemen Unix-SCCSarrow-up-right und den klassischen zentralen Systemen CVSarrow-up-right oder Apache Subversionarrow-up-right gibt es die verteilten DVCSe (Distributed Version Control System). Einen guten Einblick bietet der folgende Artikelarrow-up-right.

Neuere Systeme zur Versionsverwaltung sind verteilt. Es gibt keinen eindeutigen Server mit dem Sourcecode-Repository. Bekannte DVCS-Vertreiter sind Mercurial hg, Gitarrow-up-right und Bazaar.

Github

Githubarrow-up-right ist ein webbasierte Dienst für Git-Projekte wie ADempierearrow-up-right.

Forking

  • wir haben nur lesenden Zugriff auf adempiere github repoarrow-up-right

  • wenn ich also lokal eine Kopie/clone des adempiere repo mache, dann darf ich zwar ein checkout/pull machen, aber keinen push

  • ergo kann ich keine von mir erstelltn Änderungen einspielen

  • mit einem REMOTE-fork repo klst-com/adempierearrow-up-right, das ich ebenfalls lokal clonen kann, lässt sich das commit-Problem umgehen

  • denn ich habe als owner schreibenden Zugriff auf den REMOTE fork

pull-requests

siehe https://help.github.com/en/articles/about-pull-requestsarrow-up-right

Beispiel: PR zu Ticket 1340arrow-up-right "Enlarge length for address ..."

  • neuen branch erstellen, dieser sollte vom branch "develop" abgeleitet sein (das Folgende erstellt den branch und checkt ihn gleich aus):

  • files hinzufügen oder ändern ...

  • mit status Änderungen prüfen, da gibt es tipps:

  • neue files mit add registrieren und committen mit -m/--message= :

  • push diesen branch zu meinem remote github repo :

Cherry-picking

Beispiel: Issue https://github.com/adempiere/adempiere/issues/2231arrow-up-right

Der erste PR 2232arrow-up-right wurde nicht integriert, -> Closed with unmerged commits. Denn die commits fielen zeitlich mit der Relrasefreigabe von 3.9.1 zusammen. Im zweiten Anlauf mußten die commits aus dem pull 2232 rausgepickt werden und in einem neuen PR bereitgestellt werden. Die dabei entstehenden Konflikte müssen aufgelöst werden. Diesen Vorgang nennt man cherry-picking.

PR 2232 besteht aus mehreren commits. Hier das cherry-picking im cmd-line modus:

  • schon beim ersten commit gibt es Konfilkte

  • Auflösung im Editor oder in diesem Fall mit der "theirs"-Strategie und anschliessendem commit, einmal für die updates, dann für die renames:

  • die restlichen commits (ohne Konflike):

Last updated