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.