Git - die pragmatische Variante

für Kirstin 2017

fsociety

Git installieren

Generell gibt es für jede Plattform einen Git-Client (Windoof, Mac OS, Linux), hier wird mal Linux angeschaut

Mit apt-get install git installieren

Von nun an kannst Du git verwenden bzw. noch einen GUI-Client installieren, wenn Du keine Terminal-Befehle nutzen möchtest

(Die GUI-Clients installieren git meist schon mit)

Neues Repository erstellen

Da eine Webapplikation geplant ist, wechseln wir in das Verzeichnis, welches der Webserver (NGINX bei uns) nutzt, um Dateien auszuliefern. mit cd /var/www/projekte/ und legen hier ein neues Verzeichnis an z.B. mkdir blockly und übergeben es dem wwwdata-user, damit die Root-Rechte auch per FTP greifen mittels chown -cR blockly wwwdata.

(c = permanent, -R rekursiv)

Ins neue Verzeichnis wechseln cd blockly und ein leeres Repository anlegen mit git init

Es legt ein linux-typisches Dotfile an namens .git. Programme wie die Bash wissen, dass sie diese Dateien dann nicht anzeigen

Willst Du sie trotzdem sehen, musst Du das Deinem FTP-Programm sagen (meist eingestellt) oder mit ls -a im Terminal anzeigen

oder bestehendes Repository verwenden

Statt einem neuen Repository anzulegen, kannst Du auch von einem Bestehenden einen Klon anlegen und dort weiterarbeiten (z.B. über einen Branch, später genauer)

Ein Repository von einem lokalen Speicherort klonen über git clone /path/to/the/project/you/want/to/clone oder über eine Remote-Quelle per git clone https://github.com/niggelerk/blockly.git an Deinem Blocklybeispiel. In dem Fall brauchst Du bei Github einfach den Link

clonefromgithub

Remote-Repository mit Deinem lokalem Repository verbinden

In unserem Fall liegt das lokale Repository auf unserem milabor-Server und das Remote-Repository auf github, unter Deinem Account. Von den Begrifflichkeiten her sind natürlich beides Remote-Repository, weil keines auf Deinem Gerät liegt.

Du musst Dich jetzt in das Verzeichnis auf dem Server begeben, in dem Dein .git-File liegt cd /var/www/projekte/blockly und dort dann die beiden Repository miteinander verbinden git remote add origin https://github.com/niggelerk/blockly.git

Eine andere Variante ist, wenn Du keinen eigenen Root-Server hast, kannst Du auch lokal auf Deinem Gerät das Repository einrichten und mit z.B. github verlinken. Du kannst über github die Files auch ausliefern lassen, nicht nur dort lagern.

Damit Du nachher Änderungen pushen kannst, musst Du noch Deinen Nutzernamen und Deine E-Mail hinterlegen per

Wichtiger Hinweis:

Vorteil vom Einbinden per SSH, Du musst nicht jedes Mal Deine Logindaten eingeben. Wenn Du das im Nachhinein ändern willst geht das mit git remote set-url origin git@github.com:niggelerk/blockly.git. Im Moment ist es auf https - kannst Du entscheiden.

Änderungen zum Repository hinzufügen

Wenn Du nun neue Dateien erstellst, Bilder hochlädst, Änderungen machst, Dateien löscht usw. und Du möchtest, dass das auf Deinem entfernten Repository aktualisiert wird, musst Du immer den folgenden Arbeitsablauf durchspielen

Je nach Konfiguration wirst Du noch gefragt ob Deiner Login-Daten bei github (kannst auch hinterlegen)

Arbeitsverzeichnis, Index, HEAD - was soll das?

gitflow

Damit Git Deine ganzen Dateien verwalten kann und weiß wo Änderungen entstanden und was es aktualisieren muss und was nicht, führt es verschiedene "Sichten" auf Deine Daten.

Das Arbeitsverzeichnis ist einfach Dein Ordner, indem Du Dich organisierst, bei Dir nun blockly. Wenn Du etwas mit git add . hinzufügst, landet es im Index. Der Index ist ein großes, einzelnes Binärfile, indem Deine Dateien indiziert sind mit Prüfsummen, ihrem Namen und einem Zeitstempel

Wenn Du nun etwas git commit -m ".....", dann kommts in Dein lokales Repository (vom Index aus).

Somit löst ein git push origin master eine Aktualisierung auf dem Remote-Repository von Deinem lokalen Repository aus. Das wird auch HEAD genannt. In Deinem Fall ist der Head immer der Klon vom Master mit den "commiteten" Änderungen Deiner aktuellen Arbeit

Wenn Du es ganz genau wissen willst, schau mal bei YouTube oder google Dir was zusammen :) Ist nur das, was in meinem HEAD gerade ist.

Branch

branch

Das brauchst Du bei uns nicht machen, kannst Du natürlich aber. Branches sind sinnvoll im Team, wenn unabhängig voneinander neue Features entwickelt werden oder Hotfixes eingespielt werden müssen.

Die geklaute Grafik zeigt es ganz gut. An irgendeinem Punkt des Projektes holst Du Dir den aktuellen Stand vom Projekt mit git checkout -b "meinNeuesFeature". -b legt einen Branch an mit dem Namen der danach kommt. Am besten so nennen, wie die Aufgabe, die der Code in diesem Branch erfüllen soll.

Den Branch siehst jedoch nur Du bei Dir, bis Du irgendwann sagst git push origin "meinNeuesFeature. Origin ist immer das Original, die Quelle, der Master. Muss aber nicht Master heißen.

Damit landet aber nur der Branch im Remote-Repository, er ist noch nicht zum Master hinzugefügt, das wird über den merge gemacht.

(Checkout vs Pull) & Merge

Da Du manchmal Tage oder Wochen an einem neuen Feature arbeitest und währenddessen aus Branches anderer Coder Änderungen auf dem Remote-Master gepushed werden (denglisch ist an der Stelle vielleicht nicht so doof), kann es sein, Du willst diese Änderungen immer auch in Deinem lokalen Branch. Da gibts mehrere Möglichkeiten:

Willst Du Daten aus dem Remote-Repository nach einem Checkout bei Dir anwenden, musst Du von Hand ein git merge machen

Willst Du, dass die Daten aus Deinem lokalen Branch im Remote-Repository in den Master kommen - das Gleiche.

Bla Blubb

Branchen und Mergen brauchst Du bei uns nicht. Du kannst eiskalt auf dem Server die Files ändern und je nach Bedarf zu Deinem GitHub-Repository pushen, um ein Backup zu haben :)

Wenn wir wirklich zeitgleich daran arbeiten wollen, sprechen wir uns ab, Reden und so interne offline Kommunikation solls ja auch geben und wird als Soft-Skill sogar anerkannt : p


Du MUSST den Film Hackers kennen !