Welche selfhosted Softwareentwicklungsplattform mit git-Server?

ElliotAlderson schrieb:
Schon klar, aber warum ist ihm das so wichtig?
Schrieb er doch im Posting #7

Ich würde noch hinzufügen, das man nicht auf eine funktionstüchtige Internetverbindung angewiesen ist, wenn man es auf 'nem heimischen Device laufen lässt.
 
@ElliotAlderson Und warum sollte das so sein?

In Git hat imo alles was zu suchen was von Versionierung profitiert
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: netzgestaltung, konkretor und BeBur
ElliotAlderson schrieb:
Sowas hat nichts im GIT zu suchen.
Wäre schön, wenn Leute nicht nur einfach Sprüche raushauen würden, sondern diese auch mit Begründungen unterfüttern würden.
Weil so ist der Beitrag relativ witzlos und wirkt ein bisschen wie "Ich haue mal was Pseudoschlaues raus".
 
  • Gefällt mir
Reaktionen: konkretor und HtOW
Vielleicht schreibt er ja auch sein Tagebuch in Markdown und packt es in git …

Lasst die Leute doch machen was sie wollen, so lange sie niemandem damit schaden. Ich bspw betreibe ein K8s Cluster für eine Homepage. Macht keinen Sinn. Ist mehr Hobby weil ich beruflich immer weniger an der Technik dran bin.
 
git hat nichts mit Zugriffsberechtigungen zutun. Es bietet einfach nur Versionierung. Mein NAS bietet ebenfalls versionierte Dateien, sollte ich deswegen darauf auch nichts privates speichern?
 
  • Gefällt mir
Reaktionen: netzgestaltung, konkretor, Alter_Falter und eine weitere Person
ElliotAlderson schrieb:
dass private Dinge nichts in GIT verloren haben.
Völlig egal! Wenn ich Zuhause meine Skirpte verwalte will ich nicht jedesmal irgendwelche env Datein oder sonstige Configs/Zertifikate usw einfügen.

Deswegen hostet man ja manchmal sein eigenes Git, online darf sowas natürlich niemals verfügbar sein.

Da kann alles ohne im Git bleiben und erleichtert nur die Arbeit.
 
ElliotAlderson schrieb:
Passwörter und Zugänge haben in solchen Dingen nichts zu suchen
Von Passwörtern war nirgends die Rede.
Aber selbst wenn. In dem von Dir verlinkten Artikel steht was von:
Source code repositories are meant to be shared, with your teammates, your company, or possibly with the entire world (as is the case for open source software).
Nur ist es halt so, das er das Repository ja offenbar alleine nutzt. Und ja, er will das nicht mit Companys sharen genau deswegen ja das selfhosted.

Ob das trotzdem eine gute Idee ist das zu machen, darüber kann man sicher streiten. Aber so argumentierst Du halt ins Leere. Und das ist dann halt wenig zielführend.

ElliotAlderson schrieb:
Und wenn er sich irgendwann dazu entscheidet, mit anderen zu arbeiten?
Ja. Wenn.
Und dann kann man immer noch mal neu überlegen. Er ist sich ja ganz offenbar der Problematik bewusst.

Es kauft sich ja auch niemand vorsorglich ein Kleintransporter statt einem PKW, weil es könnte sich ja eventuell, vielleicht, irgendwann mal was verändern, so das man plötzlich auf 'nen Kleintransporter angewiesen ist.
Merkst selbst, oder?
 
ElliotAlderson schrieb:
@marcel. niemand hindert ihn an irgendwas. Ich mache nur darauf Aufmerksam, dass private Dinge nichts in GIT verloren haben. Was er letztendlich macht, ist sein Bier.
Du hast im Prinzip einen guten Punkt. Ich zumindest denke bei 'privaten daten' nicht an passwörter aka secrets aka credentials, sondern sehe das als getrennte Punkte - meine Wohnung ist privat, aber sie ist nicht geheim. Bei den zwei Links von dir geht es um andere Anwendungsfälle (Vermischung von Code und secrets im selben Repo), aber ich stimme absolut zu, dass man für passwörter dedizierte Software einsetzen sollte und nicht was eigenes ausrollen sollte.
Ich bin überrascht, wie viele das hier wegdiskutieren wollen.
 
  • Gefällt mir
