Forum: PC-Programmierung Git ganz alleine benutzen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Ich möchte GIT ganz alleine benutzen, um historische Versionen meiner 
eigenen Sourcen zu archivieren. Bisher habe ich das mit einem lokalen 
SVN Repository gemacht.

Zum Übergang nach GIT habe ich alle Projekte mit "git svn" geklont, und 
zwar alle branches, die mir wichtig sind. Dann habe ich für jedes 
Projekt ein bare Repository angelegt und die Projekte dorthin gepusht.

Allerdings frage ich mich, ob dies wirklich notwendig ist. Ich habe das 
Gefühl, dass die gesamte Historie aller branches bereits in den 
Arbeitsverzeichnissen vorliegt. Vielleicht brauche ich gar keine 
Repositories und kann mir folglich auch die pushes sparen. Richtig?

von Mathias A. (mrdelphi)


Bewertung
1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ich habe das Gefühl, dass die gesamte Historie aller branches bereits in
> den Arbeitsverzeichnissen vorliegt.

So ist es, ...

Stefan ⛄ F. schrieb:
> Vielleicht brauche ich gar keine Repositories und kann mir folglich auch
> die pushes sparen. Richtig?

...genau so nutze ich git seit Jahren auch. Bare Repositories lege ich 
nur an wenn ich es auf mehreren Rechnern clonen und von dort auch pushen 
möchte. Ansonsten habe ich für jedes Projekt genau ein Verzeichnis 
welches sowohl Arbeitsverzeichnis ist als auch das git-Repository 
enthält...ist nur einer der vielen Punkte die mir an git besser gefallen 
als an SVN :-)

von JJ (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Du hast zwei Möglichkeiten:
- Du kannst den Branch im aktuellen Arbeitverzeichnis jederzeit mit git 
checkout ändern
- Du kannst git worktree nutzen um ein Repository mit mehreren 
Arbeitsverzeichnissen zu nutzen.
https://git-scm.com/docs/git-worktree

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Allerdings frage ich mich, ob dies wirklich notwendig ist. Ich habe das
> Gefühl, dass die gesamte Historie aller branches bereits in den
> Arbeitsverzeichnissen vorliegt. Vielleicht brauche ich gar keine
> Repositories und kann mir folglich auch die pushes sparen. Richtig?

Dein Arbeitsverzeichnis enthält bereits das Repository. Von einem 
bare-Repository unterscheidet es sich im Wesentlichen dadurch, dass man 
eben direkt drauf arbeiten kann.
Ich habe trotzdem auf meinem NAS das Repository, zu dem ich immer pushe. 
Das nutze ich einerseits als eine Art Backup, falls ich mir das Repo mal 
versehentlich lokal zerstöre und andererseits, um es schnell auch mal 
auf einem anderen Rechner klonen zu können. Wenn diese Dinge für dich 
nicht nötig sind, gibt es tatsächlich keinen Grund, alles nochmal in ein 
zweites Repo zu pushen.

von Stefan ⛄ F. (stefanus)


Bewertung
2 lesenswert
nicht lesenswert
Danke für eure Antworten.

Ich halte mal für mich fest, dass ich das Repository nicht zwingend 
brauche, aber es taugt gut als Backup. Da ich es von SVN so gewohnt bin 
nutze ich es vorläufig als Backup.

von Bastler (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Melde dich bei bei Gitlab oder Github (oder einem anderen Dienst) an, 
und verwende private Repositories. Ist besser als jedes private Backup.

von M. H. (bambel2)


Bewertung
1 lesenswert
nicht lesenswert
das Repo nur im Arbeitsverzeichnis zu haben, geht super. Ich versioniere 
fast alles mit git... Selbst die Vorlagen für meine Krankmeldungen...

Wenn du aber doch mal ein remote-Repo brauchst/willst und nicht zu 
github etc. willst, gibt es noch die alternative etwas selbst zu hosten.

Mein Favorit für kleine Heimprojekte:

https://gogs.io/

Das ist ein kleiner Server mit Webseite für git (ähnlich wie github). 
Sehr schlank und einfach aufzusetzen im Gegensatz zu Alternativen 
(Bitbucket, Gitlab). Das läuft auf jedem Raspberry Pi.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> Melde dich bei bei Gitlab oder Github (oder einem anderen Dienst)
> an, und verwende private Repositories. Ist besser als jedes
> private Backup.

Das habe ich gerade für ein Projekt gemacht.

Doch habe ich Hemmungen, meine Sachen alle ohne wirklichen Bedarf in die 
Klaut zu stellen. Auf welcher Basis sollte ich diesem Anbieter 
vertrauen?

: Bearbeitet durch User
von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Doch habe ich Hemmungen, meine Sachen alle ohne wirklichen Bedarf in die
> Klaut zu stellen. Auf welcher Basis sollte ich diesem Anbieter
> vertrauen?

Das würde ich mit privatem zeug auch nicht machen. Selbst ein bare-repo 
irgendwo abzulegen, vorzugsweise auf einem anderen Rechner oder NAS, 
finde ich ist da auch die beste Lösung.

Ganz ohne bare-repo würde ich aber auch nicht machen, es ist mir schon 
ein zwei mal passiert, dass ich versehentlich meine Lokale Arbeitskopie, 
oder den .git Ordner darin gelöscht habe.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe die bare repositories auf einer Netzwerkfestplatte. Auch wenn 
das prinzipiell nicht unbedingt nötig ist, ist es so, wie DPA auch sagt, 
auch ein backup.

Oliver

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Ich habe die bare repositories auf einer Netzwerkfestplatte. Auch wenn
> das prinzipiell nicht unbedingt nötig ist, ist es so, wie DPA auch sagt,
> auch ein backup.

Hier handhaben wir das auch so: alle Projekte liegen auf dem 
Netzwerkserver und direkt auf diesen wird auch gearbeitet. Weiteres 
git-Klonen geschieht nur in Ausnahmefällen (Reisen etc.).

Der Server wird täglich rotierend auf USB-Platten gesichert und fertig.

von Jens (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Doch habe ich Hemmungen, meine Sachen alle ohne wirklichen Bedarf in die
> Klaut zu stellen. Auf welcher Basis sollte ich diesem Anbieter
> vertrauen?

Deswegen einfach eine eigene Gitea-Instanz auf dem NAS laufen lassen :-)

Das war selbst für einen Noob wie mich in wenigen Minuten eingerichtet 
(Synology und Docker sei Dank).

Vorteile:
 - Die Daten liegen auf MEINEM Server
 - Nahezu unbegrenzter Speicherplatz ;-)
 - Ich hab sie auf allen Rechnern synchron (PC, Notebook)
 - Mit den Backups des NAS werden auch alle Repos gebackupt
 - Ich kann von überall auch per Webbrowser in meine Repos schauen und 
sogar darin arbeiten
 - Bei Bedarf kann ich auch Freunden oder Arbeitskollegen Zugriff geben, 
wenn man mal zusammen an einem kleinen Projekt arbeiten möchte

Läuft seit einigen Jahren wie geschmiert :-)

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
M. H. schrieb:
> Das ist ein kleiner Server mit Webseite für git (ähnlich wie github).
> Sehr schlank und einfach aufzusetzen im Gegensatz zu Alternativen
> (Bitbucket, Gitlab).

