Allgemeines git allgemein Seite 1 von 8 servoy:version_control [Jo

servoy:version_control [Jo's DevDokuWiki]
Seite 1 von 8
Allgemeines
s.a.: Team Development mit SVN, von: Sean Devlin, Servoy USA
git allgemein
Allgemeine Infos
Git Tutorial zu GitFlow und SourceTree (von Gary Dotzlaw, www.dotzlaw.com [http://www.dotzlaw.com])
Grundsätzlich habe ich normalerweise ein aktuelles Git installiert, das mir den komfortablen Zugriff auf die
Kommandozeilen-Version (Git-Bash) ermöglicht. Hierfür bevorzuge ich das Paket Git Extensions
Zusätzlich setze ich SourceTree (Freeware von Atlassian) ein, das m e in momentanes Lieblings-GUI für den Zugriff
auf Git-Repositories ist. Ich installiere es mit dem angebotenen „Embedded“-Git.
Git Installation
Help - Install New Software - Suchbegriff „GIT“
Work with: Kepler oder Indigo –> collaboration – >git team provider
Window - Open Perspective - other - GIT Repository
Achtung: wenn dabei der folgende Hinweis kommt: „ The Environm ent variable HOME is not set . The following
Direct ory will be used for st oring t he Git user configurat ion…“
dann nich t die Umgebungsvariable HOME setzten, da danach u.U. Java nicht mehr gefunden wird…
(s.a.: servoycamp2014#servoy_developer)
Ein Git Repository anlegen
Zunächst muss eine Git-Datenbank angelegt werden, das „Repository“.
Beim Anlegen des Repositories sollte man sich Gedanken machen, ob alle Artefakte eines Workspaces oder nur die
einer Solution ge m e insa m versioniert werden sollen.
Das Git Repository wird grundsätzlich auf der obersten Verzeichnisebene angelegt, in der sich die zu versionierenden
Dateien befinden. Git bietet dann alle Dateien ab dieser Ebene als zu eben diesem Repository gehörend an. Ich lege
es dementsprechend entweder im Verzeichnis <Workspace> oder in <Workspace>\<Solution> an. Bei der
Entscheidung, ist u.a. zu beachten, dass die DBI-Files, die die Datenbank beschreiben, unter
< Workspace>\resources\datasources\<ServerName>\… gespeichert sind, womit sich in den meisten Fällen wohl
eher ein Repository pro Workspace anbieten wird.
Daraus ergibt sich dann im „Solution“-Fall die folgende Verzeichnisstruktur:
c:\workspace
├──.metadata
├──resources
│ ├──.Settings
│ ├──datasources
│ │ └──server1
│ └──styles
├──solution
│ ├──.git
│ ├──module1
│ ├──module2
│ └──module3
│
├──forms
│
├──relations
│
└──valuelists
├──solution2
...
Bei der Version „Workspace“ befindet sich das Repository entsprechend ein Verzeichnis höher:
c:\workspace
├──.git
├──.metadata
├──resources
│ ├──.settings
│ ├──datasources
│ │ └──server1
│ └──styles
├──solution
│ ├──module1
...
http://localhost:8800/servoy/version_control
13.04.2014
servoy:version_control [Jo's DevDokuWiki]
Seite 2 von 8
Übrigens: mit Hilfe des Eclipse Git Plugins habe ich es nicht geschafft, ein Repository an der entsprechenden Stelle
in e ine r v or ha nde ne n Ve r ze ich nisst r uk t u r anzulegen. Der Assistent wollte partout ein leeres Verzeichnis als Ziel
haben und das war dann jedes mal eine Ebene zu tief:
c:\workspace
├──leeresVerzeicnis
│ └──.git
<<<<---├──.metadata
├──solution
│ ├──module1
...
Deshalb besser anlegen per Git Kommandozeile
git init C:\Servoy\<workspace>\<solution>
oder mit einem der frei verfügbaren GUIs (dem Git-Internen, Git Extensions, SourceTree, …)
oder mit dem Explorer-Kontextmenü (falls etwas Entsprechendes mit installiert wurde)
Anschliessend kann man dann das Repository über das Eclipse Git Plug-In per „add existing“ hinzufügen:
Ein Repository löschen
Im Normalfall wird dazu einfach nur das Verzeichnis .git gelöscht.
W a r nu ng: wenn der entsprechende Dialog in Sour ce Tr e e benutzt wird, dann wird nicht nur das Repository, also
das .git-Verzeichnis gelöscht, sondern es werden auch alle darin referenzierten (Source-) Dateien mit gelöscht. Also
sollte man ggf. zuerst das .git-Verzeichnis manuell löschen und dann erst den Eintrag in SourceTree…
.gitignore
Über diese Datei wird gesteuert, welche Dateien nich t in die Versionierung übernommen werden sollen. Gute
Kandidaten hierfür sind sicherlich in .metadata zu finden, wo anscheinend Einstellungen der Entwicklungsumgebung
abgelegt werden
Sinnvollerweise legt man diese Datei an, be vor zum ersten Mal Dateien in das Repository eingecheckt („commit“)
werden.
.gitignore gehört in das Verzeichnis, in dem sich das Unterverzeichnis .git befindet.
<Workspace>
├──.git
├──.metadata
│ └──.plugins
│
├──com.servoy.eclipse.ui
│
├──net.sourceforge.sqlexplorer
│
├──org.eclipse.core.resources
...
.gitignore
...
http://localhost:8800/servoy/version_control
13.04.2014
servoy:version_control [Jo's DevDokuWiki]
Seite 3 von 8
was ist der Unterschied zu .gitignore_global und wo ist diese Datei normalerweise?
So könnte eine erste Version einer solchen Datei aussehen:
.gitignore
# based on a tutorial by Gary Dotzlaw, www.dotzlaw.com
# Compiled source #
###################
*.com
*.class
*.dll
*.exe
*.o
*.so
*.gitignore_global
# Servoy metadata #
###################
*/.metadata/
.metadata/
*metadata/
*\.metadata\
.metadata\
*metadata\
# Logs and databases #
######################
*.log
# OS generated #
######################
.DS_Store
.DS_Store?
._*
.Thumbs.db
git Konfiguration
Die be n ut ze r spe zifisch e n / globalen Einstellungen befinden sich im Verzeichnis %userprofile% ( c:\users\%
username% ). Alle dort zu findenden Dateien, deren Namen nur aus einer Extension bestehen, sind einen näheren
Blick wert:
z.B.:
.bash_history
.gitconfig
.gitk
.kdiff3rc
.gitconfig
[core]
autocrlf = true
editor = C:/Util/Notepad++/notepad++.exe
[user]
name = Joachim Hilgers
email = [email protected]
[merge]
tool = kdiff3
[mergetool "kdiff3"]
path = C:/Program Files (x86)/KDiff3/kdiff3.exe
[diff]
guitool = kdiff3
[difftool "kdiff3"]
path = C:/Program Files (x86)/KDiff3/kdiff3.exe
Insbesondere das frühe Einstellen von core.editor ist sehr sinnvoll, zumindest wenn man wenigstens ab und zu per
Kommandozeile arbeiten möchte und sich nicht besonders mit dem Git Standard-Editor Vi auskennt
Per Git Bash kann dies jederzeit mit dem folgenden Kommando eingestellt werden:
git config --global core.editor C:/Util/Notepad++/notepad++.exe
analog dazu
git config --global user.name Joachim Hilgers
git config --global user.email [email protected]
usw. Eine Liste der momentanen Einstellungen liefert
git config --global -l
Die ausführliche Hilfe zu den Einstellungen liefert
http://localhost:8800/servoy/version_control
13.04.2014
servoy:version_control [Jo's DevDokuWiki]
Seite 4 von 8
git config --help
Tip: wem das zu umständlich ist, der findet z.B. in den „Git Extensions“ hinreichend viele Dialoge für Einstellungen
Git + Servoy Developer
Einstellungen in Eclipse
In der Git Perspective ist es wichtig, die Navigat or View verfügbar zu haben. Denn nach jedem Wechsel des Branchs
(Checkout) sollte man hier alle Module markieren und per Rechtscklick „refresh“en. Sonst kann es zu Fehlern in der
Entwicklungsumgebung kommen, da diese zumindest teilweise nicht die im Hintergrund geänderten Sourcen
mitbekommt.
Dateien in's Repository
Zuerst müssen Dateien dem Index (=dem Inhaltsverzeichnis) hinzugefügt werden - sprich: „add to index“
http://localhost:8800/servoy/version_control
13.04.2014
servoy:version_control [Jo's DevDokuWiki]
Seite 5 von 8
Sie befinden sich dann im „Staging“-Bereich, wo sie darauf warten, in das Repository übertragen zu werden:
Das Übertragen aus dem Staging-Bereich in das Repository erfolgt dann per „commit“:
http://localhost:8800/servoy/version_control
13.04.2014
servoy:version_control [Jo's DevDokuWiki]
Seite 6 von 8
Gits großes "Ding": BRANCHING
Einer der größten Unterschiede - oder besser Vorteile - von Git gegenüber anderen Versionskontrollsystemen ist der
Umstand, dass Gits Branching-/Merging-Implementierung schon beim Entwurf eines der beiden obersten Designziele
war. Entsprechend gut wird es von Git unterstützt. Allerdings ist es für jemanden, der nicht täglich mergen/branchen
muss, zumindest mit den nativen Werkzeugen eher etwas „un-intuitiv“.
Hier hilft das im Folgenden vorgestellte SourceTree…
Branching Strategie
Den eigenen Quellcode in Branches zu verwalten darf grundsätzlich kein Selbstzweck sein, sondern sollte eine
sinnvolle Ergänzung/Unterstützung des eigenen Entwicklungspr oze sse s (so weit vorhanden ) sein. Branching
sollte dabei unterstützen, die verschiedenen Dimensionen der Versionen (zeitlich linear, zwischendurch-Hotfixes, pro
Kunde, unfertig j/n, ein Versuch/„Spike“) j/n, getestet j/n, zum Testen freigegeben j/n …) seines Quellcodes besser
im Griff zu behalten. Wird in dieser Richtung keine Verbesserung benötigt, z.B. bei klassischer linearer Versionierung
(=kein Kunde bekommt ein Zwischen-Release), dann ist der Zusatz-Aufwand für Branching wahrscheinlich nicht
notwendig. In allen anderen Fällen kann Branching zumindest die Übersichtlichkeit in der Art „wo ist der Code“
verbessern und damit die Fehlerwahrscheinlichkeit von „Der Fix hätte eigentlich drin sein müssen“ zu verringern.
Letztendlich geht es dabei also um Produktivitätsverbesserung Qualitätssicherung.
Folgend der Vorschlag von Gary Dotzlaw für eine sinnvolle Organisation der Branches. Er lehnt sich dabei an die recht
sinnvollen Standardvorgaben von Sou r ce Tr e e an, das besonders beim Brachnen/Mergen unterstützt.
Der Commit-Prozess
Das noch leere Repository
http://localhost:8800/servoy/version_control
13.04.2014
servoy:version_control [Jo's DevDokuWiki]
Seite 7 von 8
Erstes Staging
Erstes Commit
http://localhost:8800/servoy/version_control
13.04.2014
servoy:version_control [Jo's DevDokuWiki]
Seite 8 von 8
Zweites Commit
Workflow (Branching) mit SourceTree
Arbeiten im Team
vielleicht demnächst mal
servoy/version_control.txt · Zuletzt geändert: 2014/04/10 20:42 von 127.0.0.1
http://localhost:8800/servoy/version_control
13.04.2014