Mit Github push & pull

Git und GitHub, wie spielt das zusammen und

wie nutze ich das.

Glen Langer

Contao Stammtisch Berlin (24.07.2016)

Version: 1.2.1 vom 04.08.2016

Quellen

• Online Doku von Git / GitHub
• Erfahrung durch Ausprobieren
• Bücher (die Dinger aus Papier)

Lizenz

Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Deutschland Lizenz.

Über mich

• Contao seit 2.5.8
• PHP ZCE
• Forum: BugBuster
• http://contao.ninja/

Worum geht es?

Die Arbeit mit Git und Github, Branches erstellen, Pull Requests erzeugen, Versionierung, Push und Pull und einiges mehr.

"Stash mal deinen Working-Tree, sonst gibt's einen Conflict, wenn du den Dev-Branch pullst."

Unterschiede SVN <-> GIT

Es gibt Unterschiede die man als Umsteiger von SVN nach Git vielleicht wissen sollte.

⇓

• Subversion hat ein zentrales Repository

• Git lokale Arbeitskopien sind selbst Repositories
• Einigung auf ein zentrales „upstream“ Repository

Subversion
Leere Verzeichnisse werden vollständig aufgezeichnet.

Git
Zeichnet nur Inhalte auf, wodurch leere Verzeichnisse verloren gehen.

Git Installation

⇓

Git für Windows

• http://msysgit.github.com/
• Installiert die Kommandozeilenversion (inklusive eines SSH Clients) als auch die Standard GUI
• SSH Key entweder über Git Bash, Homeverzeichnis, mkdir .ssh ; ...., oder über Git Gui - Hilfe - SSH Schlüssel anzeigen, dort kann auch einer generiert werden. Wird später für GitHub benötigt bzw. Git Server über SSH

Git für Mac

• Ab Mavericks (10.9) einfach im Terminal "git" eintippen, falls nicht installiert erfolgt die Frage zur Installation
• Alternative: http://git-scm.com/download/mac

Git für Linux

$ sudo apt-get install git-all

• Alternative: http://git-scm.com/download/linux
• SSH Key für Git Server über SSH / GitHub:

$ ssh-keygen -t rsa -b 4096

Git Konfiguration

⇓

Deine Identität

$ git config --global user.name "Max Mustermann" 

$ git config --global user.email max@mustermann.de

Ohne '--global' gelten die Angaben nur für das aktuelle Projekt.

Dein Editor

Normalerweise verwendet Git den Standard-Texteditor deines Systems

$ git config --global core.editor emacs

$ git config --global core.editor 
"'C:/Program Files (x86)/Notepad++/notepad++.exe' 
-multiInst -nosession"

Formatierungen

Hier geht es um das Zeilenende Kennzeichen, im Besonderen wenn mit Windows und Linux/Mac gemeinsam gearbeitet wird. Git kann hier automatisch eingreifen.

$ git config --global core.autocrlf true

• konvertiert bei Commit CRLF in LF, und von LF zurück zu CRLF bei einem Checkout (für Windows Nutzer)

$ git config --global core.autocrlf input

• konvertiert bei Commit CRLF in LF, aber nicht in die andere Richtung bei einem Checkout (für Linux/Mac Nutzer)

Etwas Farbe

Um die Lesbarkeit zu erhöhen, werden die Ausgaben eingefärbt

$ git config --global color.diff "auto"
$ git config --global color.status "auto"
$ git config --global color.branch "auto"
$ git config --global color.interactive "auto"
$ git config --global color.ui "true"

Git Aliase

Lange Befehle abkürzen? Kein Problem

$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status

Nutzung dann beispielsweise für 'git status':

git st

Git Aliase

Auch eigene Befehle bauen ist möglich

$ git config --global alias.unstage 'reset HEAD --'
$ git config --global alias.last 'log -1 HEAD'
$ git config --global alias.visual '!gitk'

Statt 'git log -1 HEAD' kann nun ausgeführt werden:

$ git last

Prozessorkerne