Reaktionen: ElliotAlderson
BeBur schrieb:
Ich bin überrascht, wie viele das hier wegdiskutieren wollen.
Das Problem ist, das er sein Punkt nicht gut führt.

Das fängt schon allein damit an, das der Threadersteller überhaupt nichts von Passwörtern etc. gesagt hat. Insofern ist das zunächst einmal ein Strohmann.

BeBur schrieb:
Ich zumindest denke bei 'privaten daten' nicht an passwörter aka secrets aka credentials, sondern sehe das als getrennte Punkte
Eben.
 
  • Gefällt mir
Reaktionen: konkretor und KitKat::new()
BeBur schrieb:
Ich möchte noch einen anderen Ansatz in den Raum werfen:
git host (also einfach git auf dem NAS) + git GUI für die Clients, z.B. git extension + Obsidian oder StaticWiki
Das ist eigentlich auch eine gute Idee.

Ich fand die Idee mit dem Webinterface aber insofern gut, weil man auf einem Gerät (z. B. ein Handy) nicht zwingend ein auch einen git Client benötigt. Einfaches kann man ja dann per Hand von der Webseite runterziehen bzw. dort betrachten.

BeBur schrieb:
Kein einheitliches Webinterface, sondern 2 getrennte Programme werden verwendet
Das finde ich, ehrlich gesagt, gar nicht so schlimm. Technisch läuft das bei bspw. Forgejo ja genauso. Da sind auch ein git-, ssh- und ein Webserver also drei Programme drin.

Alter_Falter schrieb:
Ich würde auch eher erstmal schauen warum der Zugriff nicht klappt, am Ende hat das gar nichts mit Forgejo zu tun sondern mit dem Container-Deployment/Host.
Ich bin mir eigentlich recht sicher, dass es an Docker oder der Yaml liegen muss. Zumindest laut den Logs lässt Forgejo hin und wieder diverse Tasks wie Aufräumen usw. laufen. Ich gehe daher davon aus, dass Forgejo an sich läuft, aber -warum auch immer- nicht mehr erreichbar ist. Das zu ergründen ist jetzt aber nicht das Ziel dieses Threads.

ElliotAlderson schrieb:
Und wenn er sich irgendwann dazu entscheidet, mit anderen zu arbeiten?
Um der Diskussion ein wenig Einhalt zu gebieten: Wenn ich mit anderen arbeite, dann wird das nicht auf meinem NAS passieren.
Ich nutze git vor allem, um dort meine Skripte und dot files zu hinterlegen. Mit letzteren meine ich die versteckten (beginnen unter Linux mit einem Punkt -> "dot") Konfigurationsdateien, die teils auch private Daten enthalten. Das kann ich nicht ändern. Es stört mich aber auch nicht, da sie ja in meinen privaten Repos landen, auf die außer mir keiner Zugriff hat.
Von daher gibt es kein Problem.

In einer Gruppe oder Firma ist das natürlich eine andere Sache. Aber das läuft dann nicht mehr auf meinem NAS. Das will ich nicht bei mir hosten.
 
  • Gefällt mir
Reaktionen: BeBur
Krik schrieb:
Ich gehe daher davon aus, dass Forgejo an sich läuft, aber -warum auch immer- nicht mehr erreichbar ist. Das zu ergründen ist jetzt aber nicht das Ziel dieses Threads.
Sollte es vieilleicht aber, sonst ziehst du die nächste Software in nem Docker Container hoch und nach ein paar Monaten gehts wieder nicht mehr...
 
