Hallo,
Bei FLUG-Treffen Freitag haben wir etwas ausführlicher über Versionskontrolle mit Git gesprochen. Und auch diskutiert, ob es sinnvoll ist, von Subversion auf Git umzustellen.
Dokumentation zu Subversion gibt es u.a hier: http://svnbook.red-bean.com/de/1.7/index.html Das Projektarchiv kann lokal in einem Verzeichnis liegen. Oder entfernt mit Zugriff per HTTP-Server mit WebDAV oder mit svnserve und SSH.
Zu Git hatten wir eine Dokumentation von Xorg/Freedesktop angeschaut - auf Empfehlung von Walter: https://www.freedesktop.org/wiki/Infrastructure/git/Developers/ (war das der Link?)
Ich habe sowas noch gefunden: https://www.kernel.org/pub/software/scm/git/docs/giteveryday.html
Zur Diskussion: Git ist ein gutes Versionssystem für verteilte Entwicklung mit vielen hundert Entwicklern beim Linux-Kernel. Ist Git auch sinnvoll für Firmen mit 3 oder 10 Programmierern, die alle an einem Standort sind? Oder macht man sich dann nur viel mehr Aufwand als nötig? Im Vergleich gesehen zu zentralen Versionsverwaltungen wie CVS oder Subversion.
Viele Grüße, Stefan.
Am Sonntag, 20. August 2017 15:26 CEST, "Stefan Ziegler" stefan.ziegler_zst@gmx.de schrieb:
Zur Diskussion: Git ist ein gutes Versionssystem für verteilte Entwicklung mit vielen hundert Entwicklern beim Linux-Kernel. Ist Git auch sinnvoll für Firmen mit 3 oder 10 Programmierern, die alle an einem Standort sind?
Git ist ein exzellentes VCS für einzelne Entwickler! Selbst wenn's nur darum geht den Entwicklungsweg eines Dokumentes nachzuvollziehen (also etwas für das man früher RCS benutzte) ist Git das Tool der Wahl. Ich habe inzwischen die Konfiguration aller meiner Server in Git Repositories (apt-get install etckeeper).
Oder macht man sich dann nur viel mehr Aufwand als nötig? Im Vergleich gesehen zu zentralen Versionsverwaltungen wie CVS oder Subversion.
Man muss, realistisch betrachtet, eher sagen dass 99.9999% aller Git User als zentrales Verwaltungssystem (also eher nicht verteilt) Nutzen. Das nennt sich dann Github :-/
Git lokal zu nutzen würde ich erst mal als "Aufwandslos" bezeichnen. Ab dann ist die Frage, welche Tool-Chain man nutzen möchte. Das hin-und-herschieben von Patches via Email ist toll wenn man's selbst nutzt, mach' junger Entwickler scheint aber inzwischen eine Email-Unverträglichkeit zu haben (vieleicht sollte man ja ein Twitter-Backend für git-patch schreiben ..). Ein "quasi-zentrales" Repository auf einem Server ist inzwischen trivial. Ich würde für normal-Nutzer aber _dringend_ von einer eigenen Gitlab-Installation abraten. Fürchterlich umständlich. Ich nutze inzwischen gerne Gitea, das ist ein standalone-Binary (in Go geschrieben). Meine Konfig (zu 90% die Defaults übernommen) ist < 50 Zeilen und über das eingebaute Admin-Dashboard kann man sogar solche Nettigkeiten wie LDAP-Anbindung, Team-Verwaltung etc. Damit hat man dann nicht boss einen Git-Server (über HTTP und optional SSH) sondern auch gleich einen Issue-Tracker, Per-Repository Wiki, Online Diff, Auto-Mirroring, User-verwaltetes Schlüssel- Management usw. Da braucht's für Subversion schon richtig viel AdminSchmalz um ein auch nur annähernd mächtiges Setup zu bauen.
Gruss RalfD
Am 20.08.2017 um 15:26 schrieb Stefan Ziegler:
Zur Diskussion: Git ist ein gutes Versionssystem für verteilte Entwicklung mit vielen hundert Entwicklern beim Linux-Kernel. Ist Git auch sinnvoll für Firmen mit 3 oder 10 Programmierern, die alle an einem Standort sind? Oder macht man sich dann nur viel mehr Aufwand als nötig? Im Vergleich gesehen zu zentralen Versionsverwaltungen wie CVS oder Subversion.
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 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.
Die Frage ist eher: Macht man sich mehr Aufwand als nötig, wenn man bei Subversion bleibt?
G, Marek
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-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
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
Hallo Marek,
On 08/20/2017 04:57 PM, Marek Kralewski wrote:
Die Frage ist eher: Macht man sich mehr Aufwand als nötig, wenn man bei Subversion bleibt?
Im Gegenteil, wenn man sich nicht mit git auseinander setzt, verpasst man viel. Zum einen weil git gegenüber svn mächtiger und schneller ist und zum anderen, weil so viele Projekte inzwischen git verwenden, dass heute schon fast eine grundlegende Voraussetzung für Opensource-Mitarbeit ist, mit git umzugehen.
Für Nutzer von Subversion ist der einzige relevante, konzeptionelle Unterschied, dass Committen und Pushen zwei Schritte sind, die zusammen verwirrenderweise bei Subversion commit heißen. Da braucht es also zum einen etwas git-Konzept-Verständnis und zum anderen etwas Disziplin, auch an den push-Schritt zu denken (so man ihn den braucht).
just my 0.02 € Uwe
Am Sonntag, 20. August 2017 21:39 CEST, Uwe Kleine-König uwe@kleine-koenig.org schrieb:
Im Gegenteil, wenn man sich nicht mit git auseinander setzt, verpasst man viel. Zum einen weil git gegenüber svn mächtiger und schneller ist und zum anderen, weil so viele Projekte inzwischen git verwenden, dass heute schon fast eine grundlegende Voraussetzung für Opensource-Mitarbeit ist, mit git umzugehen.
Nun ja, nicht jeder arbeitet an Opensource. Hier ging's ja auch um Firmen.
Für Nutzer von Subversion ist der einzige relevante, konzeptionelle Unterschied, dass Committen und Pushen zwei Schritte sind, die zusammen verwirrenderweise bei Subversion commit heißen.
Wieso verwirrend? Commit schreibt die Änderungen in's Repository. Bei SVN liegt das halt auf dem Server (und nicht lokal) und desswegen muss SVN eben auch "pushen". Das ist nur konsequent.
Da braucht es also zum einen etwas git-Konzept-Verständnis und zum anderen etwas Disziplin,auch an den push-Schritt zu denken (so man ihn den braucht).
Dem ersten Teil würde ich sofort unterstreichen. Das ist extrem wichtig, gerade eben weil git so offen ist, was den Workflow betrifft. Für den zweiten Teil: glücklicherweise gibt's ja bei Git Hooks mit denen man Teile des Workflows automatisieren kann.
Gruss RalfD
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Aug 20, 2017 at 10:13:13PM +0200, Ralf Mattes wrote:
Am Sonntag, 20. August 2017 21:39 CEST, Uwe Kleine-König uwe@kleine-koenig.org schrieb:
Im Gegenteil, wenn man sich nicht mit git auseinander setzt, verpasst man viel. Zum einen weil git gegenüber svn mächtiger und schneller ist und zum anderen, weil so viele Projekte inzwischen git verwenden, dass heute schon fast eine grundlegende Voraussetzung für Opensource-Mitarbeit ist, mit git umzugehen.
Nun ja, nicht jeder arbeitet an Opensource. Hier ging's ja auch um Firmen.
Aber jeder sollte :)
Für Nutzer von Subversion ist der einzige relevante, konzeptionelle Unterschied, dass Committen und Pushen zwei Schritte sind, die zusammen verwirrenderweise bei Subversion commit heißen.
Wieso verwirrend? Commit schreibt die Änderungen in's Repository. Bei SVN liegt das halt auf dem Server (und nicht lokal) und desswegen muss SVN eben auch "pushen". Das ist nur konsequent.
Ich habe schon eingefleischten SVNlern Händchen gehalten. Für die ist es verwirrend (unglücklich, dass git diesen Schritt "commit" genannt hat, obwohl auch naheliegend).
Da braucht es also zum einen etwas git-Konzept-Verständnis und zum anderen etwas Disziplin,auch an den push-Schritt zu denken (so man ihn den braucht).
Dem ersten Teil würde ich sofort unterstreichen. Das ist extrem wichtig, gerade eben weil git so offen ist, was den Workflow betrifft. Für den zweiten Teil: glücklicherweise gibt's ja bei Git Hooks mit denen man Teile des Workflows automatisieren kann.
Persönlich würde ich von solchen Automatismen gerade am Anfang die Finger lassen, und sie erst einführen, wenn man verstanden hat, was läuft (das Konzept-Verständnis eben :) -- aber jede/r lernt anders...
lg - -- t
Hallo Ralf,
On Sun, Aug 20, 2017 at 10:13:13PM +0200, Ralf Mattes wrote:
Am Sonntag, 20. August 2017 21:39 CEST, Uwe Kleine-König uwe@kleine-koenig.org schrieb:
Im Gegenteil, wenn man sich nicht mit git auseinander setzt, verpasst man viel. Zum einen weil git gegenüber svn mächtiger und schneller ist und zum anderen, weil so viele Projekte inzwischen git verwenden, dass heute schon fast eine grundlegende Voraussetzung für Opensource-Mitarbeit ist, mit git umzugehen.
Nun ja, nicht jeder arbeitet an Opensource. Hier ging's ja auch um Firmen.
OK, das ist vielleicht meine rosa Brille, weil ich auch beruflich zum größten Teil mit OSS zu tun habe.
Auch für Firmen ist das verteilte Entwickeln hilfreich. Ich erinnere mich noch an CVS-Zeiten, wo man vor einem Release nicht mehr committen (also pushen) durfte, weil es sonst nicht mehr ohne Gefiesel möglich war, nach dem Release-Build den Tree zu taggen. Mit Subversion ist das besser, da kann man den richtigen Stand schon ein ein Tag gießen. Aber mit einem DVCS kannst Du erst mal lokal taggen und wenn dann der Releasebuild oder dessen Test auf die Bretter geht, pushst Du einfach den Tag nicht, sondern fixt erst das Problem und probierst es nochmal ohne, dass die Welt den Fehlversuch sehen muss und Du eine neue Versionsnummer brauchst.
Für Nutzer von Subversion ist der einzige relevante, konzeptionelle Unterschied, dass Committen und Pushen zwei Schritte sind, die zusammen verwirrenderweise bei Subversion commit heißen.
Wieso verwirrend? Commit schreibt die Änderungen in's Repository. Bei SVN liegt das halt auf dem Server (und nicht lokal) und desswegen muss SVN eben auch "pushen". Das ist nur konsequent.
Ja, wenn "commit" für Dich heißt "ich schiebe das ins (eventuell lokale) Repository", dann hast Du das Konzept von git-commit schon richtig verstanden. Der Otto-Normal-Subversion-Nutzer versteht unter committen aber vielleicht: "Ich mache meine Änderung den anderen zugänglich." und das passt bei git dann nicht.
Da braucht es also zum einen etwas git-Konzept-Verständnis und zum anderen etwas Disziplin, auch an den push-Schritt zu denken (so man ihn den braucht).
Dem ersten Teil würde ich sofort unterstreichen. Das ist extrem wichtig, gerade eben weil git so offen ist, was den Workflow betrifft. Für den zweiten Teil: glücklicherweise gibt's ja bei Git Hooks mit denen man Teile des Workflows automatisieren kann.
Uah, Du schlägst vor, dass man im post-commit-hook pusht? Davon würde ich abraten.
Liebe Grüße Uwe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Aug 20, 2017 at 09:39:42PM +0200, Uwe Kleine-König wrote:
Hallo Marek,
On 08/20/2017 04:57 PM, Marek Kralewski wrote:
Die Frage ist eher: Macht man sich mehr Aufwand als nötig, wenn man bei Subversion bleibt?
Im Gegenteil, wenn man sich nicht mit git auseinander setzt, verpasst man viel. Zum einen weil git gegenüber svn mächtiger und schneller ist und zum anderen, weil so viele Projekte inzwischen git verwenden, dass heute schon fast eine grundlegende Voraussetzung für Opensource-Mitarbeit ist, mit git umzugehen.
Nicht zu vergessen: die Git-"Denke" (gilt auch für andere verteilte Versionskontrollen) ist zwar eine Schwelle, aber es lohnt sich, die zu nehmen!
Für Nutzer von Subversion ist der einzige relevante, konzeptionelle Unterschied, dass Committen und Pushen zwei Schritte sind, die zusammen verwirrenderweise bei Subversion commit heißen. Da braucht es also zum einen etwas git-Konzept-Verständnis und zum anderen etwas Disziplin, auch an den push-Schritt zu denken (so man ihn den braucht).
Da gibt es einen anderen, nicht unwesentlichen, den ich kennenlernte, als ich versucht habe, einen eingefleischten SVN-Fan "umzudrehen": bei SVN ist jedes Unterverzeichnis eines (ausgecheckten) Baums ein eigener Repo (na ja, nicht wirklich ein Repo, aber es behält seine Verbindung zum Repo). Man kann einen Teilbaum auschecken und von da aus committen.
Trotzdem: die Leichtigkeit, mit der man bei git ein Repo lokal "starten" kann und auch lokal betreiben ist unschlagbar. Auch das Offline-Arbeiten und (wenn man sich daran gewöhnt hat), die "Betriebssicherheit" sind verlockend.
Mein Rat: am Anfang ein paar kleine Sachen mit git "lokal" machen.
Git hat "gewonnen" (Darcs z.B. schien mir eleganter), vor allem, weil sie früh einen sehr anspruchsvollen Kunden hatten :-)
Ich will mich nicht daran erinnern, wie es war, wenn man sich das lokale Checkout bei SVN verhunzt hat.
Und @Ralf: ja, bin noch ein Gitolite-Fan :-)
lg - -- tomás
Hallo Tomás,
Git hat "gewonnen" (Darcs z.B. schien mir eleganter), vor allem, weil sie früh einen sehr anspruchsvollen Kunden hatten :-)
Oh, ein Stichwort. Ich fand Darcs erst auch toll. Aber das Konzept ist kaputt, weil Patchaddition keine Gruppe ist. Gerade deshalb fand ich toll, dass git Bäume trackt und nicht Patche und ein Patch nur ein Werkzeug ist um jemandem anderen zu ermöglichen von einem gleichen oder ähnlichen Baum zu einem (hoffentlich) besseren zu kommen.
Abgesehen davon ist es auch effektiver, weil auschecken dann nicht das Anwenden von X Patchen ist, sondern der Baum direkt vorliegt. Dass ein Darcs-Projekt mit vielen Patchen nicht skaliert, ist da keine Überraschung.
Liebe Grüße Uwe
-
Marek Kralewski -
Ralf Mattes -
Ralf Mattes -
Stefan Ziegler -
tomas＠tuxteam.de -
Uwe Kleine-König -
walter harms