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?
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 :-)
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
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.
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.
Melde dich bei bei Gitlab oder Github (oder einem anderen Dienst) an, und verwende private Repositories. Ist besser als jedes private Backup.
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.
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?
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.
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
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.
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 :-)
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.
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.
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.
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)...
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
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.
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.
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
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
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...
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?).
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...
Backup auf USB Stick funktioniert auch prima, wenn man keinen Netzwerkspeicher hat. Einfach vor dem push einstecken.
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.
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.
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.
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.
DPA schrieb: > Ich kenne Eclipse und Netbeans, ich musste mit dem Zeugs schon Webseiten > schreiben. Ist kein Vergleich. Probiere es einfach aus.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
Marcus H. schrieb: > Selbstverständlich kannst Du auch mit > ersterem die Historie verändern. Ist mir neu, das erforsche ich bei Gelegenheit mal.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.