Git flow sieht interessant aus.
https://danielkummer.github.io/git-flow-cheatsheet/index.de_DE.html
git-branching-model Netterweise auch mit den Git cmds die dahinter stehen. http://nvie.com/posts/a-successful-git-branching-model/
re, wh
Am 20.08.2017 17:21, schrieb Ralf Mattes:
Am Sonntag, 20. August 2017 16:57 CEST, Marek Kralewski mck@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-bluntschinatorund 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
Freiburger Linux User Group Mail an die Liste: flug@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug