Forum: PC-Programmierung git und github mit VS Code Verständnisfrage


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 git (Gast)


Lesenswert?

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?

von Johannes S. (jojos)


Lesenswert?

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.

: Bearbeitet durch User
von Alex -. (alex796)


Lesenswert?

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ß,

von Rolf M. (rmagnus)


Lesenswert?

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.

von Sven B. (scummos)


Lesenswert?

github hat sich geschickt benannt, ist aber nur einer von vielen 
kommerziellen Hosting-Anbietern fuer git-Repos.

von cppbert (Gast)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von Heiner (Gast)


Lesenswert?

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

von Johannes S. (jojos)


Lesenswert?

GitHub/Gitlab/eigener Git Server macht auch Sinn wenn man alleine 
arbeitet, aber an mehreren Rechnern oder eine Lib in mehreren Projekten 
nutzt.

von Heiner (Gast)


Lesenswert?

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.

von Johannes S. (jojos)


Lesenswert?

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.

von Ant Wort (Gast)


Lesenswert?

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

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.

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