20 Aug
2017
20 Aug
'17
3:26 p.m.
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.
20 Aug
20 Aug
4:22 p.m.
New subject: [Flug] ?==?utf-8?q? Nachtrag zu Freitag: Versionskontrolle Subversion vs. Git
Am Sonntag, 20. August 2017 15:26 CEST, "Stefan Ziegler"
<stefan.ziegler_zst(a)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
4:57 p.m.
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
5:21 p.m.
New subject: [Flug] ?==?utf-8?q? Nachtrag zu Freitag: Versionskontrolle Subversion vs. Git
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
9:05 p.m.
New subject: [Flug] ?==?utf-8?q? Nachtrag zu Freitag: Versionskontrolle Subversion vs. Git
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(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
_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug(a)lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
9:39 p.m.
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
10:13 p.m.
New subject: [Flug] ?==?utf-8?q? Nachtrag zu Freitag: Versionskontrolle Subversion vs. Git
Am Sonntag, 20. August 2017 21:39 CEST, Uwe Kleine-König <uwe(a)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
10:36 p.m.
New subject: [Flug] ?==?utf-8?q? Nachtrag zu Freitag: Versionskontrolle Subversion vs. Git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Aug 20, 2017 at 10:13:13PM +0200, Ralf Mattes wrote:
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).
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
Am Sonntag, 20. August 2017 21:39 CEST, Uwe Kleine-König <uwe(a)kleine-koenig.org>
schrieb:
Aber jeder sollte :)
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. -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlmZ8tIACgkQBcgs9XrR2kYohwCfSqUTedSbUvP6470Ub4lFqnln
3FsAniV13Qojzg11vAtAA9l0n4LSr6ev
=NOhP
-----END PGP SIGNATURE-----
10:45 p.m.
Hallo Ralf,
On Sun, Aug 20, 2017 at 10:13:13PM +0200, Ralf Mattes wrote:
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.
Uah, Du schlägst vor, dass man im post-commit-hook pusht? Davon würde
ich abraten.
Liebe Grüße
Uwe
Am Sonntag, 20. August 2017 21:39 CEST, Uwe
Kleine-König <uwe(a)kleine-koenig.org> schrieb:
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.
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.
10:31 p.m.
-----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:
Nicht zu vergessen: die Git-"Denke" (gilt auch für andere verteilte
Versionskontrollen) ist zwar eine Schwelle, aber es lohnt sich, die
zu nehmen!
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).
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlmZ8YwACgkQBcgs9XrR2kZfWgCfYCNv2rmgneJXUp1zQ0Iy1U0u
4aAAn3R/6AnVyOmEIk+wunKIl4UyuZ1M
=tZFk
-----END PGP SIGNATURE-----
10:53 p.m.
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
2440
days inactive
2440
days old
10 comments
7 participants
participants (7)
-
Marek Kralewski -
Ralf Mattes -
Ralf Mattes -
Stefan Ziegler -
tomas＠tuxteam.de -
Uwe Kleine-König -
walter harms