Git und Versionsverwaltungssysteme (VCS)

Git

Software zur Versionsverwaltung für Software-Projekte
arbeitsteilige Softwareprojekte
verschiedene Code-Bestandteile pro Entwickler
automatisierte Zusammenführung

Versionsverwaltungssysteme

prinzipiell ließe sich Git komplett ohne ein Web-Interface oder zentralen Server verwenden
"GitHub" (und auch "GitLab", "Bitbucket", ...) ist ein Versionsverwaltungssystem (VCS) hostet kostenlos die OpenSource-Projekte der Entwickler
reichert den Funktionsumfang von Git auch zusätzlich an
Dank grafischer Darstellung im Browser lässt sich der Entwicklungsprozess von Software-Projekten anschaulich darstellen
Außerdem kann ein Großteil der Features, zum Beispiel das „Forken“ eines Projekts, auch durch einen Mausklick ausgeführt werden und benötigt keinen Kommandozeilen-Befehl mehr
Änderungen von allen Autoren werden gespeichert
über Client-Applikationen für Git, hauptsächlich Kommandozeilen-Tools, können Entwickler ihre Änderungen an einem Projekt zentral einreichen
GitHub stellt diese Änderungen ausführlich auf der zugehörigen Webseite dar.
Außerdem speichert Git jede Version des Software-Projekts
mit Git könnt ihr immer auf die vorherige Version zugreifen
Community-Features wie Repository oder einem Entwickler folgen
Wiki-Funktionen für jedes Projekt
Support-System, um auftretende Probleme bei Nutzern direkt und übersichtlich bearbeiten zu können

Grundlegende Begriffe bzw. Elemente

Repository

kann bei GitHub einfach als „Projekt“ verstanden werden
Dateien für ein Software-Projekt werden in einem Repository abgelegt

Branch

Innerhalb eines Repositories kann es mehrere Versionen einer Software geben. Zum Beispiel eine experimentelle Beta-Version und eine stabile Version für den Produktiv-Einsatz.
Jede Version stellt dabei einen Branch („Ast“) des Repositories dar.

Commit

„Commit“ nennt sich der Vorgang, wenn eine neue Version eines Branches bei der Versionsverwaltung eingereicht wird. Das heißt, nachdem der Entwickler einen Vorgang an einer Software abgeschlossen hat, „committed“ er die Änderungen.

Pull Request

Hat ein Entwickler einen Bug gefixt oder eine neue Funktion eingebaut, möchte er, dass seine Änderung in das ursprüngliche Projekt einfließt. Deswegen stellt er einen „Pull Request“ an den Administrator des jeweiligen Projekts. Dieser kann sich die Änderungen dann ansehen und entscheiden, ob er den Pull durchführen möchte, oder nicht.

Fork

Da alle öffentlichen Git-Projekte unter OpenSource-Lizenz stehen, kann auch jeder einen eigenen Ableger eines Repositories, einen sogenannten „Fork“, starten. Dort kann jeder privat vor sich hin entwickeln und seine Version am Ende wieder dem ursprünglichen Projekt zuführen (Pull Request stellen) – oder aber einfach eine eigenständige Variante verbreiten.

Grundlegende Befehle

Shellbefehle

Shellbefehle im Allgemeinen, um z. B. Ordner anzulegen, Verzeichnisse zu wechseln etc.

Git-spezifische Befehle

git --version

auf dem Rechner installierte Version prüfen

git clone

Projekt wird von GitLab auf lokalen Ordner kopiert (einmalig am Anfang)

git log

= history (schließen mit "q")

git status

= ?

git add Datei

= Änderung einer Datei vormerken (geänderte Datei wird grün)

git add .

= Änderung aller Dateien vormerken (geänderte Datei wird grün)

git reset

= alle vorgemerkten Änderungen/Dateien (git add) wieder entfernen

git reset [FILE]

= bestimmte vorgemerkten Änderungen/Datei (git add) wieder entfernen

git commit

= ?

-m "Erklärung"

= Kommentar zum commit

git merge

= ?

git push

= Änderung auf den Server schieben

git pull

= Aktuelle Version vom Server holen (um damit zu arbeiten)

git diff master [local-file-path]

= Unterschied zu file im Repo anschauen

Grundlegende, wichtige Workflows

Neues Git Repository anlegen

Lokales Verzeichnis anlegen

mkdir ORDNERNAME

Ins neue Verzeichnis wechseln

cd ORDNERNAME

Verzeichnis initialiseren

git init

TBD

touch README.md

TBD

git add README.md

TBD

git commit -m "first commit"

TBD

git remote add origin git@gitlab.i-fabrik.net:sebastian/typo3testpage.git

TBD

git push -u origin master

Lokales Verzeichnis in bestehendes entferntes Git-Repository laden

Voraussetzung(en)

Repository existiert auf GitLab

Zu lokalem Projektordner wechseln

cd BESTEHENDER_ORDNER

Lokales Verzeichnis initialisieren

git init

TBD

git remote add origin git@gitlab.i-fabrik.net:sebastian/typo3testpage.git

Alle Dateien zum INDEX hinzufügen

git add .

Alle Dateien zum HEAD hinzufügen

git commit -m "KOMMENTAR"

Dateien zum entfernten Repository senden

Änderungen sind jetzt im HEAD
nun, Änderungen zum entfernten Repository senden

git push -u origin master

Dateien erzeugen

touch file_A touch file_B touch file_C

Dateien zum Repo hinzufügen und committen

git add file_* git commit -m "version 1"

Repo auf Github erzeugen und Dateien ins remote Repo uploaden

git remote add origin git@github.com:GwenDragon/test.git git push -u origin master

Datei aus lokalem Repo löschen

git rm file_A

lokale Änderung committen und an remote Repo melden

git commit -m "version 2" git push -u origin master

Geänderte Dateien von Lokal zum Repository pushen

1) Änderung einer Datei vormerken

git add DATEINAME

2) Vormerkung überprüfen

git status (vorgemerkte Datei ist grün ansehen)

3) Commit vorbereiten

git commit -m "Erklärung" (Kommentar zum commit)

4) Änderung zum Server übertragen

git push

Neuen "Feature"-Branch erstellen und Änderungen hinzufügen

1) Neuen Branch anlegen

git branch BRANCHNAME

2) Zum neuen Branch wechseln

git checkout

3) Änderungen zum neuen Branch hinzufügen

git push -u origin BRANCHNAME

"Feature"-Branch mit "Master"-Branch mergen

1) Zum Master-Branch wechseln

git checkout master

2) Branch zum Merge vormerken

git merge feature

3) Vormerkung überprüfen