20 Aug
2017
20 Aug
'17
5:21 p.m.
Am Sonntag, 20. August 2017 16:57 CEST, Marek Kralewski <mck(a)tuxwerk.de> schrieb:
Das Leben für den Programmierer (weiblich oder
männlich :-) ist mit git
(oder auch mercurial...) wesentlich einfacher. Lokale branches zu
erstellen, ohne auf den Server zu pushen, ist ein Klacks, das mergen
oder rebasen wesentlich einfacher. Wenn der Programmierer schlau ist,
hat er sowieso schon git-svn im Einsatz, arbeitet also lokal mit git und
pusht dann nur gegen SVN.
Ich denke das es ist wichtig zu Verstehen das git und das Arbeiten damit
in Layern konzipiert ist. D.h. es ist ein Werkzeug dass einem viel Freiheiten
lässt wie/wofür man es nutzt. Ganz im Gegensatz zu CVS und Subversion.
Es ist daher bei der Nutzung von Git im Team wichtig sich ein wenig Gedanken
darüber zu machen wie/mit welchem Workflow man Git einsetzt. Ich persönlich
nutze inzwuschen gerne git-flow, das ist ein Satz von weiteren Command mit denen
man den Workflow managed.
Einmal:
$ git flow
Und dann z.Bsp. (ein neues Feature wird gewünscht):
$ git flow feature start mit-bluntschinator
Switched to a new branch 'feature/mit-bluntschinator'
Summary of actions:
- A new branch 'feature/mit-bluntschinator' was created, based on
'develop'
- You are now on branch 'feature/mit-bluntschinator'
Now, start committing on your feature. When done, use:
git flow feature finish mit-bluntschinator
und später dann:
$ git flow feature finish mit-bluntschinator
Switched to branch 'develop'
Already up-to-date.
Deleted branch feature/mit-bluntschinator (was 3f75ef9).
Summary of actions:
- The feature branch 'feature/mit-bluntschinator' was merged into
'develop'
- Feature branch 'feature/mit-bluntschinator' has been locally deleted
- You are now on branch 'develop'
Oder 'git flow release' um ein neues Release vorzubereiten, oder 'git flow
hotfix' etc.
Das kann man natürlich alles auch "von Hand" machen, aber das Tool nimmt einem
viel Tipparbeit
ab uns sorgt gleichzeitig für Konsistenz im Workflow.
Ich kann dann noch ergänzend gitosis
(https://github.com/tv42/gitosis)
ins Spiel bringen. Ist zwar nur ssh, aber das reicht ja auch, wenn man
sowieso ein projekt management tool mit SCM api einsetzt.
Meister Tomas sagte mal "Gitosis klingt wie eine Krankeit" :-)
Ich würde da eher (für SSH-only) gitolite empfehlen, das kann ein paar
nette Zusatzfunktionen (z.Bsp. sehr feingranulare Zugriffsregeln).
Die Frage ist eher: Macht man sich mehr Aufwand als
nötig, wenn man bei
Subversion bleibt?
Mit jedem Tag mehr den ich mich im Apache Quellcode rumtreibe graut mir mehr
davor.
Gruss RalfD
G, Marek