GitLab ist tatsächlich überraschend einfach aufzusetzen und zu 
verwalten. Das macht praktisch alles automatisch. GitLab ist sehr 
mächtig, für einen einzelnen Entwickler allerdings wahrscheinlich 
Overkill, und ob es auf einem R-PI flüssig läuft weiß ich nicht.

Von wegen Cloud: Man kann "bare" git Repositories z.B. auf eine Strato 
HiDrive-Cloud (wird beworben als sicherer Cloud-Speicher) kopieren und 
dahin dann direkt pushen/pullen. Hat dann aber keine Web-Oberfläche 
sondern ist nur eine schlichte Ablage eines "bare" repo.

von Gitea (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ich würde eher gitea statt gogs nehmen. Ist ein Fork von gogs, aber 
besser maintained und mit mehr Möglichkeiten. Ansonsten sehe ich Gitlab 
auf einem eigenen Server als Alternative.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Deswegen einfach eine eigene Gitea-Instanz auf dem NAS laufen lassen :-)

Ich habe bereits geschafft, ein leeres Verzeichnis anzulegen und darin 
den Befehl "git init --bare" einzugeben.

Die ursprüngliche Frage war, ob ich das benötige bzw. welchen Nutzen es 
mir (ganz alleine) bringt, was auch beantwortet wurde.

: Bearbeitet durch User
von Florian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gitea schrieb:
> Ich würde eher gitea statt gogs nehmen. Ist ein Fork von gogs, aber
> besser maintained und mit mehr Möglichkeiten. Ansonsten sehe ich Gitlab
> auf einem eigenen Server als Alternative.

Ich würde eher gitolite3 nehmen. Kein unnötiges GUI, leicht zu 
installieren (apt install) und zu konfigurieren (conf und keyfile)...

von Jan H. (j_hansen)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Strato
> HiDrive-Cloud (wird beworben als sicherer Cloud-Speicher)

Ist zwar nun schon Off-Topic, aber das Angebot würde ich nicht unbedingt 
bewerben. Nachdem die jetzt schon zwei Wochen lang große 
Performanceprobleme haben und wohl nicht wissen was sie tun, wäre ich 
bezüglich Sicherheit und Verfügbarkeit nicht beruhigt.

https://www.heise.de/newsticker/meldung/Lang-anhaltende-Stoerung-bei-Stratos-V-Servern-4727320.html

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Für Anfänger ist die Vielfalt der Tools (runf um GIT) eher verwirrend 
als hilfreich. Etwa 10 Stück habe ich ausprobiert und für Kacke 
befunden. Jetzt bin ich wieder bei der Kommandozeile und gitk.

Ich kenne TortoiseSVN und TortoiseHG - die haben bestimmt auch ein 
ähnliches Programm für GIT. Wenn e das für Linux gäbe, wäre ich 
glücklich. Die Software von Tortoise legt die Messlatte ziemlich hoch, 
was den Bedienkomfort angeht.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jan H. schrieb:
> Nachdem die jetzt schon zwei Wochen lang große
> Performanceprobleme haben und wohl nicht wissen was sie tun, wäre ich
> bezüglich Sicherheit und Verfügbarkeit nicht beruhigt.