Für Computer mit mehreren Prozessorkernen (optional)

$ git config --global pack.threads "0"

Git nimmt dann soviele Threads wie im System zur Verfügung stehen. Achtung: Eventuell Speicherprobleme [1], Git RAM Verbrauch:

(pack.deltaCacheSize + pack.windowMemory) × pack.threads

Notbremse (z.B. bei Shared Hoster):

$ git config --global pack.windowMemory "100m" 
$ git config --global pack.packSizeLimit "100m" 
$ git config --global pack.threads "1"

[1]: Ist dem Autor noch nie passiert, aber gut zu Wissen.

Einstellungen überprüfen

Alle Einstellungen anzeigen, die Git an dieser Stelle (z.B. innerhalb eines Projektes) bekannt sind:

$ git config --list

oder mal schauen in der Datei:

~/.gitconfig

Jetzt seid Ihr dran

Zeit zur Installation und Konfiguration von Git.

Git Repository anlegen

(es gibt mehrere Möglichkeiten, es folgen zwei)

⇓

Verzeichnis als Git Repository initialisieren

In das zu versionierende Verzeichnis wechseln und eingeben:

$ git init

Ein Unterverzeichnis .git wird erzeugt, darin sind alle relevanten Git Repository Daten, also ein Git Repository Grundgerüst.

Zu diesem Zeitpunkt sind noch keine Dateien versioniert. Wie das durchgeführt wird, folgt in den nächsten Folien.

Existierendes Repository klonen

Um das (fremde) GitHub Repository "Spielwiese" von "BugBuster1701" zu klonen, führst Du den folgenden Befehl aus:

$ git clone https://github.com/BugBuster1701/spielwiese.git

Es wird ein Verzeichnis "spielwiese" angelegt und eine Arbeitskopie der letzten Version abgelegt. (checkout)

Soll beim Klonen ein anderes Verzeichnis angelegt werden, kann dies als Parameter mit angegeben werden:

$ git clone https://github.com/BugBuster1701/spielwiese.git meinewiese

Existierendes Repository klonen

Auf eigene Repositories kann über SSH zugegriffen werden, ein klonen sähe dann so aus:

$ git clone git@github.com:BugBuster1701/spielwiese.git

Entsprechende Konfigurationen für den SSH Zugang sind vorher nötig. (Stichwort: Public Key)

Sollte kein SSH Zugang möglich sein, aber ein Proxy existiert, wäre das auch möglich: (Passwort wird benötigt)

$ git clone https://BugBuster1701@github.com/BugBuster1701/spielwiese.git

Lebenszyklus der Dateien

Bevor nun mit dem Repository gearbeitet wird, eine kleine Lehre über die Zustände die eine Datei haben kann, auch Lebenszyklus genannt.

⇓

Lebenszyklus der Dateien

Es gibt dann noch "deleted", Datei wurde dabei ohne Git Befehl gelöscht.

Lebenszyklus Working Dir - Remote Repository

Die wichtigsten Befehle (Beginner)

git status, git add, git commit, git tag

git log, git diff, git rm, git mv

⇓

git status

Gibt den Zustand der Dateien im Working Dir aus:

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git reset HEAD ..." to unstage)

	new file:   stage

Untracked files:
  (use "git add ..." to include in what will be committed)

	neu.txt

git add

Eine neue Datei zur Versionskontrolle hinzufügen bzw. eine geänderte Datei für den nächsten Commit vormerken (Stage)

$ git add .
$ git add --all
$ git add dir/
$ git add <file> 

git commit

Erzeugt einen Änderungseintrag in einem Branch aller Dateien aus dem Stage inklusive Beschreibung.

$ git commit   <-- Editor geht auf für die Beschreibung
$ git commit -m "Beschreibung für diesen Commit"
$ git commit -a -m "Beschreibung für diesen Commit"

Letzteres überspringt die Stage Area und übernimmt alle Änderungen direkt in den Commit.

git tag

Vorhandene Tags anzeigen oder Tags anlegen, um z.B. eine Release Version zu markieren (z.B. 1.0.0).

