Embed Size (px)
DESCRIPTION
Agility and OSLC with JasForge Project
Citation preview
Deutschland ! 9,80Österreich ! 10,80, Schweiz sFr 19,20 5.13
www.eclipse-magazin.de
©iS
tock
foto
.com
/Kng
kyle
2
www.software-architecture-camp.de
Das erwartet Sie im Camp: Fundierte, praxisnahe und pragmatische Einführung in Soft-warearchitektur mit hohem Übungsanteil. Sie lernen und üben die vielfältigen Aufgaben von Softwarearchitekten anhand von Fallstudien. Der Fokus liegt auf methodischem und systema-tischem Vorgehen bei Architekturentwurf und -bewertung. Beide Trainer betreuen Sie im Camp als Team. Erleben Sie ein einzigartiges Training mit spannenden Diskussionen, tiefen Ein blicken und dem außergewöhnlichen Wissen von zwei der besten Softwarearchitektur-Experten!
8. – 11. Oktober 2013, Berlin
www.software-architecture-camp.dewww.software-architecture-camp.de
Dr. Gernot Starke
Phillip Ghadir
MMMMMMiiiiiitttttt ZZZZZZeeeeeerrrtttiiifififizzziiieeerrruuunnngggzzzuuummm
MMMiiitttZZZeeerrrtttiiifififi
zzziiieeerrruuu
nnngggzzzuuu
mmm Certifi ed Certifi ed Certifi ed
Professional Professional Professional
for Software for Software for Software
Architecture Architecture Architecture
iSAQB
Ihre
Tra
iner
Mit Zertifi zierung zum „Certifi ed Professional for Software Architecture“ (iSAQB)
Mit Termin - garantie!
Präsentiert von: in Kooperation mit: Media-Partner: Veranstalter:
Neue Erweiterung für das große Git-Poster auf Seite 8!
Alles im Browser: Orion 3.0 > 45
Neuling: BPM mit Eclipse Stardust > 50
Alle Infos zum Release Train > 26
Embedded Development > 92
Die beliebtesten Miniaturcomputer
Open Source ALM > 101
JasForge und Eclipse Lyo SDK
Eclipse-4-Migration > 14, 19
Zwei Erfahrungs-berichte
News von den Java Development Tools > 36
ECLIPSE KEPLER
Alle Infos im Heft
>> 48, 51
eclipse m
ag
az
in 5
.20
13
101
ALMJasForge
www.eclipse-magazin.de eclipse magazin 5.13
von Karim Djaafar
JasForge [1] ist eine Kollaborations- und Agile-Platt-form zur Entwicklung und Integration von Agile-Tools in einem einzigen Dashboard. Das gemeinschaftlich vo-rangetriebene Projekt begann 2007 und wurde sukzessiv um verschiedene Komponenten erweitert: Subversion für Quellcodeverwaltung, Continuous Integration mit Hudson (später Jenkins), Sonar für die Verwaltung der Codequalität, JIRA für Fehlerverwaltung etc.
Für die Nutzerverwaltung verwendet JasForge eine Implementierung des LDAP-Registrys. Dabei werden drei Nutzerrollen unterstützt: Administratoren, Projekt-manager und Entwickler. Abbildung 1 zeigt die erhält-liche Version, die alle ALM-Suite-Tools darstellt und verwaltet.
Unter Verwendung des Ma-ven Archtype Wizards kann JasForge verschiedene Arten von Projekten erstellen, wie aus Abbildung 2 hervorgeht.
Es lassen sich viele verschie-dene Tools sowie Werkzeuge aus der Atlassian-Toolsuite verwalten (Abb. 3), so etwa das GreenHopper-Agile-Ma-nagement-Tool.
Von JasForge zur neuen JasForge-OSLC-Lyo-VersionBei JasForge verwenden wir die Lyo-OSLC-Implementie-rung. Hinter OSLC steht eine
offene Community, die Spezi!kationen für die Integra-tion von Werkzeugen erstellt. Diese Spezi!kationen er-möglichen es, Daten und Arbeitsabläufe entsprechender unabhängiger Software und Werkzeuge zur Verwaltung des Produktlebenszyklus zu integrieren, unterstützen also End-to-End-Lebenszyklusprozesse. Kurzum senkt die OSLC die Hürde für die Integration von Lifecycle-Tools.
Das Projekt Eclipse Lyo [2] begleitet die Aktivitäten der OSLC-Community, was die Spezi!kationen betrifft. Es stellt ein SDK zur Anwendung der OSLC-Spezi!ka-tionen zur Verfügung. Ziel ist es, die Verbreitung dieser Spezi!kationen voranzutreiben und der Eclipse-Commu-nity die Entwicklung von OSLC-konformen Tools zu er-leichtern. Außerdem stellt Lyo Entwicklern Beispielcode
Abb. 1: Alle verfügbaren ALM-Tools auf einen Blick
OSLC-Plug-in-Entwicklung mit JasForge und dem Eclipse Lyo SDK
Alles in einem Dashboard OSLC-(Open-Services-for-Lifecycle-Collaboration-)Spezi!kationen sollen die Integration von Life-cycle-Tools einfacher machen. Der folgende Beitrag beleuchtet JasForge, eine Open-Source-Agile-Plattform, die diesem Standard verp"ichtet ist. Gezeigt wird, wie man zu verschiedenen Stadien eines Projektlebenszyklus OSLC-konforme Werkzeuge integriert. Dazu werfen wir einen Blick auf die Geschichte und die ursprünglichen Ziele der JasForge-Community bis zur aktuellen Version, die das Eclipse Lyo SDK verwendet und mit OSLC-Standards somit vollständig kompatibel ist.
102
JasForgeALM
www.eclipse-magazin.deeclipse magazin 5.13
als Orientierungshilfe zur Verfügung. Bevor wir uns die JasForge-/OSLC-Suite ansehen, werfen wir erst einen Blick auf einige grundlegende Konzepte der OSLC.
OSLC: KernkonzepteServiceProvider: Die OSLC de!nieren das Konzept des ServiceProviders, der es Produkten ermöglicht, Con-tainer oder Partitionen für die Integration zugänglich zu machen. Der ServiceProvider ist das zentrale Ord-nungsprinzip der OSLC. Durch ihn können Werk-zeuge Ressourcen zur Verfügung stellen und Nutzer zu allen Ressourcen navigieren sowie neue erstellen. ServiceProvider liefern Antworten auf zwei einfache Fragen:
An welche URLs muss ich neue Ressourcen senden (POST)?Woher bekomme ich eine Liste bestehender Ressour-cen (GET)?
Weitere Eigenschaften des ServiceProviders:
Alle OSLC-Ressourcen be!nden sich in einem Service-Provider. Je nach Bedarf kann jede OSLC-Ressource eine Eigenschaft besitzen, die angibt, in welchem Ser-viceProvider sie sich be!ndet.
Clients können auf die Liste an bestehenden Ressourcen in einem ServiceProvider zugreifen. Die einzige in OSLC de!nierte Möglichkeit, neue OSLC-Ressour-cen zu erstellen, ist, sie in einem ServiceProvider zu erzeugen – ent-weder direkt durch einen HTTP-POST oder durch einen Dialog.Ein ServiceProvider ist selbst eine OSLC-Ressource mit einem HTTP- URL.
Zwei grundlegende Eigenschaften ei-nes ServiceProviders sind:
oslc:creation: der URL einer Res-source, an den man Repräsenta-tionen schicken kann, um neue Ressourcen zu erzeugen.oslc:queryBase: der URL einer Ressource, auf den man per GET zugreifen kann, um eine Liste an bestehenden Ressourcen im Ser-viceProvider zu erhalten. Der URL wird „queryBase URL“ genannt, und die Ressource, die von diesem URL identi!ziert wird, nennt sich queryBase.
Creation Factories: Um eine neue OSLC-Ressource zu erzeugen, muss
ein OSLC-Client per POST eine Repräsentation dieser Ressource an den Creation-URI der Creation Factory senden:
Ein HTTP-POST eines Inhalts an einen Creation-URI löst im Normalfall die Erstellung einer neuen Ressour-ce aus; konnte die Erstellung nicht erfolgen, erhält man über den entsprechenden HTTP-Statuscode eine Erklärung. Die Antwort auf einen erfolgreichen HTTP-POST an einen Creation-URI enthält normalerweise einen HTTP Location Header, der den URI der neu erzeug-ten Ressource enthält.
Query-Fähigkeiten: Ein OSLC-Service kann eine oder mehrere Query-Fähigkeiten bereitstellen, um Res-sourcen zu durchsuchen. Eine Query-Fähigkeit stellt einen Base-URI für Query-Resource-URIs zur Verfü-gung, optional auch Resource Shapes, die die Wer-te der Eigenschaften beschreiben, welche in den zu durchsuchenden Ressourcen zu erwarten sind. Durch Query-Fähigkeiten lassen sich also die Ressourcen aus!ndig machen, die von einem OSLC-Service ver-waltet werden.
RDF: REST und Linked Data sind die Hauptimple-mentierungen, auf die sich das Kernteam geeinigt hat.
Abb. 2: Projekterstellung
Abb 3: Toolverwaltung
103
ALMJasForge
www.eclipse-magazin.de eclipse magazin 5.13
OSLC de!nieren Ressour-cen durch URLs, die dann durch HTTP-Methoden verändert werden kön-nen. Ressourcen in OSLC bestehen oft aus Daten über gängige Konzepte in ALM-Software, z. B. Bugs (im OSLC-Vokabular: Change Requests).
OSLC-Daten werden durch das RDF (Resource Description Framework) repräsentiert, durch das Softwarehersteller auf einfache Art und Weise spezielle Erweiterungen zu den Daten hinzufügen können, die von ihrer OSLC-API-Implementierung be-reitgestellt werden. OSLC-Services müssen RDF/XML-Repräsentationen produzieren und konsumieren. OSLC de!niert nur begrenzt Daten, die über eine bestimmte Ressource zur Verfügung gestellt werden müssen.
JasForge OSLC: Überblick und ArchitekturJasForge OSLC ist eine Prototypversion. Sie integriert das Open-Source-Tool Bugzilla, mit dem sich Änderungen verfolgen lassen, mit der Codeverwaltung von Subversi-on. Die Nutzerverwaltung basiert auf OpenLDAP, so wie die JasForge-Community und -Produktversion [1]. Die JasForge-Architektur besteht aus vier Bausteinen:
JasForge Model: das Hauptmodul, das alle Kernenti-täten der Datenbank de!niert
Listing 1@Service("svnServiceProviderCatalog")public class SvnServiceProviderCatalog implements ISvnServiceProviderCatalog {
private static Class<?>[] RESOURCE_CLASSES = { ManageReposOslcBean.class }; public ServiceProvider createServiceProvider(String baseURI, String URIOslc) throws OslcCoreApplicationException, URISyntaxException { final ServiceProvider serviceProvider = ServiceProviderFactory. createServiceProvider( URIOslc, baseURI, "ManageSVN", "Service provider for jasforge tools : SVN " , null, RESOURCE_CLASSES, null);
return serviceProvider; }
public ServiceProviderCatalog getServiceProviderCatalog(String baseURI, String URIOslc) throws OslcCoreApplicationException, URISyntaxException{ ServiceProviderCatalog serviceProviderCatalog = new ServiceProviderCatalog(); ServiceProvider serviceProvider = createServiceProvider(baseURI, URIOslc) ;
serviceProviderCatalog.addServiceProvider(serviceProvider); serviceProviderCatalog.setTitle("Jasforge OSLC Service Provider Catalog for SVN"); serviceProviderCatalog.setDescription("Jasforge OSLC Service Provider Catalog contenant l'ensemble des services offerts pour SVN"); serviceProviderCatalog.setPublisher(new Publisher("JasmineConseil", "com.jasmineconseil.jasforge")); try { serviceProviderCatalog.getPublisher().setIcon(new URI("http://jasforge.com/resources/img/logo-jasforge.gif")); } catch (URISyntaxException e) { e.printStackTrace(); }
return serviceProviderCatalog; }}
Abb. 4: Die Architektur im Detail
Abb. 5: Die JasForge-Begrüßungsseite
104
JasForgeALM
www.eclipse-magazin.deeclipse magazin 5.13
JasForge Service: das Kernstück der Anwendung, es enthält: y DAO-Interfaces, die die Art des Zugangs zu den Da-ten bestimmen
y Den Maven-Service, der die von JasForge vorge-schlagenen Maven-Services zur Verfügung stellt
y LDAP-Service: ein Modul, das Nutzerrollen mithilfe der LDAP-Registry verwaltet
JasForge-Plug-in: enthält alle JasForge-Plug-ins, die die von JasForge unterstützten OSLC-kompatiblen Tools de!nieren; momentan unterstützen wir Sub-version, Bugzilla (s. o.) und Nexus als Repository-Verwaltungswerkzeug; weitere Tools wurden von der Open-Source-Community vorgeschlagen, die das Jas-Forge-Ökosystem bereichern sollen [1]; das JasForge-Plug-in besteht aus: y dem ServiceProviderCatalog, der alle durch das Tool zur Verfügung gestellten ServiceProvider aufführt
y dem ServiceProvider (s. o.) y den Services, die das Plug-in anbietet: Creation Fac-tory (zur Erstellung einer neuen Ressource mithilfe eines spezi!zierten URI), Query-Fähigkeit, Crea-tion-Dialog (Ressourcenerzeugung mi thilfe einer Dialogbox) und Auswahldialog zur Auswahl einer
Abb. 6: Plug-in-Verwaltung
Listing 3@OslcCreationFactory ( title = "Svn repository Creation Factory", label = "Svn repository Creation", resourceShapes = {OslcConstants.PATH_RESOURCE_SHAPES + "/" + ConstantsOslc.PATH_CHANGE_REQUEST}, resourceTypes = {ConstantsOslc.TYPE_CHANGE_REQUEST}, usages = {OslcConstants.OSLC_USAGE_DEFAULT} ) @POST @Path("/createReposSvn") @Consumes({OslcMediaType.APPLICATION_RDF_XML, OslcMediaType. APPLICATION_XML, OslcMediaType.APPLICATION_JSON}) @Produces({OslcMediaType.APPLICATION_RDF_XML, OslcMediaType.APPLICATION_XML, OslcMediaType.APPLICATION_JSON})// Create Subversion repository
public Response createRepos(RepositoryCM reposCM) throws URISyntaxException{
Response builder =null; User u = userService.findUserByUsername(reposCM.getCreatedBy()).get(0); String createur = u.getFirstname() + " " + u.getLastname(); log.debug("name repos" + reposCM.getTitle() + "createur" + createur);
if (validatePathrepo(reposCM.getPath(),reposCM.getIpMachine())) { log.debug("path" + reposCM.getPath()); log.debug("name repos" + reposCM.getTitle()); Repository reposInsert = new Repository(); Server server = new Server(); server.setIpMachine(reposCM.getIpMachine().trim()); }// to be completed return builder; }
Listing 2@GET@Path("/repo/{reposId}")@Produces({OslcMediaType.APPLICATION_RDF_XML, OslcMediaType.APPLICATION_XML, OslcMediaType.APPLICATION_JSON})public RepositoryCM myRepos(@PathParam("reposId") Integer reposId){
RepositoryCM repos = new RepositoryCM(); log.info("test myRepos"); try { Repository rep = repositoryService.findRepositoryById(reposId); repos = RepositoryCM.fromRepository(rep); } catch (IllegalParameterException e) { e.printStackTrace(); } catch (DataSourceException e) { e.printStackTrace(); } log.info("test fin myRepos"); return repos; }
105
ALMJasForge
www.eclipse-magazin.de eclipse magazin 5.13
Abb. 7: Subversion-Plug-in
Abb. 8: Bugzilla-Plug-in
Ressource. Weitere Informationen kön-nen [3] entnommen werden.
JasForge Web: de!niert das Web Part der An-wendung mithilfe des Spring Frameworks.
Abbildung 4 zeigt die Architektur der JasForge-OSLC-Toolsuite im Detail.
JasForge OSLC in AktionSehen wir uns das JasForge-OSLC-Tool genauer an. Abbildung 5 zeigt die Begrüßungsseite des Projekts.
JasForge OSLC stellt ein Modul zur Verwal-tung aller OSLC-kompatiblen Plug-ins bereit (in der Plug-in-Verwaltung, Abb. 6).
Abbildung 7 zeigt ein Subversion-kompatibles Plug-in, das die Liste verfügbarer Subversion-Repositories anzeigt.
In Abbildung 8 ist das Bugzilla-Plug-in zu sehen, das Bugs anzeigt und ab der JasForge-OSLC-Version 2.0.4 unterstützt wird. Dieses Plug-in besteht haupt-sächlich aus einem AJAX-Mashup-OSLC-CM-Consu-mer, den wir mit jQuery entwickelt haben.
Um unsere Tour durch die JasForge-OSLC-Lyo-Tool-suite abzuschließen, zeigen wir in Listing 1 einen Auszug aus dem Code, der den Einsatz des OSLC ServiceProvi-ders verdeutlicht.
Java-Methoden, die Subversion-Services entsprechen, wie z. B. Repository-Management, werden mit JAX-RS-Annotationen versehen. So verwenden wir in Listing 2 beispielsweise HTTP GET, um Subversion-Repositories zu verwalten (man beachte hier die Verwendung der GET REST-Methode, die RDF XML und JSON unter-stützt).
Nun verwenden wir die HTTP-POST-Methode, um Repositories herzustellen (Listing 3).
ZusammenfassungDiese Tour durch die JasForge-OSLC-Lösung konnte Ihnen hoffentlich einen ersten Einblick in diese neue und spannende Technologie vermitteln, die die OSLC zur Integration und Verwaltung von ALM-Tools bieten.
Eine Demo steht unter [4] bereit. Besuchen Sie unsere Seite und beteiligen Sie sich am Aufbau der JasForge-Plattform. Viel Spaß dabei!
Aus dem Englischen von der Redaktion des Eclipse Magazins.
Karim Djaafar ist CO von Jasmine CONSEIL, einem französischen Unternehmen und Eclipse-Solutions-Mitglied, das sich agiler Ent-wicklung und Java-EE-Expertise verschrieben hat. Er verfügt über einen breiten Erfahrungsschatz in den Themen Java-EE-Entwicklung und Agile Coaching, kann auf über zwanzig Jahre Erfahrung in
Enterprise-Anwendungsentwicklung, IT-Management zurückblicken und ist Autor zahlreicher Bücher zu Eclipse und JBoss.
Links & Literatur
[1] http://www.jasforge.com
[2] http://eclipse.org/lyo
[3] http://open-services.net/bin/view/Main/OslcCoreSpeci!cation
[4] http://jasforge.com/jasforge2-test/login.xhtml
w
Aktuelle Shortcuts:twitter.com/entwicklerpress
facebook.com/entwicklerpress
blog.entwickler-press.de
Stefan Zörner
LDAP für Java-EntwicklerEinstieg und Integration
240 Seiten, 2013
PRINT ISBN: 978-3-86802-094-6 Preis: 29,90 € / 30,80 € (A)
PDF ISBN: 978-3-86802-282-7 Preis: 17,99 €
EPUB ISBN: 978-3-86802-618-4 Preis: 17,99 €
Neu!
Beste Bücher für besten Code!
In vielen Unternehmen haben Verzeichnisse zur Speicherung und Bereitstellung von Informationen eine strategische Bedeutung. Vorherrschender Zugriffsmechanismus auf Verzeichnisdienste ist das Lightweight Directory Access Protocol (LDAP). In diesem Buch wird Java-Entwicklern auf kompakte und praxisnahe Weise das Rüstzeug vermittelt, um im Projektalltag Verzeichnisdienste in ihre Lösungen zu integrieren. Der Autor ist sowohl in der Java- als auch in der LDAP-Welt heimisch und bringt seine langjährigen Praxiserfahrungen zu beiden Technologien ein. Das erfolgreiche Buch liegt jetzt in der vierten Aufl age vor.
Die Referenz seit 2004!
www.entwickler-press.de/LDAP
Alle Printausgaben frei Haus erhalten Intellibook-ID kostenlos anfordern(www.intellibook.de)
Mit der Intellibook-ID kostenlos in der App anmelden und Zugriff auf alle Ausgaben des Eclipse Magazins erhalten (+ Bonusinhalte!)
ECLIPSE3
Jetzt 3 Top-Vorteile sichern!
1
Mit der Intellibook-ID kostenlos in der App 2
Zugriff auf das komplette PDF-Archiv mit der Intellibook-ID
3
ECLIPSEECLIPSEJetzt 3 Top-Vorteile sichern!
Jetzt abonnieren!
www.eclipsemagazin.de
Bjørn Stachmann, etracker GmbH
Feature Branches reviewen
Wenn man im Team mit Feature Branches arbeitet, möchte
man oft wissen, was auf den einzelnen Branches passiert ist.
*Fast-Forward Merges* erschweren das leider. Git erspart sich
dabei ein Merge Commit, wenn es genügt, den Branch-Zeiger
auf ein nachfolgendes Commit vorzurücken. Der Nachteil:
Man sieht nicht mehr, woher die Änderungen gekommen sind
oder ob überhaupt ein Merge stattgefunden hat. Ich empfehle
deshalb *Fast Forwards* abzuschalten:
JLW�FRQºJ���
JOREDO�PHUJH
�Ҭ�IDOVH
Die *First-Parent History*, bei der man immer nur den ers ten
Vorgänger eines Commits betrachtet, zeigt uns, welche Ände-
rungen per Commit direkt auf dem Branch getätigt und wel-
che per Merge von anderen Branches dazugeholt wurden:
JLW�ORJ���ºU
VW�SDUHQW�PD
VWHU��IHDWXU
H
Bei Reviews möchte man oft nur jene Änderungen betrachten,
die direkt auf diesen Feature Branches durchgeführt wurden.
Dann blendet man die Merges aus:
JLW�ORJ���ºU
VW�SDUHQW���
QR�PHUJHV��
�
PDVWHU��IHDW
XUH
Tobias Bayer, inovex
Tipp für Kommandozeilen-Aficionados
Ich habe diese beiden Aliasse in meiner config:
JUDSK� �ORJ�
��JUDSK�
�
��SUHWW\ IRU
PDW��&UHG�K
�&UHVHW�
���&�\H
OORZ��G�&UHV
HW��V��&JUHH
Q��FU��
� �&�EROG�EOXH
���DQ!�&UHVH
W���DEEUHY�
FRPPLW�
�
��GDWH UHODW
LYH
GDLO\� �ORJ�
��VLQFH���G
D\�DJR���RQ
HOLQH�
�
��DXWKRU�WRE
LDV�ED\HU#LQ
RYH[�GH
Der erste zeigt einen schönen Graphen auf der Kommando-
zeile und der zweite sagt mir, was ich im Daily zu erzählen
habe.
Tim Berglund, GitHub
Git Log
Das Command git log bringt eine einschüchternd große
Anzahl an Optionen mit sich. Viele Git-User reagieren auf diese
Komplexität, indem sie nur die einfachste Einsatzmöglichkeit
in Anspruch nehmen. Andere tauschen die Kommandozeile
gegen grafische Tools ein, sobald sie sich eine komplexe
Repository History anzeigen lassen wollen. Obwohl nichts
Verkehrtes daran ist, ein Git-GUI zu verwenden – mir gefallen
http://mac.github.com und http://windows.github.com
besonders gut –, sollten Git-User in der Lage sein, die History
von der Kommandozeile aus zu sehen, wenn ihnen das lieber
ist. Es gibt vier Kommandozeilen-Log-Schalter, die dies
ermöglichen:
JLW�ORJ���JU
DSK���RQHOLQ
H���GHFRUDWH
��DOO
--graph sorgt dafür, dass der Log den Repository-Graphen mit
ASCII-Art zeichnet, was besser funktioniert, als man vermuten
würde. --oneline bricht die Ausgabe jedes Commits auf eine
einzige Zeile mit verkürztem Commit Hash herunter. --decorate
versieht jeden Commit mit jedem verfügbaren Branch- oder
Tag-Namen. --all sorgt dafür, dass der Log die Commits aller
Branches anzeigt, nicht nur die des aktuellen.
Dieses Command ist natürlich etwas sperrig. Man sollte also
ggf. einen Alias erzeugen – siehe dazu folgenden Tipp von
Artur Speth.
Artur Speth, Microsoft
Aliasse
Aliasse sind nützlich, wenn man Befehle in Git abkürzen
möchte. Zum Beispiel bekommt man mit dem Befehl git diff
--cached die staged-Änderungen. Dafür kann ich mir einen
Alias einrichten.
Mit git config --global alias.staged 'diff --cached' habe ich nun
einen einfachen Zugriff auf den Befehl mittels git staged.
Christian Janz , BridgingIT
Änderungen mit „git stash“ parken
Wer kennt das nicht? Während der Entwicklung eines neuen
Features muss dringend ein Fehler gefixt werden. Was aber
passiert mit den gemachten Änderungen? Hier schafft git
stash Abhilfe: Damit wird der aktuelle Zustand von Arbeits-
verzeichnis und Index gesichert und das Arbeitsverzeichnis
auf den HEAD Commit zurückgesetzt. Von dort kann nun in
den Release Branch gewechselt werden, um dort den Fehler
zu beheben. Danach integriert git stash pop die anfangs
gemachten Änderungen für das neue Feature wieder in das
Arbeitsverzeichnis. Eclipse unterstützt dieses Feature auch
seit EGit 2.0.
Dominik Schadow, BridgingIT
Ein Git Repository in ein anderes kopieren
Mit wenigen Schritten lässt sich ein Git Repository inkl.
Historie und Autoren in ein bereits vorhandenes kopieren.
Der folgende Tipp zeigt dies mit dem master Branch eines
Repositorys:
Das Ziel-Repository normal klonen oder erstellen
git remote add -f [remote name] [repo url]
integriert das zweite Repository
git merge -s ours --no-commit [remote name]/master
führt Änderungen ohne Commit zusammen, wobei im
Konfliktfall das Ziel-Repository gewinnt
git read-tree --prefix=[local path] -u [remote name]/
master. integriert alle Commits in den angegebenen Pfad
git commit und git push
Änderungen übertragen
Michael Johann, Eco Novum GmbH
Statusanzeige im Prompt
Auf welchem Branch befinde ich mich, und welchen Status hat
er? Ist das Arbeitsverzeichnis des aktuellen Branches zwischen-
zeitlich verändert („dirty“) worden? Diese Frage taucht bei
einem Entwickler unter Nutzung eines Versionskontrollsystems
genauso häufig auf wie der Befehl „ls“ (list) in einer Shell, um
sich den Inhalt des Dateisystems anzeigen zu lassen. Die fol-
genden Zeilen, eingebunden in das Shell-Skript (z. B.: ~/.bash_
profile), halten uns immer bequem auf dem Laufenden:
IXQFWLRQ�JLW
BGHOHWHG�^
��>>���JLW�V
WDWXV��!��GH
Y�QXOO�_�JUH
S�
GHOHWHG����
����@@��HF
KR����
}IXQFWL
RQ�JLWBDGGHG
�^
��>>���JLW�V
WDWXV��!��GH
Y�QXOO�_�JUH
S�
��8QWUD
FNHG�ºOHV���
�� ����@@�
�HFKR�°�±
}IXQFWL
RQ�JLWBPRGLº
HG�^
��>>���JLW�V
WDWXV��!��GH
Y�QXOO�_�JUH
S�
�
PRGLºHG����
����@@��HF
KR�� �
}IXQFWL
RQ�JLWBGLUW\
�^
��HFKR����JL
WBDGGHG���JL
WBPRGLºHG���
JLWB
�
GHOHWHG��
}IXQFWL
RQ�JLWBEUDQF
K�^
��JLW�EUDQFK
���QR�FRORU�
�!��GHY�QXOO
�_�VHG��H
� ��A>A @�G�
�H��V� �?��
?��>?���JLWB
GLUW\�@��
}H[SRUW
�36� ?Z��JL
WBEUDQFK���
Im Wesentlichen zeigen die Funktionen drei Zustände an:
Wurden Dateien gelöscht? Dann wird ein Minuszeichen
ans Ende des Prompts angehängt.
Wurden Dateien verändert? In diesem Fall zeigt ein Stern-
symbol die Änderung an.
Wurden Dateien hinzugefügt? Der Status wird dann durch
ein Pluszeichen signalisiert.
Sollten Sie ein Linux betreiben, das deutschsprachige Ausgaben
erzeugt, sollten Sie die Zeichenketten bei den grep-Befehlen
entsprechend durch die zu erwartenden Worte ersetzen.
Martin Dilger, Freiberuflicher
Softwareconsultant und -trainer
Rebase
�JLW�UHEDVH�
�L�+($'a�$Q]
DKO�FRPPLWV!
�
Mit einem Interactive Rebase lässt sich wortwörtlich
Geschichte schreiben. Git ermöglicht es, bereits getätigte
Commits im Nachhinein (solange sie noch nicht gepusht sind)
zu bearbeiten, zusammenzufassen, zu vereinfachen und zu
veredeln. HEAD bezeichnet den zuletzt getätigten Commit
auf einem Branch.
~ <Anzahl Commits> beschreibt die Anzahl an Commits, die
vom obersten Commit aus bearbeitet werden sollen.
SLFN��������
�FRPPLW��
U���FҬH��FRP
PLW��
V����E�E��FR
PPLW��
I���JGE�V�FR
PPLW��
Die Standardauswahl ist pick oder p. Sie bewirkt, dass
Commit 1 unverändert bleibt.
Mit reword oder r lässt sich im Nachhinein die Commit
Message verändern.
Mit squash oder s wie bei Commit 3 würde er nach dem
Rebase mit Commit 2 verschmelzen. Seine Commit
Message bleibt erhalten.
Von mir persönlich mit Abstand am häufigsten
verwendet wird fixup oder f wie Commit 4. Dieser
Commit würde vollständig mit Commit 3 verschmelzen.
Git arbeitet von unten nach oben.
Interactive Rebase ist das Tool der Wahl, um Commits sauber
zu strukturieren.
Mario Konrad, bbv Software Services
Git Reset
Haben Sie in Ihrem Repository einen Commit, den Sie löschen
möchten, oder wollen Sie den HEAD auf einen bestimmten
Commit zurücksetzen, so können Sie mit Git die Geschichte
Ihres Repositorys nachträglich verändern.
Die letzten zwei Commits aus dem Repository unwider ruflich
löschen:
JLW�UHVHW���
KDUG�+($'a�
Auf die gleiche Weise ist es auch möglich, den HEAD auf einen
bestimmten Commit zu legen:
JLW�UHVHW���
KDUG�
��F��D�
��DG����IG��
DH��HD�IEE��
����H��HI�
Wurde beim letzten Commit etwas vergessen oder es hat sich
bei der Commit Message ein Fehler eingeschlichen, ist git-
reset sehr hilfreich:
JLW�UHVHW���
VRIW�+($'A
���
JLW�FRPPLW��
D��P��FRPPLW
�PHVVDJH�
Sie möchten den letzten pull oder merge rückgängig machen?
Kein Problem:
JLW�SXOO
���
JLW�UHVHW���
KDUG
Haben Sie eine Änderung bereits in ein remote Repository
gepusht, dann müssen Sie den Reset des HEADs mit force auf
das remote Repository pushen:
JLW�UHVHW���
KDUG�+($'A
JLW�SXVK���I
RUFH�RULJLQ�
PDVWHU
Bei Ihrer aktuellen Arbeit wollen Sie Änderungen eines Files
verwerfen, nicht jedoch die Arbeit an anderen Files beein-
trächtigen. Diese Aktion wird nicht mit git-reset durchgeführt,
sondern mit checkout:
JLW�FKHFNRXW
����ºOH�W[W
Achtung: Seien Sie vorsichtig mit git-reset, Sie können so
Ihr Repository permanent beschädigen.
René Preißel, eToSquare
Subtree-Befehl
Submodule bedeuten meist viele fehleranfällige Schritte.
Da kommt der subtree-Befehl wesentlich einfacher daher.
Auch mit ihm kann man ein externes Repository einbinden,
z. B. den Branch master des HTML5-Boilerplate-Projekts:
JLW�VXEWUHH�
DGG���SUHº[�
KWPO��ERLOHU
SODWH�?
������������
������VTXDVK
�KWWSV���JLW
KXE�FRP�
�
K�ES�KWPO��E
RLOHUSODWH�J
LW�PDVWHU
Im Gegensatz zu Submodulen werden dabei aber alle Dateien
in das aktuelle Repository importiert. Das weitere Arbeiten
bedarf keiner besonderen Schritte. Das Aktualisieren auf
einen neueren Stand ist ein einzelner Befehl:
JLW�VXEWUHH�
SXOO���SUHº[
�KWPO��ERLOH
USODWH�?
������������
�������VTXDV
K�KWWSV���JL
WKXE�FRP�
�
K�ES�KWPO��E
RLOHUSODWH�J
LW�PDVWHU
Änderungen im Unterprojekt können auch wieder in das
externe Repository zurückübertragen werden (split-Befehl).
Mein Tipp: Vermeiden Sie Submodule und nehmen Sie besser
den subtree-Befehl.
1) Lifecycle einer Git-Datei
untracked: noch nicht versioniert
unmodified: versioniert, aber noch nicht verändert
modified: verändert, aber noch nicht im Stage
staged: kann committet werden
2) Ein lokales Repository besteht aus:
Working Directory/Arbeitskopie: erste Station für ausgecheckte Dateien
Staging Area/Index: zweite Station, enthält die ausgecheckten und
bearbeiteten Dateien, die im nächsten Schritt zu einem Branch in einem
Repository hinzugefügt werden sollen
HEAD: verweist auf den letzten Commit im aktuellen Branch
3) Git Commands
Neues lokales Repository von bestehender Arbeitskopie anlegen
git init
Neues Repository ohne Arbeitskopie anlegen
JLW�LQLW���E
DUH
Repository klonen und Arbeitskopie auschecken
Arbeitskopie erstellen
JLW�FORQH��S
IDG���������
>]LHOSIDG@
Bei Verwendung eines entfernten Repositorys
�JLW�FORQH�>S
URWRFRO���@>
EHQXW]HUQDPH
#KRVW�@�SIDG
���������
>]LHOSIDG@
����(V�JHQ�JW
��KLHU�HLQHQ
�J�OWLJHQ�85
/�DQ]XJHEHQ�
�
���%HQXW]HUQ
DPH��=LHOISD
G�XQG�GDV�3U
RWRNROO�VLQG
�RSWLRQDO�
����0|JOLFKH�
:HUWH�I�U�GD
V�3URWRNROO�
�KWWS���KWWS
V���VVK�
���RGHU�JLW
Add & Commit
Änderungen der Staging Area/Index hinzufügen
JLW�DGG��GDW
HLQDPH!
JLW�DGG�
�JLW�DGG�����
�5HNXUVLY��Q
LPPW�DOOH�9H
U]HLFKQLVVH�
XQG
� � ������8QWHUY
HU]HLFKQLVVH
�PLW�LQ�GHQ�
,QGH[
Bestätigen der Änderungen in der Staging Area/Index
JLW�FRPPLW��
P��&RPPLW�1D
FKULFKW�
�JLW�FRPPLW��
DP��&RPPLW�1
DFKULFKW����
��D�I�JW�DOO
H�
���bQGHUXQJH
Q�DQ�'DWHLHQ
�KLQ]X��GLH�
EHUHLWV�JHWU
DFNW�
���ZHUGHQ��'
DPLW�VSDUW�P
DQ�VLFK�HLQ�
JLW�DGG��GDW
HLQDPH!
––> Änderung in HEAD
Änderungen in entferntes Repository hochladen
JLW�SXVK�RUL
JLQ�PDVWHU
master kann durch beliebigen anderen existierenden Branch im origin
ersetzt werden.
Lokales Repository ist nicht von entferntem geklont worden,
soll aber mit einem anderen Repository verbunden werden
JLW�UHPRWH�D
GG�RULJLQ��U
HSRVLWRU\�XU
O!
Branching Commands
Zu einem neuen Branch (feature_branch) wechseln
JLW�FKHFNRXW
�¬E�IHDWXUHB
EUDQFK
Zurück zum Master
JLW�FKHFNRXW
�PDVWHU
Neuen Branch löschen
JLW�EUDQFK�¬
G�IHDWXUHBEU
DQFK
Mergen und Aktualisieren
Neueste Änderungen in aktuellen Branch des lokalen Repositorys
übernehmen
JLW�SXOO�RUL
JLQ�PDVWHU
Branch mit einem anderen Branch zusammenführen
JLW�PHUJH��E
UDQFK!
Zusammenführen von Änderungen
JLW�DGG��GDW
HLQDPH!
Differenzen zwischen Branches anzeigen
JLW�GLҬ��TXH
OOEUDQFK!��]
LHOEUDQFK!
Änderungen der Staging Area/Index im Vergleich zum letzten
Commit anzeigen
JLW�GLҬ
Tagging
Neuen Tag erstellen (z. B. v0.1)
JLW�WDJ�Y���
�>�FRPPLW�,'
!@
Neuen kommentierten Tag erstellen (z. B. v0.1)
JLW�WDJ��D�Y
�����P�0HLQ
H�9HUVLRQ���
�
Liste der referenzierbaren Commit-IDs
JLW�ORJ
Änderungen rückgängig machen
Lokale Änderungen auf letzten Stand in HEAD zurücksetzen
JLW�FKHFNRXW
�����GDWHLQD
PH!
Änderungen komplett verwerfen
Zum Thema „Änderungen verwerfen“ finden Sie in der Sektion
10 Profitipps umfangreiche Tipps von Mario Konrad.
10 Profitipps
Commands
Sponsored by
Presented by:
master
Initial
Tag #0.1
Tag #1.0
#1.0 startet
Tag #1.1
Release
Hotfix
Feature
Zeit
Feature
development
Feature 1
für das aktuelle Release
für das nächste Release
Feature 3
Feature 2
Workflow
Der komplette Git-Workflow
1. Main Branches
Es gibt verschiedene Varianten, ein Git-Projekt zu beginnen.
Der folgende Beispielworkflow beginnt mit zwei Main
Branches:
Master Branch (master)
Development Branch (development)
Beide Main Branches sind von unbegrenzter Dauer.
Die initiale Produktversion startet auf dem Branch master und
wird im Branch development reflektiert. Im Branch master wird
der Sourcecode von HEAD stets im produktionsfertigen Status
angezeigt.
Im Branch development wird der Sourcecode von HEAD stets
mit den letzten Änderungen für das nächste Release angezeigt.
Gut zu wissen!
Eine andere, durchaus verbreitete Workflowvariante wäre,
dass konstant auf dem Master Branch gearbeitet wird. Die
hier gezeigte Variante trägt durch ihre Aufteilung aber zum
besseren Verständnis der einzelnen Workflowschritte bei.
2. Releases
Wenn der Sourcecode in development einen stabilen Status
erreicht hat und bereit ist, ausgeliefert zu werden, wird er
mittels eines Merge in den Branch master überführt und mit
einer Releasenummer ausgezeichnet.
IMMER wenn Änderungen in den Branch master gemergt
werden, haben wir per Definition ein neues Produktions-
release (dazu mehr in „Einen Release Branch erstellen“).
3. Supporting Branches
Supporting Branches erleichtern das parallele Arbeiten der
Teammitglieder. Man unterscheidet Feature Branch, Release
Branch und Hotfix Branch.
Feature Branch
Der Feature Branch dient dem Tracking der einzelnen
Features: Es gibt u. U. mehrere parallele Feature Branches (je-
weils einen Branch pro Feature). Ein Feature Branch existiert,
solange das Feature in der Entwicklungsphase ist. Dann wird
das Feature in den Branch development überführt (merge),
sodass es in das nächste Release ein gefügt werden kann. Das
Feature wird dann wiederum vom Branch development in den
Branch master gemergt.
Gut zu wissen!
Branch Naming Convention bei Feature Branches: Alles ist
erlaubt, außer master, development, release-* und hotfix-*.
Bei der Verwendung spezifischer Software, wie etwa JIRA,
erfolgt die Benennung der Branches üblicherweise nach
den Issue-IDs.
Release Branch (release-*)
Der Release Branch dient der Vorbereitung für das
Production-Release: Kurzfristige Überprüfungen des
Releasecodes werden auf einen Release Branch gelegt.
Hier können schnelle Bug Fixes (geringerer Form)
gemacht und Metadaten für das nächste Release vor-
bereitet werden. Somit bleibt der Branch development
frei, um weiterhin Features zu mergen. Der Release
Branch wird nach Abschluss eines Fixes/der Vorberei-
tung aufgelöst. Zuvor wird er sowohl in development
als auch in master gemergt.
Einen Release Branch erstellen
Der Release Branch zweigt vom Branch development
ab, sobald development kurz vor einem neuen Release
steht. Zu diesem Zeitpunkt müssen alle Features für das
nächste anstehende Release in den Branch development
gemergt werden.
Der Start eines Release Branch bedeutet automatisch
die Vergabe der Versionsnummer des bevorstehenden
Release (also z. B. #1.0, 2.0. ... ). Davor reflektierte der
Branch development zwar bereits die Änderungen des
kommenden Release, es ist aber bis dahin noch unklar,
ob es sich um eine Version #0.x oder #x.0 handeln wird
(vgl. dazu Punkt 2).
Checkliste
Bevor ein Release Branch in ein neues Release münden
kann:
Mergen Sie den Release Branch in den Branch master
(zur Erinnerung: Jeder Commit ist per Definition ein
neues Release!).
Vergeben Sie einen Tag (z. B.: 1.0) für den Commit als
zukünftige Referenz auf diese Version.
Mergen Sie den Release Branch auch in den Branch
development, damit künftige Releases ebenfalls die
im Release Branch getätigten Bug Fixes enthalten
können.
Entfernen Sie den Release Branch.
Vor dem finalen Rollout werden keine größeren neuen
Features mehr gemergt – sollte dennoch gerade das
nächste Feature in den releasefähigen Status übergehen,
wird es im Branch development gemergt und dort bis
zum nächsten großen Release vorgehalten.
Hot!x Branch (hotfixes-*)
Der Hotfix Branch hilft dabei, schnell
und live Produktionsprobleme zu fixen.
Er ist dem Release Branch ähnlich, wird
aber unvorhergesehen gebrancht. Denn
er entsteht aus der Notwendigkeit, sofort
zu handeln, wenn der Zustand der pro-
duktiv laufenden Version unerwünschte
Merkmale aufweist (z. B. critical bugs in
der Production-Version, die sofort gefixt
werden müssen). Der Hotfix Branch
zweigt vom Branch master, oder besser
gesagt, von dem Tag auf dem Branch
master, das die Produktions version
markiert.
Die schnellen Production Fixes werden
auf dem Hotfix Branch erledigt, damit
zur gleichen Zeit auf dem Branch deve-
lopment weitergearbeitet werden kann.
Der Hotfix Branch wird in master und
development überführt. Danach wird
der Hotfix Branch wieder gelöscht.
Ausnahme!
Wenn parallel auch noch ein Release Branch aktiv ist, wird der Hotfix
Branch in der Regel nur in diesen gemergt. Mit dem Release Branch wer-
den die Fixes dann in den Master gemergt. Werden die im Hotfix Branch
getätigten Production Fixes besonders akut benötigt, wird sowohl in den
Release Branch als auch in den Development Branch gemergt.master
development
masterRelease #x.0
Bug Fix
Release
development
master
#1.2 läuft live, macht
Probleme
Erstellung eines Hotfix
Branch zur Lösung des
Problems in #1.2
development ist unstable bis
Hotfix Branch überführt wird
Hotfix Branch wird nach
Problemlösung entfernt
#1.2.1 läuft ohne
Probleme
Hotfix
development
master
Tag #1.0
Tag #2.0
Start Release #2.0
Release
Feature
Feature 2
development
master
development
Release #0.1Release #0.2
Initial
master
development
Feature
Feature 1
Release #xy
masterRelease #1.0
Start des
Release #1.0
Initial
Release
development
Feature
Feature 1
Grafische Umsetzung: meat* – concept and design
Dieser Platz ist frei für spannende
Add-ons aus dem
Git-Universum.
Sie finden Poster-Add-ons
in den Magazinen der
Software & Support Media GmbH.
Git The Big
Picture
Git/Hg-Client für den
professionellen Einsatz
syntevo.com/smartgithg
1) Lifecycle einer Git-Datei
Lokales Repository ist nicht von entferntem geklont worden,
soll aber mit einem anderen Repository verbunden werden
JLW�UHPRWH�D
GG�RULJLQ��U
HSRVLWRU\�XU
O!
Branching Commands
Zu einem neuen Branch (feature_branch) wechselnCommands
Presented by:
Git The Big
PictureThe Big
PictureThe Big
Großes Git-Poster!
www.eclipsemagazin.de
![[DE] ECM Vision & Potentiale | Ulrich Kampffmeyer | ECM Forum | Zürich 24.06.2006 | conversion problems](https://img.pdfslide.org/doc/110x75/54b3996d4a795944738b47b8/de-ecm-vision-potentiale-ulrich-kampffmeyer-ecm-forum-zuerich-24062006-conversion-problems.jpg)