Das sind die V-Server, nicht der Cloud-Speicher. Ich habe mit letzterem 
seit vielen Jahren keine Probleme.

Stefan ⛄ F. schrieb:
> Jetzt bin ich wieder bei der Kommandozeile und gitk.

Die git-Kommandozeile zu beherrschen ist auf jeden Fall sinnvoll. Früher 
oder später stolpert man über eine Befehls-Konstellation die sich nur 
per Kommandozeile machen lässt, und dann ist man froh nicht nur in den 
GUI-Tools herumklicken zu können. Wenn man die etwas kryptischen aber 
essentiellen Befehle kennt, ist die Kommandozeile in der Bedienung nicht 
wirklich schlimmer als per GUI. Die in IDEs eingebauten Diff/Merge-Tools 
(insb. das von Eclipse) sind allerdings auch sehr hilfreich. "gitg" ist 
auch gelegentlich nützlich.

von Jan H. (j_hansen)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Das sind die V-Server, nicht der Cloud-Speicher.

Und du glaubst der Cloud-Speicher läuft nicht im selben RZ? geht ja 
nicht darum, dass der Cloud-Speicher jetzt Probleme hätte, sondern dass 
die Firma bei Problemen sehr planlos wirkt. Aber ist ja auch egal

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ich kenne TortoiseSVN und TortoiseHG - die haben bestimmt auch ein
> ähnliches Programm für GIT. Wenn e das für Linux gäbe, wäre ich
> glücklich. Die Software von Tortoise legt die Messlatte ziemlich hoch,
> was den Bedienkomfort angeht.

TortoiseGit legt die sogar moch etwas höher.

Ist aber heutzutage doch völlig egal, da jede ernstzunehmende IDE eine 
vollständige git-Integration bietet.

Oliver

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Ist aber heutzutage doch völlig egal, da jede ernstzunehmende IDE eine
> vollständige git-Integration bietet.

Naja, wenn man öfter die IDE wechselt (passiert insb. im 
Embedded-Bereich öfters) ist es auch etwas lästig sich ständig an neue 
git-Oberflächen zu gewöhnen. Die git-Kommandozeile hingegen ist immer 
vorhanden und konsistent und funktioniert auch auf konsolenbasierten 
Umgebungen, z.B. Buildserver.

Wenn man bei spezielleren git-Problemen das Internet befragt werden die 
meisten Lösungen git-Konsolen-Befehle sein, und nicht immer kann man die 
einfach 1:1 Copy&Pasten und muss schon etwas damit anzufangen wissen.

Das Komplizierte an git ist sowieso nicht das Auswendig-Lernen der 
Befehle an sich, sondern die abstrakten Konzepte zu verstehen - was 
genau sind Commits, (Remote-Tracking-)Branches, Tags, Merges, Remotes, 
Merge-Strategies...

Ich hab schon öfter Leute verzweifeln sehen weil sie ohne ihre 
git-fähige IDE nicht wussten wie sie ihre Repositories verwalten 
müssen...

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> Naja, wenn man öfter die IDE wechselt (passiert insb. im
> Embedded-Bereich öfters) ist es auch etwas lästig sich ständig an neue
> git-Oberflächen zu gewöhnen.

Genau das ist bei mir der Punkt. Als Senior Entwickler berate ich die 
Kollegen bei Problemen. Da sind drei IDE's im Umlauf, die ich alle gut 
kennen muss, deswegen wechsele ich sie alle paar Monate.

Bislang wechselte ich auch oft zwischen Windows und Linux, wobei ich 
Windows inzwischen zu benutzen verweigere wegen ungeklärter Fragen rund 
um die DSGVO.

Wir nutzen im Büro (noch) Hg und TortoiseHg gibt es zum Glück auch für 
Linux. Bei Git muss ich dann wohl umdenken. Aber erst einmal übe ich zu 
hause die ganzen Schweinereien von Git (von wegen Historie 
manipulieren), damit ich vorher weiß, was ich im Büro besser strikt 
verbiete.

Alleine deswegen brauche schon mehrere remote Repositories. Meine Frage 
im Eröffnungs-Thread war daher eher hypothetisch (würde ich eins 
brauchen, wenn ich ganz alleine arbeite und nicht den Umgang mit Repos 
lernen will?).

: Bearbeitet durch User
von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also ich mach das Bauen, des Verwalten der Repos und das Editieren von 
Code mit dedizierten Tools. Bauen von Zeugs mit make (sofern das Projekt 
nichts anderes nutzt) im Terminal, Verwalten der Git repos mit git im 
Terminal, editieren von Code mit Kate. Auch Dinge wie gdb, valgrind, 
strace, etc. nutze ich direkt.

Warum nehmen Leute überhaupt IDEs, die brauchen ewig zum Starten, haben 
immer andere Interfaces, erschweren die direkte Interaktion mit den 
eigentlichen Tools, etc. Auch praktischer finde ich das nicht, ich kann 
mit einem Tastendruck zwischen den Bildschirmen mit den Tools wechseln, 
plus, ich hab dann nen ganzen Bildschirm, um mit denen zu arbeiten, stat 
irgendwo nen kleinen Bereich in der IDE, in dem man kaum was sieht...