$ git tag
$ git tag 1.0.0
$ git tag -a 1.0.0 -m "Version 1.0.0"
$ git tag -a 0.5.3 -m "Version 0.5.3 beta" 9fceb02

• alle Tags anzeigen
• neuen einfachen Tag anlegen
• neuen kommentierten Tag anlegen
• nachträglich neuen kommentierten Tag anlegen für Commit Hash

git log

Zeigt die letzten Änderungen (Commits) an. Hier einige wenige Varianten:

$ git log
$ git log -p -2
$ git log -4 --oneline
$ git log -4 --pretty=format:"%h - %an, %ar : %s"
$ git log --all --grep='Hotfix #33'

"git log" ist sehr sehr mächtig, hat haufenweise Optionen. Hilfe mit "git help log" zeigt Manual mit 1300 Zeilen!

Der Output im Einzelnen:

Ausgabe: git log

commit 5bca2e5d64275f13c63def522b2909d7547024b8
Author: Glen <mail@no.name>
Date:   Thu Jun 23 23:41:43 2016 +0200

    im stage

commit 2768012ecfd142a385bea8e11203476a775d6c5f
Author: Glen <mail@no.name>
Date:   Sun Sep 27 00:03:03 2015 +0200

    Test

Hash, Datum, Commit Beschreibung ist hier zu sehen, nicht jedoch welche Dateien es betraf.

Ausgabe: git log -p -2

commit 5bca2e5d64275f13c63def522b2909d7547024b8
Author: Glen <mail@no.name>
Date:   Thu Jun 23 23:41:43 2016 +0200

    im stage

diff --git a/commi b/commi
new file mode 100644
index 0000000..e69de29

commit 2768012ecfd142a385bea8e11203476a775d6c5f
Author: Glen <mail@no.name>
Date:   Sun Sep 27 00:03:03 2015 +0200

    Test

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..86fc8db
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,1 @@
+.buildpath

Option "-p" bedeutet Patch Format, "-2" die letzten zwei Commits.

Ausgabe: git log -4 --oneline

5bca2e5 im stage
2768012 Test
c4e3d80 composer angepasst
41e2e78 extra in composer.json

Kurzer Hash und Commit Nachricht

Ausgabe: git log -4 --pretty=format...

$ git log -4 --pretty=format:"%h - %an, %ar : %s"
5bca2e5 - Glen , 2 hours ago : im stage
2768012 - Glen , 9 months ago : Test
c4e3d80 - Glen , 2 years, 8 months ago : composer angepasst
41e2e78 - Glen , 2 years, 8 months ago : extra in composer.json

Kurzer Hash, Autor Name, relatives Autor Datum und Commit Nachricht

Ausgabe: git log --all --grep...

$ git log --all --grep='Hotfix #33'
commit fc9e6dc4963ae22f6b645b202ade9729800c9375
Author: Glen <mail@no.name>
Date:   Tue Jul 5 11:42:24 2016 +0200

    Hotfix #33, update composer.json

Sucht in allen (--all) Branches in den commit-Nachrichten nach dem Text 'Hotfix #33' und gibt das vollständige Log aus

git diff

Zeigt die Unterschiede in der Patch Notation an zwischen zwei Commits. Hier einige Varianten:

$ git diff <-- alle Änderungen, die nicht im Stage sind
$ git diff --cached <-- alle Änderungen die im Stage sind *1
$ git diff --staged <-- alle Änderungen zw. Stage und lokalem Repo *1
$ git diff <hash> <hash/tag/HEAD> <-- Änderungen zwischen zwei Commits
$ git diff <hash>/HEAD^! <file> <-- Unterschied zum Vorgänger
$ git diff <tag> HEAD >local.patch <-- Patch erzeugen *2

*1: In der Demo testen wo da der Unterschied ist.
(Ergebnis: --staged ist ein Synonym für --cached)

*2: Einspielen mit:

$ git apply local.patch; git commit -m "applied patch"

git rm

