Ecm 5 13_djaafar_jas_forge

Deutschland € 9,80
Österreich € 10,80, Schweiz sFr 19,205.13
www.eclipse-magazin.de
©iStockfoto.com/Kngkyle2
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 Einblicken
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 ZZZZZZeeeeeerrrtttiiifififi
zzziiieeerrruuunnngggzzzuuummm
MMMiiitttZZZeeerrrtttiiifififi
zzziiieeerrruuunnngggzzzuuummm
Certified
Certified
Certified
Professional
Professional
Professional
for Software
for Software
for Software
Architecture
Architecture
Architecture
iSAQB
IhreTrainer
Mit Zertifizierung zum
„Certified 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
eclipsemagazin5.2013

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-Version
Bei JasForge verwenden wir
die Lyo-OSLC-Implementie-
rung. Hinter OSLC steht eine
offene Community, die Spezifikationen für die Integra-
tion von Werkzeugen erstellt. Diese Spezifikationen 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 Spezifikationen betrifft.
Es stellt ein SDK zur Anwendung der OSLC-Spezifika-
tionen zur Verfügung. Ziel ist es, die Verbreitung dieser
Spezifikationen 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-)Spezifikationen sollen die Integration von Life-
cycle-Tools einfacher machen. Der folgende Beitrag beleuchtet JasForge, eine Open-Source-Agile-
Plattform, die diesem Standard verpflichtet 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: Kernkonzepte
ServiceProvider: Die OSLC definieren 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 befinden sich in einem Service-
Provider. Je nach Bedarf kann jede OSLC-Ressource
eine Eigenschaft besitzen, die angibt, in welchem Ser-
viceProvider sie sich befindet.
Clients können auf die Liste an
bestehenden Ressourcen in einem
ServiceProvider zugreifen.
Die einzige in OSLC definierte
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 identifiziert 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
ausfindig 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
OSLC definieren 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
definiert nur begrenzt Daten, die über eine bestimmte
Ressource zur Verfügung gestellt werden müssen.
JasForge OSLC: Überblick und Architektur
JasForge 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 definiert
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 {
ﬁnal 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:
DAO-Interfaces, die die Art des Zugangs zu den Da-
ten bestimmen
Den Maven-Service, der die von JasForge vorge-
schlagenen Maven-Services zur Verfügung stellt
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 definieren; 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:
dem ServiceProviderCatalog, der alle durch das Tool
zur Verfügung gestellten ServiceProvider aufführt
dem ServiceProvider (s. o.)
den Services, die das Plug-in anbietet: Creation Fac-
tory (zur Erstellung einer neuen Ressource mithilfe
eines spezifizierten 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) {
} catch (DataSourceException e) {
}
log.info("test fin myRepos");
return repos;
}

