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.
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 ...
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