Löscht eine Datei aus dem Repository (beim nächsten Commit) und im Normalfall auch gleich aus dem Working Dir

$ git rm <file> <-- entfernt Datei aus dem Repo und Working Dir
$ git rm -f <file> <-- Force wenn Datei geändert im Stage liegt
$ git rm --cached <file> <-- entfernt Datei aus dem Repository, 
  bleibt im Working Dir vorhanden

git mv

Datei verschieben oder umbenennen (mit Commit bestätigen)

$ git mv <file_from> <file_to> 

Kurzform für:

$ mv file_from file_to
$ git rm file_from
$ git add file_to

Verschiebung / Umbenennung verfolgen:

$ git log --summary -M90% | grep -e "^ rename"

Tipp: .gitignore

Nicht alles muss versioniert werden im Projektverzeichnis. Dateien und Verzeichnisse können davon ausgenommen werden.

Dazu wird eine Datei angelegt .gitignore

⇓

Tipp: .gitignore

# Transifex
/.tx/
#for development in vbox
/vendor/
composer.lock
#IDE
.buildpath
.project
.settings/
#Cache
src/cache/largebrowscap_*/largebrowscap.iniparts.*
src/cache/largebrowscap_*/largebrowscap.patterns.*

Tipp: .gitignore

Git ignoriert leere Verzeichnisse, kann aber überredet werden mit einer .gitignore Datei in das entsprechende Verzeichnis:

# Dummy file to make Git create the folder
*
!.gitignore

Demo

Ausprobieren der gezeigten Befehle.

git status, git add, git commit, git tag
git log, git diff, git rm, git mv

Die wichtigsten Befehle (Fortgeschrittene)

git branch, git checkout, git merge

git remote, git push, git fetch, git pull

⇓

git branch

In Git ist ein Branch ein Zeiger auf einen der Commits. Der Standardname eines Git-Branches lautet "master".

$ git branch develop

Legt ein Branch an mit Namen "develop", bzw. erzeugt einen neuen Zeiger mit Namen "develop" der auf den aktuellen Commit zeigt.

git branch

Im Bild sind drei Commits zu sehen, zeitlich von links nach rechts. Die Pfeile der Commits zeigen auf den jeweiligen Vorgänger.

git branch

Über den Zeiger "HEAD" weiß Git, welchen Branch Du momentan verwendest.

git checkout

In einen anderen Branch wechseln, hier nach "develop"

$ git checkout develop
$ git checkout -b develop master <-- Branch anlegen und wechseln 

Dadurch zeigt HEAD nun auf den Branch "develop".

git checkout

Nach einer Dateiänderung mit Commit verschieben sich dann die Zeiger.

git checkout

Wechsel zurück nach Master und Änderung committen, bewirkt ein auseinander laufen der Historie.

git merge

Zusammenführen von Branches, beide haben Änderungen

$ git checkout master
$ git merge develop

git merge (fast forward)

Zusammenführen von Branches, master ohne Änderung

$ git checkout master
$ git merge develop

git merge --no-ff

Zusammenführen von Branches, master ohne Änderung

$ git checkout master
$ git merge --no-ff develop  <-- kein fast forward bitte!

git merge: Konflikt :-(

Hat man an der selben Datei an der selben Stelle in den beiden Branches was geändert, ist der Merge nicht konfliktfrei möglich.

$ git checkout master
$ git merge develop
Auto-merging README
CONFLICT (content): Merge conflict in README
Automatic merge failed; fix conflicts and then commit the result.

Git hat hier keinen 'merge commit' erstellt. Der Prozess wurde gestoppt. In so einen Fall schauen wir uns die Datei mal an:

git merge: Konflikt :-)

<<<<<<< HEAD
Hello World
=======
Hallo Welt
>>>>>>> develop

Für eine Version entscheiden oder mixen, je nach Bedarf. Die Abschnittszeilen mit löschen und speichern.

Anschließend mit 'git add' die Änderung als bereinigt markieren und falls nötig die nächste Konfliktdatei bearbeiten. Zum Schluss dann mit 'git commit' den "merge commit" abschließen.