105
ALMJasForge
Abb. 7: Subversion-Plug-in
Abb. 8: Bugzilla-
Plug-in
Ressource. Weitere Informationen kön-
nen [3] entnommen werden.
JasForge Web: definiert das Web Part der An-
wendung mithilfe des Spring Frameworks.
Abbildung 4 zeigt die Architektur der JasForge-
OSLC-Toolsuite im Detail.
JasForge OSLC in Aktion
Sehen 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).
Zusammenfassung
Diese 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/OslcCoreSpecification
[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-Entwickler
Einstieg 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 Auflage 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!)
ECLIPSE
3
Jetzt 3 Top-Vorteile sichern!
1
Mit der Intellibook-ID kostenlos in der App2
Zugriff auf das
komplette PDF-Archiv
mit der Intellibook-ID
3
ECLIPSEECLIPSE
Jetzt 3 Top-Vorteile sichern!
Jetzt abonnieren!
www.eclipsemagazin.de
Bjørn
Stachm
ann, etracke
r GmbH
Featur
e Branch
es review
en
Wenn
man im Team mit Feature
Branche
s arbeitet
, möchte
man oft wissen,
was auf den einzelne
n Branche
s passiert
ist.
*Fast-Fo
rward
Merges*
erschwe
ren das leider.
Git erspart
sich
dabei
ein Merge
Commit
, wenn
es genügt,
den Branch-
Zeiger
auf ein nachfolg
endes
Commit
vorzurü
cken. Der Nachtei
l:
Man sieht nicht mehr,
woher
die Änderun
gen gekomm
en sind
oder ob überhau
pt ein Merge
stattgef
unden
hat. Ich empfeh
le
deshalb
*Fast Forward
s* abzusch
alten:
Die *First-Pa
rent History*
, bei der man immer
nur den ersten
Vorgäng
er eines Commit
s betrach
tet, zeigt uns, welche
Ände-
rungen
per Commit
direkt
auf dem Branch
getätigt
und wel-
che per Merge
von anderen
Branche
s dazugeh
olt wurden
:
Bei Reviews
möchte
man oft nur jene Änderun
gen betracht
en,
die direkt
auf diesen
Feature
Branche
s durchge
führt wurden.
Dann blendet
man die Merges
aus:
Tobias
Bayer,
inovex
Tipp für Komm
andoze
ilen-Af
icionad
os
Ich habe diese beiden
Aliasse
in meiner
config:
Der erste zeigt einen
schönen
Graphen
auf der Komma
ndo-
zeile und der zweite
sagt mir, was ich im Daily zu erzählen
habe.
Tim Berglu
nd, GitHub
Git Log
Das Comma
nd git log bringt
eine einschü
chternd
große
Anzahl
an Optione
n mit sich. Viele Git-User
reagiere
n auf diese
Komple
xität, indem
sie nur die einfachs
te Einsatzm
öglichke
it
in Anspruc
h nehmen
. Andere
tausche
n die Komma
ndozeile
gegen
grafisch
e Tools ein, sobald
sie sich eine komplex
e
Reposito
ry History
anzeige
n lassen
wollen.
Obwohl
nichts
Verkehr
tes daran
ist, ein Git-GUI
zu verwend
en – mir gefallen
http://m
ac.githu
b.com
und http://w
indows.
github.c
om
besonde
rs gut –, sollten
Git-User
in der Lage sein, die History
von der Komma
ndozeile
aus zu sehen,
wenn
ihnen
das lieber
ist. Es gibt vier Komma
ndozeile
n-Log-S
chalter,
die dies
ermögli
chen:
--graph
sorgt dafür,
dass der Log den Reposito
ry-Graph
en mit
ASCII-Ar
t zeichne
t, was besser
funktion
iert, als man vermute
n
würde.
--oneline
bricht
die Ausgabe
jedes Commit
s auf eine
einzige
Zeile mit verkürzt
em Commit
Hash herunte
r. --decora
te
versieht
jeden
Commit
mit jedem
verfügb
aren Branch-
oder
Tag-Nam
en. --all sorgt dafür,
dass der Log die Commit
s aller
Branche
s anzeigt,
nicht nur die des aktuelle
n.
Dieses
Comma
nd ist natürlich
etwas
sperrig.
Man sollte also
ggf. einen
Alias erzeuge
n – siehe dazu folgend
en Tipp von
Artur Speth.
Artur
Speth,
Microso
ft
Aliasse
Aliasse
sind nützlich
, wenn
man Befehle
in Git abkürze
n
möchte
. Zum Beispiel
bekomm
t man mit dem Befehl
git diff
--cached
die staged-Ä
nderung
en. Dafür
kann ich mir einen
Alias einricht
en.
Mit git config
--global
alias.sta
ged 'diff --cached
' habe ich nun
einen
einfache
n Zugriff
auf den Befehl
mittels
git staged.
Christi
an Janz , Bridgin
gIT
Änderu
ngen mit„git stash“
parken
Wer kennt
das nicht?
Währen
d der Entwick
lung eines neuen
Features
muss dringen
d ein Fehler
gefixt
werden
. Was aber
passiert
mit den gemach
ten Änderun
gen? Hier schafft
git
stash Abhilfe:
Damit
wird der aktuelle
Zustand
von Arbeits-
verzeich
nis und Index
gesiche
rt und das Arbeitsv
erzeichn
is
auf den HEAD
Commit
zurückg
esetzt.
Von dort kann nun in
den Release
Branch
gewech
selt werden
, um dort den Fehler
zu behebe
n. Danach
integrie
rt git stash pop die anfangs
gemach
ten Änderun
gen für das neue Feature
wieder
in das
Arbeitsv
erzeichn
is. Eclipse
unterstü
tzt dieses
Feature
auch
seit EGit 2.0.
Domin
ik Schado
w, Bridgin
gIT
Ein Git Reposi
tory in ein andere
s kopier
en
Mit wenigen
Schritte
n lässt sich ein Git Reposito
ry inkl.
Historie
und Autoren
in ein bereits
vorhand
enes kopieren
.
Der folgend
e Tipp zeigt dies mit dem master
Branch
eines
Reposito
rys:
Das Ziel-Rep
ository
normal
klonen
oder erstellen
git remote
add -f [remote
name]
[repo
url]
integrie
rt das zweite
Reposito
ry
git merge
-s ours --no-co
mmit
[remote
name]/m
aster
führt Änderun
gen ohne Commit
zusamm
en, wobei
im
Konflikt
fall das Ziel-Rep
ository
gewinnt
git read-tre
e --prefix
=[local
path]
-u [remote
name]/
master.
integrie
rt alle Commit
s in den angegeb
enen Pfad
git commit
und git push
Änderun
gen übertrag
en
Michae
l Johann
, Eco Novum
GmbH
Statusa
nzeige
im Promp
t
Auf welchem
Branch
befinde
ich mich, und welchen
Status
hat
er? Ist das Arbeitsv
erzeichn
is des aktuelle
n Branche
s zwische
n-
zeitlich
verände
rt („dirty“)
worden
? Diese Frage taucht
bei
einem
Entwick
ler unter Nutzung
eines Versions
kontroll
systems
genauso
häufig
auf wie der Befehl
„ls“ (list) in einer Shell, um
sich den Inhalt
des Dateisys
tems anzeige
n zu lassen.
Die fol-
genden
Zeilen,
eingebu
nden in das Shell-Sk
ript (z.B.: ~/.bash_
profile),
halten
uns immer
bequem
auf dem Laufend
en:
}
}
}
}
}
Im Wesentl
ichen zeigen
die Funktion
en drei Zuständ
e an:
Wurden
Dateien
gelösch
t? Dann wird ein Minusze
ichen
ans Ende des Prompts
angehän
gt.
Wurden
Dateien
verände
rt? In diesem
Fall zeigt ein Stern-
symbol
die Änderun
g an.
Wurden
Dateien
hinzuge
fügt? Der Status
wird dann durch
ein Pluszeic
hen signalisi
ert.
Sollten
Sie ein Linux betreibe
n, das deutsch
sprachig
e Ausgabe
n
erzeugt,
sollten
Sie die Zeichen
ketten
bei den grep-Bef
ehlen
entsprec
hend durch
die zu erwarten
denWorte
ersetzen
.
Martin
Dilger,
Freiberu
flicher
Softwar
econsu
ltant und -trainer
Rebase
Mit einem
Interact
ive Rebase
lässt sich wortwö
rtlich
Geschic
hte schreibe
n. Git ermögli
cht es, bereits
getätigt
e
Commit
s im Nachhin
ein (solange
sie noch nicht gepusht
sind)
zu bearbei
ten, zusamm
enzufas
sen, zu vereinfa
chen und zu
veredeln
. HEAD
bezeich
net den zuletzt
getätigt
en Commit
auf einem
Branch.
~ <Anzah
l Commit
s> beschre
ibt die Anzahl
an Commit
s, die
vom obersten
Commit
aus bearbei
tet werden
sollen.
Die Standar
dauswa
hl ist pick oder p. Sie bewirkt
, dass
Commit
1 unverän
dert bleibt.
Mit reword
oder r lässt sich im Nachhin
ein die Commit
Messag
e verände
rn.
Mit squash
oder s wie bei Commit
3 würde
er nach dem
Rebase
mit Commit
2 verschm
elzen.
Seine Commit
Messag
e bleibt
erhalten
.
Von mir persönl
ich mit Abstand
am häufigs
ten
verwen
det wird fixup oder f wie Commit
4. Dieser
Commit
würde
vollstän
dig mit Commit
3 verschm
elzen.
Git arbeitet
von unten
nach oben.
Interact
ive Rebase
ist das Tool der Wahl, um Commit
s sauber
zu struktur
ieren.
Mario
Konrad
, bbv Softwa
re Service
s
Git Reset
Haben
Sie in Ihrem
Reposito
ry einen
Commit
, den Sie löschen
möchte
n, oder wollen
Sie den HEAD
auf einen
bestimm
ten
Commit
zurückse
tzen, so können
Sie mit Git die Geschic
hte
Ihres Reposito
rys nachträg
lich verände
rn.
Die letzten
zwei Commit
s aus dem Reposito
ry unwider
ruflich
löschen
:
Auf die gleiche
Weise
ist es auch möglich
, den HEAD
auf einen
bestimm
ten Commit
zu legen:
Wurde
beim letzten
Commit
etwas
vergesse
n oder es hat sich
bei der Commit
Message
ein Fehler
eingesc
hlichen,
ist git-
reset sehr hilfreich
:
Sie möchte
n den letzten
pull oder merge
rückgän
gig machen
?
Kein Problem
:
Haben
Sie eine Änderun
g bereits
in ein remote
Reposito
ry
gepusht
, dann müssen
Sie den Reset des HEADs
mit force auf
das remote
Reposito
ry pushen:
Bei Ihrer aktuelle
n Arbeit
wollen
Sie Änderun
gen eines Files
verwerf
en, nicht jedoch
die Arbeit
an anderen
Files beein-
trächtig
en. Diese
Aktion
wird nicht mit git-reset
durchge
führt,
sondern
mit checkou
t:
Achtung
: Seien Sie vorsicht
ig mit git-reset
, Sie können
so
Ihr Reposito
ry perman
ent beschäd
igen.
René Preiße
l, eToSqu
are
Subtre
e-Befe
hl
Submod
ule bedeute
n meist viele fehleran
fällige
Schritte
.
Da kommt
der subtree-
Befehl
wesentl
ich einfache
r daher.
Auch mit ihm kann man ein externe
s Reposito
ry einbind
en,
z.B. den Branch
master
des HTML5-
Boilerpl
ate-Proj
ekts:
Im Gegensa
tz zu Submod
ulen werden
dabei
aber alle Dateien
in das aktuelle
Reposito
ry importie
rt. Das weitere
Arbeiten
bedarf
keiner
besonde
ren Schritte
. Das Aktualis
ieren auf
einen
neueren
Stand
ist ein einzelne
r Befehl:
Änderun
gen im Unterpr
ojekt können
auch wieder
in das
externe
Reposito
ry zurückü
bertrage
n werden
(split-Be
fehl).
Mein Tipp: Vermeid
en Sie Submod
ule und nehmen
Sie besser
den subtree-
Befehl.
1) Lifecy
cle einer Git-Datei
untrack
ed: noch nicht versioni
ert
unmod
ified: versioni
ert, aber noch nicht verände
rt
modifie
d: verände
rt, aber noch nicht im Stage
staged:
kann commit
tet werden
2) Ein lokales Repository
besteht aus:
Working
Directo
ry/Arbe
itskopie
: erste Station
für ausgech
eckte Dateien
Staging
Area/In
dex: zweite
Station,
enthält
die ausgech
eckten
und
bearbei
teten Dateien
, die im nächste
n Schritt
zu einem
Branch
in einem
Reposito
ry hinzuge
fügt werden
sollen
HEAD:
verweis
t auf den letzten
Commit
im aktuelle
n Branch
3) Git Comm
ands
Neues
lokales
Reposit
ory von bestehe
nder Arbeits
kopie
anlegen
git init
Neues
Reposit
ory ohne Arbeits
kopie
anlegen
Repos
itory klonen
und Arbeit
skopie
ausche
cken
Arbeits
kopie
erstelle
n
Bei Verwen
dung eines entfern
ten Reposit
orys
Add & Comm
it
Änderu
ngen der Staging
Area/In
dex hinzufü
gen
Bestätig
en der Änderu
ngen in der Staging
Area/In
dex
––> Änderun
g in HEAD
Änderu
ngen in entfern
tes Reposit
ory hochlad
en
master
kann durch
beliebig
en anderen
existiere
nden Branch
im origin
ersetzt
werden.
Lokales
Reposit
ory ist nicht von entfern
tem geklont
worden
,
soll aber mit einem
anderen
Reposit
ory verbun
den werden
Branch
ing Comm
ands
Zu einem
neuen
Branch
(feature
_branch
) wechse
ln
Zurück
zum Master
Neuen
Branch
löschen
Merge
n und Aktual
isieren
Neueste
Änderu
ngen in aktuelle
n Branch
des lokalen
Reposit
orys
überne
hmen
Branch
mit einem
anderen
Branch
zusamm
enführe
n
Zusamm
enführe
n von Änderu
ngen
Differen
zen zwische
n Branche
s anzeige
n
Änderu
ngen der Staging
Area/In
dex im Vergleic
h zum letzten
Commi
t anzeige
n
Taggin
g
Neuen
Tag erstelle
n (z. B. v0.1)
Neuen
komme
ntierten
Tag erstelle
n (z. B. v0.1)
Liste der referen
zierbare
n Commi
t-IDs
Änderu
ngen rückgä
ngig mache
n
Lokale
Änderu
ngen auf letzten
Stand
in HEAD
zurücks
etzen
Änderu
ngen komple
tt verwerf
en
Zum Thema
„Änderu
ngen verwerf
en“ finden
Sie in der Sektion
10 Profitipp
s umfang
reiche
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
developm
ent
Feature
1
für das aktuelle
Release
für das nächste
Release
Feature
3
Feature
2
Workflow
Der komplette Git-Workflow
1. Main Branc
hes
Es gibt verschie
dene Variante
n, ein Git-Proje
kt zu beginne
n.
Der folgend
e Beispiel
workflow
beginnt
mit zwei Main
Branche
s:
Master
Branch
(master
)
Develop
ment Branch
(develop
ment)
Beide
Main Branche
s sind von unbegre
nzter Dauer.
Die initiale
Produkt
version
startet
auf dem Branch
master
und
wird im Branch
developm
ent reflektie
rt. Im Branch
master
wird
der Sourcec
ode von HEAD
stets im produkt
ionsfert
igen Status
angezei
gt.
Im Branch
developm
ent wird der Sourcec
ode von HEAD
stets
mit den letzten
Änderun
gen für das nächste
Release
angezei
gt.
Gut zu wissen!
Eine andere,
durchau
s verbreit
ete Workflo
wvarian
te wäre,
dass konstan
t auf dem Master
Branch
gearbei
tet wird. Die
hier gezeigte
Variante
trägt durch
ihre Aufteilu
ng aber zum
bessere
n Verständ
nis der einzelne
n Workflo
wschritt
e bei.
2. Releas
es
Wenn
der Sourcec
ode in developm
ent einen
stabilen
Status
erreicht
hat und bereit
ist, ausgelie
fert zu werden,
wird er
mittels
eines Merge
in den Branch
master
überfüh
rt und mit
einer Releasen
ummer
ausgeze
ichnet.
IMMER
wenn
Änderun
gen in den Branch
master
gemerg
t
werden,
haben
wir per Definitio
n ein neues
Produkt
ions-
release
(dazu
mehr in„Einen
Release
Branch
erstellen
“).
3. Suppo
rting Branc
hes
Support
ing Branche
s erleichte
rn das parallele
Arbeiten
der
Teammi
tglieder
. Man untersch
eidet Feature
Branch,
Release
Branch
und Hotfix
Branch.
Featur
e Branc
h
Der Feature
Branch
dient dem Tracking
der einzelne
n
Features
: Es gibt u.U. mehrere
parallele
Feature
Branche
s (je-
weils einen
Branch
pro Feature)
. Ein Feature
Branch
existiert
,
solange
das Feature
in der Entwick
lungsph
ase ist. Dann wird
das Feature
in den Branch
developm
ent überfüh
rt (merge)
,
sodass
es in das nächste
Release
eingefügt
werden
kann. Das
Feature
wird dann wiederu
m vom Branch
developm
ent in den
Branch
master
gemerg
t.
Gut zu wissen!
Branch
Naming
Conven
tion bei Feature
Branche
s: Alles ist
erlaubt,
außer
master,
developm
ent, release-*
und hotfix-*.
Bei der Verwend
ung spezifisc
her Softwar
e, wie etwa JIRA,
erfolgt
die Benenn
ung der Branche
s üblicher
weise
nach
den Issue-ID
s.
Releas
e Branc
h (releas
e-*)
Der Release
Branch
dient der Vorbere
itung
für das
Product
ion-Rele
ase: Kurzfris
tige Überprü
fungen
des
Release
codes
werden
auf einen
Release
Branch
gelegt.
Hier können
schnelle
Bug Fixes (geringe
rer Form)
gemach
t und Metada
ten für das nächste
Release
vor-
bereitet
werden
. Somit
bleibt
der Branch
develop
ment
frei, um weiterh
in Feature
s zu mergen
. Der Release
Branch
wird nach Abschlu
ss eines Fixes/de
r Vorbere
i-
tung aufgelö
st. Zuvor
wird er sowohl
in develop
ment
als auch in master
gemerg
t.
Einen
Releas
e Branc
h erstell
en
Der Release
Branch
zweigt
vom Branch
developm
ent
ab, sobald
developm
ent kurz vor einem
neuen
Release
steht.
Zu diesem
Zeitpun
kt müssen
alle Features
für das
nächste
anstehe
nde Release
in den Branch
developm
ent
gemerg
t werden.
Der Start eines Release
Branch
bedeute
t automa
tisch
die Vergabe
der Versions
numme
r des bevorste
henden
Release
(also z. B. #1.0, 2.0. ... ). Davor
reflektie
rte der
Branch
developm
ent zwar bereits
die Änderun
gen des
komme
nden 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)
.
Checkli
ste
Bevor
ein Release
Branch
in ein neues
Release
münden
kann:
Mergen
Sie den Release
Branch
in den Branch
master
(zur Erinneru
ng: Jeder Commit
ist per Definitio
n ein
neues
Release!
).
Vergebe
n Sie einen
Tag (z.B.: 1.0) für den Commit
als
zukünft
ige Referen
z auf diese Version.
Mergen
Sie den Release
Branch
auch in den Branch
developm
ent, damit
künftige
Releases
ebenfall
s die
im Release
Branch
getätigt
en Bug Fixes enthalte
n
können
.
Entferne
n Sie den Release
Branch.
Vor dem finalen
Rollout
werden
keine größere
n neuen
Features
mehr gemerg
t – sollte dennoch
gerade
das
nächste
Feature
in den releasef
ähigen
Status
übergeh
en,
wird es im Branch
developm
ent gemerg
t und dort bis
zum nächste
n großen
Release
vorgeha
lten.
Hotfix
Branc
h (hotfix
es-*)
Der Hotfix
Branch
hilft dabei,
schnell
und live Produkt
ionsprob
leme zu fixen.
Er ist dem Release
Branch
ähnlich,
wird
aber unvorhe
rgesehe
n gebranc
ht. Denn
er entsteht
aus der Notwen
digkeit,
sofort
zu handeln
, wenn
der Zustand
der pro-
duktiv
laufende
n Version
unerwü
nschte
Merkma
le aufweis
t (z.B. critical
bugs in
der Product
ion-Vers
ion, 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 Produkt
ionsversion
markier
t.
Die schnelle
n Product
ion Fixes werden
auf dem Hotfix
Branch
erledigt
, damit
zur gleichen
Zeit auf dem Branch
deve-
lopment
weiterge
arbeitet
werden
kann.
Der Hotfix
Branch
wird in master
und
developm
ent überfüh
rt. Danach
wird
der Hotfix
Branch
wieder
gelösch
t.
Ausnah
me!
Wenn
parallel
auch noch ein Release
Branch
aktiv ist, wird der Hotfix
Branch
in der Regel
nur in diesen
gemerg
t. Mit dem Release
Branch
wer-
den die Fixes dann in den Master
gemerg
t. Werden
die im Hotfix
Branch
getätigt
en Product
ion Fixes besonde
rs akut benötig
t, wird sowohl
in den
Release
Branch
als auch in den Develop
ment Branch
gemerg
t.
master
developm
ent
master
Release
#x.0
Bug
Fix
Release
develop
ment
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ösun
g entfernt
#1.2.1 läuft ohne
Probleme
Hotfix
developm
ent
master
Tag #1.0
Tag #2.0
Start Release
#2.0
Release
Feature
Feature
2
developm
ent
master
developm
ent
Release
#0.1
Release
#0.2
Initial
master
developm
ent
Feature
Feature
1
Release
#xy
master
Release
#1.0
Start des
Release
#1.0
Initial
Release
developm
ent
Feature
Feature
1
Grafisch
e Umsetzu
ng: meat*
– concept
and design
Dieser
Platz ist frei für spanne
nde
Add-ons aus dem
Git-Universum.
Sie finden
Poster-
Add-on
s
in den Magazi
nen der
Softwa
re&Suppor
t Media
GmbH.
GitThe Big
Picture
Git/Hg-Client
für den
professionelle
n Einsatz
syntevo.com
/smartgithg
1) Lifecy
cle einer Git-Datei
Lokales
Reposit
ory ist nicht von entfern
tem geklont
worden
,
soll aber mit einem
anderen
Reposit
ory verbun
den werden
Branch
ing Comm
ands
Zu einem
neuen
Branch
(feature
_branch
) wechse
ln
Commands
Presented by:
GitThe Big
Picture
The Big
Picture
The Big
Großes Git-Poster!
www.eclipsemagazin.de

Ecm 5 13_djaafar_jas_forge

Weitere ähnliche Inhalte

Was ist angesagt? (8)

Andere mochten auch (20)

Ähnlich wie Ecm 5 13_djaafar_jas_forge (20)

Mehr von Jasmine Conseil (15)

Ecm 5 13_djaafar_jas_forge