von Sebastian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Backup auf USB Stick funktioniert auch prima, wenn man keinen 
Netzwerkspeicher hat. Einfach vor dem push einstecken.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
DPA schrieb:
> Warum nehmen Leute überhaupt IDEs

Ich finde sie schon komfortabler, aber ich bin auch sehr dafür, von 
ihnen unabhängig zu sein. Wenn eine IDE mal versagt oder warum auch 
immer nicht verfügbar ist, sollte man trotzdem arbeitsfähig bleiben. 
Dann ist ein Wechsel der IDE auch viel einfacher möglich und jeder 
Entwickler im Team kann nehmen, womit er am besten klar kommt.

: Bearbeitet durch User
von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Genau das ist bei mir der Punkt. Als Senior Entwickler berate ich die
> Kollegen bei Problemen.

Na, da ist's doch schön mit dem git-Konsolen-Wissen angeben zu können :)

DPA schrieb:
> Warum nehmen Leute überhaupt IDEs

Diese Frage kannst du dir selbst beantworten indem du eine 
leistungsfähige IDE wie z.B. Android Studio mit Java oder Kotlin auf 
einem modernen Rechner benutzt und daran denkst, dass in professionellen 
Kontexten ein paar Tausend € für Equipment (PC, Software) nachrangig 
hinter der Arbeitszeit des Entwicklers sind - nicht nur wegen der 
Lohnkosten, sondern auch wegen Time-To-Market.

Sebastian schrieb:
> Backup auf USB Stick funktioniert auch prima, wenn man keinen
> Netzwerkspeicher hat.

USB-Sticks sind leider notorisch unzuverlässig. Bei Einbruch, Brand o.ä. 
werden die zusammen mit dem Rechner in Mitleidenschaft gezogen. Daher 
sind Off-Site-Backups (Cloud), zumindest wenn man die Daten 
(Source-Code, Dokumente, ...) zum Geld verdienen braucht, essentiell. 
Wenn man dem Cloud-Anbieter nicht traut kann man die Daten ja auch 
verschlüsseln, und so teuer sind die "guten" Anbieter auch nicht.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe auf meinem vServer ein Verzeichnis, wo ich meine privaten Repos 
per ssh pushe, eigentlich auch nur als Backup und weil es praktisch ist 
wenn man das Projekt mal von einem anderen Rechner aus braucht.

Aber Vorsicht: ein git remote ist kein Ersatz für ein Backup auf eine 
externe Festplatte oder ähnliches. Man kann relativ leicht beide Repos 
kaputt machen.