git merge: Konflikte mit mergetool

Es ist möglich, die Konflikte auch mit graphischen Tools zu lösen. Dafür gibt es das "mergetool" welches man definieren kann. Ist es nicht definiert sieht das so aus:

$ git mergetool

This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
meld opendiff kdiff3 tkdiff xxdiff tortoisemerge gvimdiff diffuse 
diffmerge ecmerge p4merge araxis bc3 codecompare emerge vimdiff

Wird das 'merge' Werkzeug beendet, fragt Git nach, ob der Konflikt gelöst wurde. Bei Antwort 'Ja' wird das Skript diese Datei als gelöst markieren.

git remote

Vorhandene Remote Repositories anzeigen oder Remote Repositories anlegen

$ git remote
$ git remote -v
$ git remote add [shortname] [url]
$ git remote add forkedfrom git://github.com/BugBuster1701/visitors.git
$ git remote rm [shortname]

• alle Remote Repositories anzeigen, nur Kurzform
• ebenso, "-v" Kurzform und hinterlegte URL
• Remote Repository hinzufügen
• Remote Repository hinzufügen, Beispiel
• Remote Repository (Verknüpfung) löschen

git push

Änderungen in ein Remote Repository veröffentlichen, ein nicht existierender Branch wird angelegt

$ git push [remote-name] [branch-name]
$ git push origin master
$ git push --tags origin master
$ git push --tags

• Syntax
• Beispiel, Änderungen vom lokalen Branch "master" veröffentlichen
• ebenso, aber "Tags" mit veröffentlichen
• nur "Tags" veröffentlichen

git push default

Hat man mehrere Branches im lokalen Repository und der push-Befehl soll nur den aktiven Branch übertragen, ohne das man Branch-Parameter angibt, kann man die push.default Option setzen:

$ git config push.default upstream

Bei dem Standardwert matching würden alle lokalen Branches übertragen werden, die einen gleichnamigen Remote Branch besitzen.

git fetch

Importiert Commits vom Remote-Repository in das lokale Repository als Remote-Branches

$ git fetch [remote-name]
$ git fetch [remote-name] [branch-name]

• Fetchen aller Branches aus dem Repository
• Fetchen nur den Branch [branch-name]

Änderungen in origin/master gegenüber dem lokalen master:

$ git log --oneline master..origin/master

Manuell mergen:

$ git merge origin/master

git pull

Fetchen der spezifizierten Remote-Kopie des aktuellen Branches und mergen direkt in die lokale Kopie.

$ git pull [remote-name]

Entspricht:

$ git fetch [remote-name]; git merge [remote-name]/[current-branch]

Nur ein speziellen Branch fetchen und mergen:

$ git pull [remote-name] [remote-branch]

git pull (Beispiel)

$ git checkout master

$ git pull origin

Fetched alle 'origin' Branches und merged den 'master' Branch. Entspricht also:

$ git fetch origin; git merge origin/master

git pull

Die Option '--rebase' kann genutzt werden, um eine lineare History sicherzustellen, indem unnötige Merge-Commits vermieden werden.

$ git pull --rebase [remote-name]

• Statt 'git merge' für die Integration des Remote-Branchs mit dem lokalen Branch zu nutzen, wird 'git rebase' angewendet.

Workflow

Arbeiten mit lokalen und externen Branches die permanent bzw. temporär sind. Git ist im Prinzip ein Baukasten. Es kann jeder selber festlegen, wie das Git Ökosystem seines Projektes auszusehen hat.

⇓

Workflow Branches

Ein Beispiel wie es in den meisten Fällen ausreichend und auch empfohlen wird.

• Permanente origin Branches
  • origin/master
  • origin/develop
• Permanente lokale Branches
  • master
  • develop
• Temporäre lokale Branches
  • hotfix
  • feature

Worflow Übersicht

Vergleich von Workflow Modellen

• Comparing Workflows
  (Centralized, Feature, Gitflow, Forking)
