Guten Abend, ich arbeite mich ein in Visual Studio Code und habe einen Ordner mit einem Programm, das funktioniert. Jetzt will ich diesen Stand sichern, aber auch weiter daran basteln, also bin ich auf git gekommen und habe ein Repositorium angelegt (im Ordner ist jetzt ein versteckter .git-Ordner). Lokal verstehe ich das einigermaßen - ich erzeuge einen Branch und ändere da. Aber was hat das mit Github auf sich? Werden da meine lokalen Aktivitäten parallel vorgenommen, oder wie spielt das zusammen? Oder sollte ich den Quelltext dann nur noch auf github haben? Oder was sollte wo liegen?
es macht Sinn die Quellen an einem zentralen Punkt zu haben, das kann der öffentliche github Server sein, oder auch einer im eigenen Netz. Gitlab gibt es als Community Version, damit geht das auch. Mit 'git push' werden die Änderungen dann auf den remote geschoben, auf anderen Rechnern oder auch in anderen Arbeitsverzeichnissen kann man dann die Änderungen wieder holen und so an mehreren Orten einfacher synchron halten.
git schrieb: > Lokal verstehe ich das einigermaßen - ich erzeuge einen Branch und > ändere da. Aber was hat das mit Github auf sich? Werden da meine lokalen > Aktivitäten parallel vorgenommen, oder wie spielt das zusammen? Git und Github sind zwei verschiedene Sachen. Git kann ohne Github leben, Github aber nicht ohne Git. Hast du einen Github account? Dein lokales Repo muss mit dem Github Repo verlinkt werden. Mache dich erstmal mit Git vertraut, und lasse Github außen vor. Wenn du git init, git add., git commit -m "XZY" vertraut bist, und dann im zweiten Schritt auch Branches verstehst, würde ich mich mit Github außeinander setzen. Diese Playsiste mir persönlich sehr gut gefallen: https://www.youtube.com/watch?v=cEGIFZDyszA&list=PL6gx4Cwl9DGAKWClAD_iKpNC0bGHxGhcx Gruß,
git schrieb: > Lokal verstehe ich das einigermaßen - ich erzeuge einen Branch und > ändere da. Aber was hat das mit Github auf sich? Werden da meine lokalen > Aktivitäten parallel vorgenommen, oder wie spielt das zusammen? > > Oder sollte ich den Quelltext dann nur noch auf github haben? Oder was > sollte wo liegen? Du hast bei git immer ein lokales Repository. Aber git erlaubt auch die Synchronisation mit remote-Repositiories. Dazu gibt es die git-Kommandos push und pull (und noch ein paar andere). Im einfachsten Fall gibt es einen Server, der dann als origin eingetragen wird. Du arbeitest also weiterhin wie gewohnt in deinem lokalen Repository und nutzt diese Kommandos, um deine Änderungen auf das Remote-Repository zu bringen bzw. von dort Änderungen anderer in dein Repository zu holen. So können dann andere sich dieses Repository klonen, um an den Quellcode zu kommen und ggf. ebenfalls daran zu arbeiten. github ist erst mal einfach eine Plattform, die die Möglichkeit bietet, git-Repositories und noch ein paar andere Sachen drum herum zu hosten. Der Zusammenhang zwischen git und github ist ungefähr so wie der zwischen E-Mail und gmx. Das eine ist das allgemeine System, das andere ein konkreter Anbieter, über den man es nutzen kann.
github hat sich geschickt benannt, ist aber nur einer von vielen kommerziellen Hosting-Anbietern fuer git-Repos.
Rolf M. schrieb: > Der Zusammenhang zwischen git und github ist ungefähr so wie der > zwischen E-Mail und gmx. Das eine ist das allgemeine System, das andere > ein konkreter Anbieter, über den man es nutzen kann. und git auf deinem System ist wie ein lokaler Mail-Server :) lösen dich gedanklich einfach von zentralistischem Denken du kannst so viele lokale Repos vom selben Repo haben - github oder auch gitlab usw. helfen dir nur deine Repos mit anderen gemeinsam zu nutzen - ist aber alles ganz normale git-Technik, github macht nur ein nettes Frontend drauf du kannst dir auch einen lokalen git-Server installieren - brauchst du aber nicht wenn du wenig Erfahrung mit Versionskontrolle oder arbeiten im Team/Open-Source hast werden dir die großen Vorteile von git erst mal gar nicht auffallen - aber später um so mehr
cppbert schrieb: > Rolf M. schrieb: >> Der Zusammenhang zwischen git und github ist ungefähr so wie der >> zwischen E-Mail und gmx. Das eine ist das allgemeine System, das andere >> ein konkreter Anbieter, über den man es nutzen kann. > > und git auf deinem System ist wie ein lokaler Mail-Server :) Ja, so wie es halt früher auf Workstations normal war. Auch heute noch läuft übrigens auf unixoiden Rechnern standardmäßig ein Mail-Server, nur wird der heute meistens nur noch dazu verwendet, Systemnachrichten lokal an den Administrator zu schicken. > du kannst dir auch einen lokalen git-Server installieren - brauchst du > aber nicht Zumindest unter Linux kann man prinzipiell jedes lokale Repository als Server nutzen, sofern der Rechner per ssh erreichbar ist.
Es steht zwar irgendwie auch in den vorherigen Antworten, aber ich möchte das noch einmal deutlich formulieren: git schrieb: > ich arbeite mich ein in Visual Studio Code und habe einen Ordner mit > einem Programm, das funktioniert. Jetzt will ich diesen Stand sichern, > aber auch weiter daran basteln Solange das die einzige Anforderung ist, gibt es überhaupt keinen Grund, irgendetwas mit github oder ähnlichem zu tun. Das ändert sich in dem Moment, in dem mehrere Personen am Projekt beteiligt sind, und sei es nur lesend. Dann ist github eine Lösung, um ein zentrales Repository mit "dem ganzen Zirkus" zu haben: Webinterface, HTTP, SSH auf einem weltweit zugänglichen Server, vielleicht noch mit automatisiertem Deployment oder ähnlichem. Weder ist es die einzige Lösung dieser Art (gitlab wäre die offensichtliche Alternative, kann man sogar selbst hosten), noch ist es immer die beste Lösung, insbesondere wenn man Bedenken hat, den Code aus der Hand zu geben, oder ohnehin schon Infrastruktur wie einen SSH-Server betreibt, zu dem alle Teilnehmer Zugang haben, und Klickibunti keine Anforderung ist. Immer eine gute Quelle für den Anfang: https://git-scm.com/book/en/v2 Kapitel 4. Sofern du nicht der einzige Entwickler bist, kannst du gleich mit Kapitel 5 weitermachen, denn diese Überlegungen muss man dann praktisch zwangsläufig anstellen. Es ist kein Zufall, was danach in Kapitel 6 passiert. Falls man sich von diesen Themen als git-Anfänger eine Zeit lang fernhalten kann, finde ich das gut. Es erleichtert den Einstieg, nicht gleich die volle Komplexität wuppen zu müssen und git erstmal nur lokal einzusetzen. Letztens bin ich über ein Tutorial für node.js gestolpert, das sich ausdrücklich an Anfänger (Programmierung!) gerichtet hat. Es ging damit los, github und heroku einzurichten. Das ist so bescheuert, dass es schon fast wieder clever ist: Zwei Accounts einzurichten ist ein schnelles Erfolgserlebnis. Vielleicht das einzige für längere Zeit ...
GitHub/Gitlab/eigener Git Server macht auch Sinn wenn man alleine arbeitet, aber an mehreren Rechnern oder eine Lib in mehreren Projekten nutzt.
Johannes S. schrieb: > GitHub/Gitlab/eigener Git Server macht auch Sinn wenn man alleine > arbeitet, aber an mehreren Rechnern oder eine Lib in mehreren Projekten > nutzt. Ich habe mir überlegt, dazu etwas zu schreiben, habe es dann wegen Anfängerfrage nicht gemacht. Nicht dass man diesen Prozess nicht sauber in git abbilden kann (ein Patch über git diff/apply), aber wenn man gerade erst anfängt besteht die Gefahr, sich "Feierabend-Commits" anzugewöhnen: "Ich mache jetzt einen Commit auf meinem Desktoprechner, weil ich auf meinem Laptop weiterarbeiten will." Das ist der Tod der Struktur, die man eigentlich haben möchte: Ein Commit ist eine logisch zusammenhängende, gerne eher kleine Einheit von Änderungen oder ein Zustand, den man in Zukunft möglicherweise wiederherstellen möchte. Meine Überzeugung ist, dass je schneller ein Einsteiger ein Gefühl dafür bekommt, was ein guter Commit ist, desto leichter fällt das Erlernen der diversen Features von git. Der Bedarf kommt dann nämlich ganz von alleine, wenn man "ganz normal" arbeitet und sich zu geeigneten Zeitpunkten fragt, wie man das Ergebnis nun git "erklärt". Aber grundsätzlich gebe ich dir Recht: Dieses Szenario kann ein guter Grund sein, git nicht nur lokal zu betreiben.
Meine Erfahrung ist das es eher schlecht ist geänderte Stände ohne commit zu haben. Die Summe zusammenhängender commits ist dann ein abgeschlossener branch.
Ich versuche es auch nochmal zu beantworten: Du hast ja schon gesehen, dass du Branches machen kannst. Eventuell hast du auch schon gesehen, dass es Tools gibt um Änderungen von einem Branch in den anderen zu bekommen. Github ist jetzt einfach nur ein Ort an den du so einen branch pushen kannst um mit anderen zusammenzuarbeiten. Weil es gut dazu passt liefert Gihub auch noch Ticketsystem Wiki, Releases und Co. mit - das hat dann aber wenig mit git selber zu tun. Die absolut beste Beschreibung was git tut habe ich übrigens hier gefunden: https://www.youtube.com/watch?v=1ffBJ4sVUb4
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.