Entwicklungsumgebung
Es gibt viele integrierte Entwicklungsumgebungen/IDEs. 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 GitHub.
Konfigurationsmanagement
zum Softwarekonfigurationsmanagement/SCM 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/adempiere.
Versionsverwaltung
Es gibt unzählige Version Control Systeme/VCS. Neben lokalen Systemen Unix-SCCS und den klassischen zentralen Systemen CVS oder Apache Subversion gibt es die verteilten DVCSe (Distributed Version Control System). Einen guten Einblick bietet der folgende Artikel.
Neuere Systeme zur Versionsverwaltung sind verteilt. Es gibt keinen eindeutigen Server mit dem Sourcecode-Repository. Bekannte DVCS-Vertreiter sind Mercurial hg, Git und Bazaar.
Github
Github ist ein webbasierte Dienst für Git-Projekte wie ADempiere.
die adempiere repo Administratoren mit Schreibrechten sind Victor Perez und Yamel Senih
weitere Ansprechpartner:
Forking
wir haben nur lesenden Zugriff auf adempiere github repo
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/adempiere, das ich ebenfalls lokal clonen kann, lässt sich das commit-Problem umgehen
denn ich habe als owner schreibenden Zugriff auf den REMOTE fork
abschliessend kann ich mit einem pull-request meine Änderungen an das adempiere repo weitergeben, wo einer der Administratoren es in das Projekt integriert (merge), siehe https://github.com/adempiere/adempiere/pulls - oder auch nicht: closed pulls
pull-requests
siehe https://help.github.com/en/articles/about-pull-requests
Beispiel: PR zu Ticket 1340 "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 :
Abschliessend auf github mit diesen branch den "pull request"/PR erstellen für https://github.com/adempiere/adempiere
Cherry-picking
Beispiel: Issue https://github.com/adempiere/adempiere/issues/2231
Der erste PR 2232 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