• Der zentralisierte Workflow Teil 1, Teil 2
• Der Feature Branch Workflow Teil 1, Teil 2
• Der Forking-Workflow Teil 1, Teil 2
• Der Gitflow-Workflow Teil 1, Teil 2
• Der Pull Request Workflow Teil 1, Teil 2

Eigener Git Server

Ein eigener Git Server der über SSH zu erreichen ist, kann ganz einfach eingerichtet werden.

In den nachfolgenden Folien wird davon ausgegangen, dass ein Linux PC dafür zur Verfügung steht und öffentliche SSH-Schlüssel der Entwickler für den Login verwendet werden.

⇓

Nutzer anlegen für den Git Server

$ sudo adduser git 
$ su git 
$ cd 
$ mkdir .ssh
$ touch .ssh/authorized_keys 
$ chmod 700 .ssh

In das Unterverzeichnis legen wir nun die öffentlichen SSH-Schlüssel ab von den Entwicklern.

$ cat /tmp/id_rsa.kevin.pub >> ~/.ssh/authorized_keys 
$ cat /tmp/id_rsa.helen.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.james.pub >> ~/.ssh/authorized_keys

Ein Repository anlegen

$ cd /opt/git <- ggf. vorher anlegen, einmalig
$ mkdir project.git
$ cd project.git
$ git --bare init

Damit wird ein Repository ohne ein Arbeitsverzeichnis erzeugt. Das muss dann für jedes neue Projekt auf diese Weise angelegt werden.

Erster Entwickler legt los

"gitserver" sei der Hostname des Servers auf dem wir gerade das Bare-Repository angelegt haben.

# Kevin Jones Computer
$ cd myproject
$ git init
$ vim README
$ git add .
$ git commit -m 'initial commit'
$ git remote add origin git@gitserver:/opt/git/project.git
$ git push origin master

Zweiter Entwickler legt los

Hier kann bereits durch klonen begonnen werden

# Helen Lewis Computer
$ git clone git@gitserver:/opt/git/project.git myfirstproject
$ cd myfirstproject
$ vi README
$ git add .
$ git commit -m 'fix a typo'
$ git push origin master

Eigenen Git Server absichern

Den angelegten Nutzer "git" sollte man einschränken, damit dieser nur für das Repository genutzt werden kann. Dazu bekommt dieser eine eigene Shell von Git:

$ sudo chsh -s /usr/bin/git-shell git

Damit versteht der Nutzer "git" nur noch Git Befehle und bietet keine normale Shell mehr an.

Weitere Befehle (1)

git reset ... <-- lokale Änderungen rückgängig machen, "merge" abbrechen

git stash [pop] ... <-- lokale Änderungen zwischenspeichern und zurückholen

git rebase <branch> <--Historie glätten, Branch verschieben

Weitere Befehle (2)

git blame <file> <-- wer hat was geändert

git archive ... <-- Projektinhalt als Archiv anlegen

git cherry-pick <hash> <-- einzelnen Commit übernehmen

git reflog <-- Historie der Commits der Branch-Referenzen

Weitere Befehle (3)

git submodule ... <-- In einem Projekt ein weiteres Projekt darin einbinden

git subtree... <-- In einem Projekt ein weiteres Projekt importieren

.... vieles mehr, z.B. "Hooks"

Git GUIs

Für Git gibt es sowohl GUIs die Git selber mitbringt als auch von externen Anbietern welche.

Diese gibt es als freie und kostenpflichtige für Windows, Mac und Linux.

Manche davon sind reine Anzeige Tools, andere können auch Git Befehle absetzen.

⇓

Git interne GUIs

• gitk (only browsing)
• git gui (for comitting, too)

Diese GUIs benötigen unter Linux eine X Windows Umgebung bzw. eine gesetzte $DISPLAY Environment Variable.

Hinweis: Unter Ubuntu ist "git gui" ein extra Paket, installierbar mit:

sudo apt-get install git-gui

⇓

Git externe GUIs