von DPA (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> DPA schrieb:
>> Warum nehmen Leute überhaupt IDEs
>
> Diese Frage kannst du dir selbst beantworten indem du eine
> leistungsfähige IDE wie z.B. Android Studio mit Java oder Kotlin auf
> einem modernen Rechner benutzt und daran denkst, dass in professionellen
> Kontexten ein paar Tausend € für Equipment (PC, Software) nachrangig
> hinter der Arbeitszeit des Entwicklers sind - nicht nur wegen der
> Lohnkosten, sondern auch wegen Time-To-Market.

Ich kenne Eclipse und Netbeans, ich musste mit dem Zeugs schon Webseiten 
schreiben. Schneller schreib ich den Code in denen auch nicht. Auch toll 
ist, wenn z.B. irgendwelche Schleifen unterliniert werden, und dann 
andere meinen, das automatisiert durch was weniger licheres ersetzen zu 
müssen...

Am längsten dauert dort aber sowieso immer, wenn z.B. maven wiedermal 
spinnt, oder ein Framework wie z.B. Spring irgend ne obskure 
Fehlermeldung beim Starten wirft, zu der man nirgends was brauchbares 
finden kann, usw. Und dann hatte ich mit dem IDE scheiss dort schon 
Sachen, wo es z.B. beim Bauen in der Konsole ging, aber in der IDE 
nicht, oder nur nach beim 2ten mal in der IDE bauen, oder dass mal was 
nicht neu übersetzt wurde was hätte sollen, und all solchen scheiss, den 
ich bei anderen Sprachen und Buildumgebungen nie hatte...

Ne, hier wurden die Java Anwendungen mittlerweile größtenteils in was 
anderem neu geschrieben. War aber sowieso langsam mal nötig.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Ich kenne Eclipse und Netbeans, ich musste mit dem Zeugs schon Webseiten
> schreiben.

Ist kein Vergleich. Probiere es einfach aus.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
DPA schrieb:
> Ich kenne Eclipse und Netbeans

Dann schau Dir mal IDEA IntelliJ an, diese IDE ist in jeder Hinsicht um 
Welten besser - das merk man aber erst, wenn man einige Wochen damit 
gearbeitet hat, denn es sind zahllose kleine Details (und bessere 
Stabilität), die in Summe den großen Unterschied ausmachen.

In der Kostenlosen Version musst du deinen Applikationsserver allerdings 
außerhalb der IDE starten.

: Bearbeitet durch User
von Mathias A. (mrdelphi)


Bewertung
1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ich kenne TortoiseSVN und TortoiseHG - die haben bestimmt auch ein
> ähnliches Programm für GIT. Wenn e das für Linux gäbe, wäre ich
> glücklich. Die Software von Tortoise legt die Messlatte ziemlich hoch,
> was den Bedienkomfort angeht.

TortoiseGit gibt's, und finde ich mit Abstand die beste GUI für git die 
ich kenne. Leider, leider nur für Windows verfügbar -- so nutze ich es 
auf dem Firmenlaptop sehr gerne -- privat gibt's bei mir allerdings kein 
Windows und demnach kein TortoiseGit :-(

Stefan ⛄ F. schrieb:
> Jetzt bin ich wieder bei der Kommandozeile und gitk.

Das sind bei mir unter Linux auch die bevorzugten Tools für git. 
Kommandozeile zu 99% -- ziemlich selten mal gitk, etwas häufiger noch 
tig -- ist eine "GUI" an der Text-Konsole, Bedienung daher 
gewöhnungsbedürftig, aber komme damit meist besser zurecht als mit gitk.


Allerdings ist es schon wieder Jahre her dass ich zuletzt bzgl Git-GUI 
für Linux recherchiert habe, womöglich gibt's inzwischen doch was 
besseres? Insbesondere Web-Oberflächen wollte ich schon länger mal näher 
anschauen, also sowas wie gitlab, github u.s.w., allerdings zum selbst 
installieren. Hier im Thread wurden ja auch noch welche genannt...

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Mathias A. schrieb:
> womöglich gibt's inzwischen doch was besseres?

gitkraken soll gut sein, ist aber kostenpflichtig.

Meine Kollegen evaluieren gerade gitlab. Das scheint sinnvoll zu sein, 
wenn man die Arbeit des Teams am Projekt mit diesem Tool koordinieren 
will. Dafür haben wir aber schon andere Tools (Jira, Jenkins) bei denen 
wir vermutlich bleiben werden, denn unsere Welt besteht nicht nur auf 
GIT Projekten. Noch ist nichts entschieden.

: Bearbeitet durch User
von Marcus H. (mharnisch) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Mathias A. schrieb:
>> womöglich gibt's inzwischen doch was besseres?

Emacs+Magit macht mir das Leben erträglich bevor ich nach der Arbeit 
wieder zu Hg wechseln darf :) Im Ernst: Magit ist eine verdammt gute Git 
Oberfläche. Ich habe von Leuten gehört, die nur sich nur deswegen für 
Emacs als Editor entschieden haben.

> Meine Kollegen evaluieren gerade gitlab. Das scheint sinnvoll zu sein,
> wenn man die Arbeit des Teams am Projekt mit diesem Tool koordinieren
> will. Dafür haben wir aber schon andere Tools (Jira, Jenkins) bei denen
> wir vermutlich bleiben werden, denn unsere Welt besteht nicht nur auf
> GIT Projekten. Noch ist nichts entschieden.

Für bestehende Hg Projekte vielleicht Heptapod (GitLab fork) -- dann ist 
die Bedienung wengistens einheitlich. RhodeCode, Kallithea und 
Phabricator können mit Git, Hg und SVN unter einem Dach umgehen.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Puh, so viele Wahlmöglichkeiten!

Das blöde ist, dass man all diese Programm nicht schon nach 5 Minuten 
bewerten kann. Manche haben ihre Qualitäten bzw Haken ein bisschen 
verborgen, so dass man eine Weile braucht, um sie zu bemerken.

von Marcus H. (mharnisch) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Aber erst einmal übe ich zu
> hause die ganzen Schweinereien von Git (von wegen Historie
> manipulieren), damit ich vorher weiß, was ich im Büro besser strikt
> verbiete.

Aber das ist doch bei DVCS Teil des Konzepts?! Nur veröffentlichte 
commits sollte man nach Möglichkeit nicht nachträglich verändern, wenn 
das DVCS damit nicht sauber umgehen kann.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Marcus H. schrieb:
> Aber das ist doch bei DVCS Teil des Konzepts?! Nur veröffentlichte
> commits sollte man nach Möglichkeit nicht nachträglich verändern, wenn
> das DVCS damit nicht sauber umgehen kann.

Die Firma in der ich arbeite kennt den Begriff "Veröffentlichung" nicht.

Wir brauchen die Nachvollziehbarkeit aller Veränderungen. Was die Leute 
lokal auf ihren Laptops machen, ist deren Sache. Aber sobald ein Ticket 
an den Test übergeben wird, muss relevante Änderung unveränderbar 
dokumentiert sein.

Wenn jemand für einen Fix 10 Anläufe zur Lösung braucht, dann haben wir 
eben Einträge in der Historie. Sieht hässlich aus, soll aber so sein.

: Bearbeitet durch User
von DPA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Wir brauchen die Nachvollziehbarkeit aller Veränderungen. Was die Leute
> lokal auf ihren Laptops machen, ist deren Sache. Aber sobald ein Ticket
> an den Test übergeben wird, muss relevante Änderung unveränderbar
> dokumentiert sein.

Dann auf jeden fall force pushs und löschen von branches deaktivieren. 
Wie auf das Repo zugegriffen wird spielt bei solchen Anforderungen auch 
eine rolle.

von Uhu U. (uhu)


Bewertung
-1 lesenswert
nicht lesenswert
Bei openHPI beginnt am 03.06. ein Kurs "Let’s Git – Versionsverwaltung 
und Open Source". Die Teilname ist kostenlos, ein Zeugnis kann man auch 
bekommen, so man das will.

von Marcus H. (mharnisch) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Aber sobald ein Ticket
> an den Test übergeben wird, muss relevante Änderung unveränderbar
> dokumentiert sein.

Das ist in dem Fall die Veröffentlichung. Vermutlich ein push auf ein 
anderes Repository, von dem aus die Tests gestartet werden.
Hg löst das ganz elegant durch “phases” (secret, draft, public). Alles 
was public ist, darf nicht mehr (ohne weiteres) verändert werden.

> Wenn jemand für einen Fix 10 Anläufe zur Lösung braucht, dann haben wir
> eben Einträge in der Historie. Sieht hässlich aus, soll aber so sein.

Es wäre aber schon schön wenn ich den Freitag-Abend-Sicherheits-Commit 
unter Umgehung des Montag-ich-hab-noch-solchen-Kater-Commits, am 
Dienstag vervollständigen könnte. Ich sehe die Historie zunehmend als 
Teil der Dokumentation des Entwicklungsprozesses an.

von Florian (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
DPA schrieb:
> Stefan ⛄ F. schrieb:
>> Wir brauchen die Nachvollziehbarkeit aller Veränderungen. Was die Leute
>> lokal auf ihren Laptops machen, ist deren Sache. Aber sobald ein Ticket
>> an den Test übergeben wird, muss relevante Änderung unveränderbar
>> dokumentiert sein.
>
> Dann auf jeden fall force pushs und löschen von branches deaktivieren.
> Wie auf das Repo zugegriffen wird spielt bei solchen Anforderungen auch
> eine rolle.

Das oben erwähnte gitlab kann das ebenfalls und nennt es "protected 
branches": https://docs.gitlab.com/ee/workflow/protected_branches.html

Nutze in der Arbeit auch gitlab mit Jenkins und Jira. Funktioniert 
problemlos. Man muss ja nicht alle features (tickets, wikis, ...) von 
gitlab auf einmal nutzen. Privat nutze ich gitolite, da ich kein WebUI 
brauche. Ansonsten git via bash und gelegentlich gitk oder tig.

Und wenn man mal nicht weiter weiß, einfach die "git help <cmd>" lesen 
oder auf stackoverflow suchen.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke der Mittelweg ist, force pushes auf protected branches zu 
verbieten. Sie ganz auszuschalten finde ich nicht so toll, ich würde 
Review-Kommentare schon gern in die Commits einpflegen, in die sie 
logisch reingehören und nicht in jedem Branch mit 3 Commits, der 
gemerged wird, noch 12 Commits mit "rename variable" und "rephrase 
comment" obendrauf haben.

von Rolf M. (rmagnus)


Bewertung
-1 lesenswert
nicht lesenswert
Sven B. schrieb:
> Ich denke der Mittelweg ist, force pushes auf protected branches zu
> verbieten. Sie ganz auszuschalten finde ich nicht so toll, ich würde
> Review-Kommentare schon gern in die Commits einpflegen, in die sie
> logisch reingehören und nicht in jedem Branch mit 3 Commits, der
> gemerged wird, noch 12 Commits mit "rename variable" und "rephrase
> comment" obendrauf haben.

Klingt für mich irgendwie komisch, bestehende Commits nachträglich 
nochmal zu verändern. Aber ich habe sehr lange alles mit svn gemacht, wo 
jeder Commit fix und unveränderbar ist (außer vielleicht durch den Admin 
direkt auf dem Server). Vorteil ist, dass man etwas, das einmal da drin 
ist, nicht mehr kaputt machen kann. Jeder beliebige frühere Stand des 
Repos kann später zu 100% reproduziert werden. Deshalb war's für mich 
erst mal etwas gewöhnungsbedürftig, dass man bei git auch an schon 
eingecheckten Sachen später noch rummanipulieren und auch mal schnell 
alles kaputt machen kann.

Zu den Reviews: Ich dachte, dafür sind Pull-Requests gedacht.

von DPA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Zu den Reviews: Ich dachte, dafür sind Pull-Requests gedacht.

Pull/Merge Requests sind nicht teil von Git. Das ist lediglich ein 
häufiges Feature diverser Webfrontends für Versionsverwaltungssysteme. 
Traditionell werden Mailinglisten für das Senden & Reviewen von Patches 
oder links zu einem Repo/Branch verwendet, einige Freie Softwareprojekte 
machen das auch heute noch so. Prinzipiell spielt es keine rolle, wie 
oder worüber man die Codeänderungen verteilt und anschaut. Das 
Pull/Merge Requests Feature von Github, Gitlab und co. ist aber durchaus 
relativ beliebt, weil es das ganze relativ simpel macht. Man muss sich 
aber auch bewusst sein, dass diese auch Limitationen haben. Will man 
z.B. mehrere Branches mergen, Commits von anderen
 oder im Webfrontend nicht als geforkt markierten Projekten, oder andere 
komplexere Dinge, muss man das immer noch wie früher manuell lokal 
machen.

von DPA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Klingt für mich irgendwie komisch, bestehende Commits nachträglich
> nochmal zu verändern.

Nach dem Commit hat man die vor dem Push ja zunächst noch lokal. Dann 
ist es ganz praktisch, das vor dem Puschen nochmal aufbereiten zu 
können, also Schreibfehler korrigieren, Beschreibungen ausschmücken, 
commits zusammenführen oder auftrennen, um sie getrennt betrachten zu 
können, oder nicht funktionierende Zwischenstände nicht zu pushen, usw. 
In dem Zusammenhang sind auch force-pushes zu temporären Branches, die 
zum mergen vorgesehen sind, praktisch. Was zählt ist dann in der Regel 
die Historie nach dem Merge, in den Haupt-branches, die sollte man dann 
nicht mehr verändern. Und dann gibt es noch kosmetische Entscheide, wie 
z.B., will man bei einem Merge die Commits zusammenfassen (squashen), 
oder einzeln lassen, will man nen merge commit, usw.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Klingt für mich irgendwie komisch, bestehende Commits nachträglich
> nochmal zu verändern. Aber ich habe sehr lange alles mit svn gemacht, wo
> jeder Commit fix und unveränderbar ist (außer vielleicht durch den Admin
> direkt auf dem Server).

Das ist ja bei git tatsächlich genauso: auch ein force push oder amend 
ändert keine Commit-Objekte, sondern erzeugt neue und ändert den 
Branch-Pointer so, dass er auf die neuen zeigt. Die alten Commits 
bleiben aber erhalten (werden allerdings nach ein paar Wochen 
garbage-collected, wenn kein Branch oder Tag auf sie verweist). Bis 
dahin aber kann man die Änderungen vergleichsweise leicht rückgängig 
machen.

Das history-rewriting ist sicherlich etwas gewöhnungsbedürftig, aber für 
Reviews finde ich es wirklich wertvoll. Ich sortiere z.B. Commits auch 
vor Erstellen eines Reviews gerne nochmal um, mit dem Gedanken "für den 
Leser ist es eigentlich logischer, wenn sich das zuerst ändert". Oder 
fasse welche zusammen, die später vergessene Teile eines Refactorings 
noch nachgereicht haben.

von Mathias A. (mrdelphi)


Bewertung
-1 lesenswert
nicht lesenswert
DPA schrieb:
> Rolf M. schrieb:
>> Klingt für mich irgendwie komisch, bestehende Commits nachträglich
>> nochmal zu verändern.
>
> Nach dem Commit hat man die vor dem Push ja zunächst noch lokal. Dann
> ist es ganz praktisch, das vor dem Puschen nochmal aufbereiten zu
> können, also Schreibfehler korrigieren, Beschreibungen ausschmücken,
> commits zusammenführen oder auftrennen, um sie getrennt betrachten zu
> können, oder nicht funktionierende Zwischenstände nicht zu pushen, usw.
> In dem Zusammenhang sind auch force-pushes zu temporären Branches, die
> zum mergen vorgesehen sind, praktisch. Was zählt ist dann in der Regel
> die Historie nach dem Merge, in den Haupt-branches, die sollte man dann
> nicht mehr verändern.

Genau so ?

Dass man Commits erstmal in Ruhe lokal machen und ggf korrigieren kann, 
bevor man sie veröffentlicht, finde ich einen großen Vorteil im 
Vergleich zu SVN.

Und ja, der oder die Haupt-Branches sollten auf dem Server nie 
nachträglich geändert werden. (ich meine dass man das auch technisch 
unterbinden kann, habe es allerdings selbst noch nie gemacht).
Außer der dann nicht mehr 100% nachvollziehbaren Historie ist ein 
weiterer Grund, dass bei Änderung eines Commits in Wirklichkeit ein 
neuer Commit erstellt wird, mit neuer commit-id, und alle Commits die 
auf dem geänderten aufbauen werden ebenfalls neu erstellt und bekommen 
neue commit-ids. Wenn jemand anderes die ursprünglichen Commits bereits 
ausgecheckt hatte, kommt es dadurch zu Inkonsistenzen. Welche 
Konsequenzen es genau hat weiß ich nicht, aber git an der Kommandozeile 
zeigt manchmal Warnungen, wenn man was macht was solche Probleme 
verursachen könnte.

Die ursprünglichen Commits werden dabei übrigens nicht gelöscht, es wird 
nur der aktuelle branch zu den neuen Commits umgehängt, dadurch sind die 
alten nicht mehr direkt sichtbar. Falls sie aber noch zu einem weiteren 
branch gehören, bleiben sie meines Wissens dort sichtbar...

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Marcus H. schrieb:
> Es wäre aber schon schön wenn ich den Freitag-Abend-Sicherheits-Commit
> unter Umgehung des Montag-ich-hab-noch-solchen-Kater-Commits, am
> Dienstag vervollständigen könnte.

Ja, genau dafür interessiere ich mich auch. Aber es steht im Widerspruch 
zu dem Grundsatz, die Historie nachträglich nicht mehr zu manipulieren. 
Das muss man halt mal durchdenken und ausprobieren, bevor man es an 
echten Projekten macht.

Ich könnte mir vorstellen, dass die Programmierer für jedes Ticket einen 
temporären Entwickler-Branch starten, diesen bei Abgabe in den 
Testing-Branch mergen und dann ihren temporären Entwickler-Branch 
verschwinden lassen. Dann hat man vielleicht genug Nachvollziehbarkeit 
und zugleich weniger Commits in der Historie, als ich das bisher von HG 
und SVN gewohnt bin.

> Ich sehe die Historie zunehmend als Teil
> der Dokumentation des Entwicklungsprozesses an.

In der Firma wo ich arbeite ist sie längst integraler Bestandteil des 
Entwicklungsprozesses. Wir schreiben seit einigen Jahren auch keine 
Changelog.txt Dateien mehr, wobei wir gerade diskutieren, dass für 
gemeinsam genutzte Komponenten und Bibliotheken (wovon mehrere 
unterschiedliche Versionen gleichzeitig in Produktion sind) doch wieder 
einzuführen.

Das meiste unserer Produkte ist nach wie vor individuelle Software, von 
denen exakt eine Version in Produktion existiert.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Sven B. schrieb:
> nicht in jedem Branch mit 3 Commits, der
> gemerged wird, noch 12 Commits mit "rename variable" und "rephrase
> comment" obendrauf haben.

Genau das ist ein Punkt, wo ich das Manipulieren der Historie trotz 
meiner prinzipiellen Ablehnung doch attraktiv finde. Wenn ein 
Programmierer glaubt, er sei fertig, gibt es das einem anderen 
Programmierer zum Review. Der übergibt es an einen oder mehrere Tester, 
und erst dann geht es in die Produktion. Während dieser Reviews und 
Tests kommt es häufig vor, dass die Doku umstrukturiert wird und 
manchmal auch das Programm - damit wir durch unseren eigenen Code 
langfristig noch durchblicken. Das fängt mit besseren Namen für Symbole 
an und geht manchmal so weit, eine extrem lange Funktion im mehrere 
kleine aufzusplitten. Oder eine gemeinsam genutzte Universalfunktion, 
die inzwischen viele Sonderlocken enthält, in spezialisierte Funktionen 
auszuteilen. Das alles hat im Idealfall keinen Einfluss auf die 
Funktion, interessiert daher den betrieb und die Nachwelt nicht die 
Bohne.

Deswegen könnte ich damit leben, mehrere Commits dieser Art zu einem 
"Refactor code, no functional change" zusammen zu fassen. Aber da kommt 
ich an den Punkt, wo ich meine eigenen bewährten Prinzipien zumindest 
teilweise über Board werfen muss. Da darf ich mir keine groben Fehler 
leisten, denn ich bin für die Qualität der Quelltexte verantwortlich.

Bisher gab es da gar nicht zu diskutieren, da die Historie 
unveränderlich war. Nun kommt da eine womöglich folgenschwere 
Entscheidung auf mich zu, die sich aus den neuen technischen 
Möglichkeiten ergibt.

By the way, wir sind jetzt ganz weit weg vom Titel des Threads. Aber das 
ist mir jetzt auch egal. Genau diese Fragen hätte ich hier auch noch 
aufgeworfen, nur später.

: Bearbeitet durch User
von Marcus H. (mharnisch) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Ich könnte mir vorstellen, dass die Programmierer für jedes Ticket einen
> temporären Entwickler-Branch starten, diesen bei Abgabe in den
> Testing-Branch mergen und dann ihren temporären Entwickler-Branch
> verschwinden lassen. Dann hat man vielleicht genug Nachvollziehbarkeit
> und zugleich weniger Commits in der Historie, als ich das bisher von HG
> und SVN gewohnt bin.

Das verstehe ich nicht. Hg und Git sind sich in dieser (und vielen 
anderen Dingen) sehr ähnlich. Selbstverständlich kannst Du auch mit 
ersterem die Historie verändern. Mache ich ständig. Das (offiziell noch 
experimentelle) absorb sucht sich mit erstaunlicher Präzision sogar 
automatisch die zu modifizierenden Commits raus. Sehr praktisch für 
einfache Korrekturen, wie Tippfehler.

Mit topics (evolve extension) bekommst du ziemlich exakt das von dir 
oben beschriebene Szenario sogar automatisiert.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Marcus H. schrieb:
> Selbstverständlich kannst Du auch mit
> ersterem die Historie verändern.

Ist mir neu, das erforsche ich bei Gelegenheit mal.

von Jan (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Stefan ⛄ F. schrieb:
> Bislang wechselte ich auch oft zwischen Windows und Linux, wobei ich
> Windows inzwischen zu benutzen verweigere wegen ungeklärter Fragen rund
> um die DSGVO.
Naja, das ist aber stark von der Linux Distribution abhängig. Bei Ubuntu 
wurde z.B. erst vor kurzem der letzte Amazon Kram entfernt. Das gehört 
einfach in keine Linux Distribution.

Ich habe das Git Problem mit einem LUKS container gelöst. Dort habe ich 
ein privates Repo, was bei einer möglichen Kompromittierung von GitLab 
dennoch sicher sein soll. Man pusht dann einfach das verschüsselte img. 
Nachteil dieser Lösung ist natürlich, dass man den container erst 
mounten muss, um an das Repo zu kommen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.