Naja, du sagst, du suchst etwas, das du eigentlich schon hast. Die offensichtliche Antwort "gitea" (weil quasi dasselbe) wird nicht viel helfen, wenn das dann dasselbe technische Problem haben wird.
Ich stand vor ca. 1 Jahr auch vor der Frage, wie ich am besten ein repo auf dem NAS selbst hoste. Web-UI hätte ich gar nicht benötigt, aber am Ende war gitea im Docker viel einfacher einzurichten als alles andere.

ElliotAlderson schrieb:
Und wenn er sich irgendwann dazu entscheidet, mit anderen zu arbeiten? Self Hosted GIT heißt erstmal nichts.

Na dann entfernt er den Kram und macht ein neues Repo auf? Solange einem bewusst ist, was man tut und dass der Verlust der History dann die Konsequenz ist, ist doch alles i.O.
 
Zuletzt bearbeitet:
andy_m4 schrieb:
Das fängt schon allein damit an, das der Threadersteller überhaupt nichts von Passwörtern etc. gesagt hat. Insofern ist das zunächst einmal ein Strohmann.
Passwörter waren nur Beispiele, die sinnbildlich für private Daten stehen, die man nicht mit dritten teilen sollte.
Ich hatte eigentlich erwartet, dass ihr das versteht und ich das nicht weiter ausführen müsste.

Enurian schrieb:
Na dann entfernt er den Kram und macht ein neues Repo auf?
Dann ist die ganze Versionierungshistorie futsch.
 
ElliotAlderson schrieb:
Passwörter waren nur Beispiele, die sinnbildlich für private Daten stehen, die man nicht mit dritten teilen sollte.
So war aber Deine Formulierung nicht.
Und wie Bebur schon sagte, gibt es unterschiedliche Kategorien von privat. Das Wohnungsbeispiel war da ganz passend. Wenn jemand ein Bild meiner Küche hat, dann wird er darauf keine Geheimnisse sehen. Trotzdem möchte ich nicht, das er es hat.
Und solcherlei Daten hat man ja vielleicht auch in seinem Repository. Das können ja beispielsweise auch irgendwelche Domainnamen oder IP-Adressen sein. Beobachtet man hier auch regelmäßig im Forum, das Leute bei ihren Screenshots IP-Adressen schwärzen. Man kann über den Sinn oder Unsinn solcher Dinge sprechen, aber ganz offenbar gibt es ein Bedürfnis danach, solche Daten zu schützen.

Übrigens ist es ja schon ein Wert eines eigenen Home-Servers ansich, nicht bei allem ständig darüber nachdenken zu müssen, ob man die Sachen da speichert oder nicht.

ElliotAlderson schrieb:
Ich hatte eigentlich erwartet, dass ihr das versteht und ich das nicht weiter ausführen müsste.
Sorry, aber Du hast Dich in Deinen Antworten auch nicht gerade mit Ruhm bekleckert. Das fängt schon damit an, das Du nach Dingen fragst, die bereits beantwortet waren.
Ein bisschen mehr Selbstkritik darf es schon sein. ;-)

Krik schrieb:
Das zu ergründen ist jetzt aber nicht das Ziel dieses Threads.
Nichtsdestotrotz ist ein "läuft nicht" allein keine gute Motivation. Weil das kann immer passieren. Normalerweise versucht man Dinge zu reparieren und nicht wegzuschmeißen und durch was Anderes zu ersetzen.
Es sei denn, man ist auch aus anderen Gründen unzufrieden mit der Lösung oder es kommt regelmäßig zu Stabilitätsproblemen.
Und das klang (zumindest bisher) noch nicht so durch und daher sicherlich auch der ein oder andere Einwand.

Zudem ist auch nicht völlig klar, ob es eine Migration (im Sinne von: ich will alles/viel rüber kriegen inkl. der Metadaten) oder nicht.
So wie ich verstanden hatte, wäre Letzteres auch in Ordnung.
 
  • Gefällt mir
Reaktionen: Alter_Falter
Zurück
Oben