• tig : ein text-mode (ncurses) Interface für Git
• SourceTree (Win/Mac)
• GitKraken (Win/Mac/Linux)
• GitHub Desktop (Win/Mac)
• Weitere Git-GUI Clients

Praxis

Ausprobieren der GUIs mit dem Bare-Server?

Oder später mit GitHub?

GitHub

Web-Interface, Wiki und Support-System für Entwickler

GitHub

Hostet kostenlos öffentliche OpenSource-Projekte

Private Projekte kosten, siehe Preismodell

Reichert den Funktionsumfang von Git zusätzlich an
( Web 2.0 Features wie "Folgen" , "Beobachten" und "Stars", Fork, Pull Request (per Mausklick), Wiki , Issue Tracker, ...)

GitHub Fork

Jeder kann von den öffentlichen Git-Projekten einen eigenen Ableger eines Repositories, einen "Fork", starten. Dort kann jeder privat das Projekt weiter entwickeln. Anschließend ist es möglich diese Weiterentwicklung dem ursprünglichen Projekt zurück zuführen (Pull Request einreichen) – oder als eigenständige Variante zu veröffentlichen.

GitHub Pull Request

Möchte ein Entwickler die Weiterentwicklung in das ursprüngliche Projekt einfließen lassen, kann ein "Pull Request" eingereicht werden an den Administrator des jeweiligen Projektes. Dieser sieht sich die Änderungen an und entscheidet, den Pull durchzuführen, oder nicht.

Beachte: Follow-up-Commits

GitHub und SSH

Anmelden auf GitHub, dann:

• Settings -> SSH and GPG Keys
  oder
• Aufruf der URL: https://github.com/settings/ssh
• neuen SSH Key anlegen

GitHub Commit Secret

GitHub reagiert auf Schlüsselwörter gefolgt von der Ticket Nummer in der Commit Nachricht. (erste Zeile)

Schlüsselwörter sind: fix/fixes/fixed, close/closes/closed oder resolve/resolves/resolved

$ git commit -m "Fixed #42, CSS korrigiert"

Schließt das Ticket sobald dieser Commit sich im master Branch befindet.

Praxis

GitHub anschauen und ausprobieren.

GitHub Alternativen

Neben GitHub gibt es noch Bitbucket, ursprünglich für Mercurial entwickelt wurde es später um Git Funktionalität erweitert und gehört zu Atlassian.

Es gibt auch Alternativen zum selber installieren mit mehr oder weniger identischen Funktionen.

Nachfolgend sind einige aufgelistet, es gibt sicherlich noch mehr davon.

⇓

GitHub Alternativen zum Installieren

• GitLab Community Edition (CE), Ubuntu, Debian, CentOS, Raspbian
• GitBucket, Java8 (gitbucket.war), LDAP
• Gogs - Go Git Service; Go; Windows, Linux, Mac, Docker, Vagrant, Binary

Literatur- Linkliste - Offline

• Buch: Git: Dezentrale Versionsverwaltung im Team - Grundlagen und Workflows
  (3., aktualisierte und erweiterte Auflage (29. Oktober 2015))
  Blog dazu: https://kapitel26.github.io/archive
• Git Cheat Sheet - Tower (PDF als ZIP-Download mit verschiedenen Designs)

⇓

Literatur- Linkliste - Online

• Online Buch: ProGIT deutsch, 1st Edition 2009
• Online Buch: ProGIT englisch, 2nd Edition 2014
• Git online interaktiv über Browser: TryGit (en)
• git ready - Lerne Git Commit für Commit
• Youtube: Git Crash-Kurs - Tobias Günther (de, 1h),
  sehr guter und verständlicher Einstieg

Fragen?

Tipp:

Repository Spielwiese / Playground anlegen und einfach alles ausprobieren.

Bonus:

GitHub -> Packagist.org (Composer) Verknüpfung

(wenn noch Zeit ist)

Fertich!

Diese Präsentation wurde erstellt mit

reveal.js-for-Contao

Danke an den Contao-Stammtisch München.