GIT: Unterschied zwischen den Versionen
(49 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 16: | Zeile 16: | ||
== Branches == | == Branches == | ||
− | Branches anzeigen. Der aktive Branch wird farblich hervorgehoben | + | Branches anzeigen. Der aktive Branch wird farblich hervorgehoben |
git branch | git branch | ||
Einen neuer Branch beginnen | Einen neuer Branch beginnen | ||
Zeile 29: | Zeile 29: | ||
git branch -d "hotfix_1" | git branch -d "hotfix_1" | ||
=== Branches zusammenführen === | === Branches zusammenführen === | ||
− | + | Alle Änderungen commiten, dann | |
git checkout master | git checkout master | ||
git merge "testbranch" | git merge "testbranch" | ||
− | |||
Wenn nicht alle Dateien automatisch zusammengeführt werden können, so gibt es eine Meldung | Wenn nicht alle Dateien automatisch zusammengeführt werden können, so gibt es eine Meldung | ||
: Der Editor Kate zeigt die Konflikte an. Nach durchgeführten Änderungen einen Commit machen | : Der Editor Kate zeigt die Konflikte an. Nach durchgeführten Änderungen einen Commit machen | ||
Zeile 38: | Zeile 37: | ||
git add project/view/file.php | git add project/view/file.php | ||
git commit | git commit | ||
− | |||
− | |||
=== Branch umbenennen === | === Branch umbenennen === | ||
Zeile 48: | Zeile 45: | ||
== Commits == | == Commits == | ||
− | === | + | === Änderungen anzeigen vor dem Commit === |
git status | git status | ||
− | === | + | === Änderungen anzeigen nach dem Commit === |
− | * Eine | + | ==== Anzeigen der letzten Commits ==== |
+ | git log --oneline | ||
+ | ==== Id kopieren und einfügen ==== | ||
+ | Unterschiede anzeigen mit dem Befehl <tt>diff</tt> oder mit Hilfe von z.B. <tt>KDiff3</tt> | ||
+ | git diff <Commit Id> | ||
+ | git difftool <Commit Id> | ||
+ | * Eine Datei in verschiedenen Branches vergleichen | ||
git diff master branch_test datei.php | git diff master branch_test datei.php | ||
− | |||
git difftool master branch_test datei.php | git difftool master branch_test datei.php | ||
+ | |||
=== Dateien ignorieren === | === Dateien ignorieren === | ||
− | + | Im Repo eine Datei <tt>.gitignore</tt> anlegen und Dateien und Verzeichnisse eintragen, die in diesem Repo ignoriert werden sollen. | |
+ | touch .gitignore | ||
+ | Dateien und Verzeichnisse eintragen | ||
+ | # Beispiel | ||
+ | protected/runtime/ | ||
+ | assets | ||
+ | ==== Globale Konfiguraion ==== | ||
+ | * Konfiguration ändern | ||
+ | git config --global core.excludesfile ~/.gitignore_global | ||
+ | * Datei anlegen und bearbeiten | ||
touch ~/.gitignore_global | touch ~/.gitignore_global | ||
− | + | ||
− | + | # ~/.gitignore_global | |
− | * | + | *.log |
− | |||
tmp/ | tmp/ | ||
− | |||
− | |||
− | === | + | === Dateien entfernen === |
− | ==== Änderungen verwerfen ==== | + | Dateien und Verzeichnisse aus dem Repo entfernen |
− | + | git rm -r --cached tmp/* | |
+ | |||
+ | === Änderungen === | ||
+ | ==== Änderungen vor dem Commit verwerfen ==== | ||
Alle Änderungen im Arbeitsverzeichnis '''vor einem Commit''' rückgängig machen | Alle Änderungen im Arbeitsverzeichnis '''vor einem Commit''' rückgängig machen | ||
git checkout HEAD * | git checkout HEAD * | ||
Die Änderungen werden aus der Staging Area entfernt. | Die Änderungen werden aus der Staging Area entfernt. | ||
+ | |||
==== Zu einem früheren Commit zurückkehren ==== | ==== Zu einem früheren Commit zurückkehren ==== | ||
* Zuerst die Commits anzeigen | * Zuerst die Commits anzeigen | ||
git log | git log | ||
− | |||
Zu einem bestimmten Commit zurückkehren und alle späteren Änderungen verwerfen | Zu einem bestimmten Commit zurückkehren und alle späteren Änderungen verwerfen | ||
git reset --hard 8a0181d7b38472a04d90b64dd84a8bc62d138686 | git reset --hard 8a0181d7b38472a04d90b64dd84a8bc62d138686 | ||
Alle Änderungen nach dem Commit <code>8a0181d7b38472a04d90b64dd84a8bc62d138686</code> sind hiermit verworfen. | Alle Änderungen nach dem Commit <code>8a0181d7b38472a04d90b64dd84a8bc62d138686</code> sind hiermit verworfen. | ||
− | |||
===== In der Hierarchie zurückgehen ===== | ===== In der Hierarchie zurückgehen ===== | ||
* Zwei Schritte zurück | * Zwei Schritte zurück | ||
git checkout HEAD~2 | git checkout HEAD~2 | ||
Man befindet sich nun im Zustand eines losgelösten HEAD. | Man befindet sich nun im Zustand eines losgelösten HEAD. | ||
− | + | : Hier kann man einen neuen Branch beginnen | |
− | Hier kann man einen neuen Branch beginnen | ||
git checkout -b <branch_name> | git checkout -b <branch_name> | ||
* Zurück zu einem bestimmten Commit | * Zurück zu einem bestimmten Commit | ||
Zeile 95: | Zeile 105: | ||
=== Letzte Commit Beschreibung ändern === | === Letzte Commit Beschreibung ändern === | ||
git commit --amend | git commit --amend | ||
− | + | ||
− | |||
=== Release numbering === | === Release numbering === | ||
− | Die Versionen des GIT Repositories kann man <tt>tags</tt> verwalten. | + | Die Versionen des GIT Repositories kann man mit Hilfe von <tt>tags</tt> verwalten. |
− | + | Eine Versionsnummer setzt sich aus drei Zahlen zusammen: | |
MAJOR.MINOR.PATCH | MAJOR.MINOR.PATCH | ||
Beispiel: 1.3.7 | Beispiel: 1.3.7 | ||
In diesem Beispiel ist festgelegt: <tt>MAJOR = 1, MINOR = 3, PATCH = 7</tt> | In diesem Beispiel ist festgelegt: <tt>MAJOR = 1, MINOR = 3, PATCH = 7</tt> | ||
− | Nach einem Commit kann man eine neue Versionsnummer vergeben. | + | Nach einem '''Commit''' kann man eine neue Versionsnummer vergeben. |
tag -a 1.3.7 -m "new features" | tag -a 1.3.7 -m "new features" | ||
Anzeige der Versionsnummern | Anzeige der Versionsnummern | ||
Zeile 111: | Zeile 120: | ||
1.3.7-1-gecc4a83 | 1.3.7-1-gecc4a83 | ||
− | Die Ausgabe zeigt, dass zusätzlich zur Versionsnummer beim Commit eine <tt>build number</tt> und der Buchstabe <tt>g</tt> gefolgt von der abgekürzten <tt>commit-Id</tt> angehängt wurde. | + | Die Ausgabe zeigt, dass zusätzlich zur Versionsnummer beim Commit eine <tt>build-number</tt> und der Buchstabe <tt>g</tt> gefolgt von der abgekürzten <tt>commit-Id</tt> angehängt wurde. |
− | + | ||
+ | Vergibt man beim nächsten Commit keine neue Versionsnummer, so wird die <tt>build-number</tt> automatisch um 1 erhöht. | ||
git describe | git describe | ||
1.3.7-2-g0adfd20 | 1.3.7-2-g0adfd20 | ||
+ | Die <tt>build-number</tt> wird also beim '''Commit''' automatisch verändert. Die Versionsnummer bleibt gleich. Sie kann durch den Befehl <tt>git tag -a</tt> geändert werden. | ||
− | === Release numbering - | + | Info: https://stackoverflow.com/questions/37814286/how-to-manage-the-version-number-in-git |
− | Das folgende Script | + | |
− | + | Ich habe jedoch die Versionierung meiner Projekte modifiziert mit Hilfe eines Scripts. | |
− | + | ||
− | + | ==== Release numbering - modified ==== | |
+ | Das folgende Script <tt>commit.sh</tt> ändert die Versionierung nach eigenen Vorstellungen. | ||
if [ $# -gt 0 ] ; then | if [ $# -gt 0 ] ; then | ||
− | + | DESCRIPTION="$*" | |
else | else | ||
− | read -p "Commit | + | read -p "Commit Beschreibung eingeben: " DESCRIPTION |
fi | fi | ||
Zeile 132: | Zeile 144: | ||
done | done | ||
− | |||
echo "------------------" | echo "------------------" | ||
echo $(pwd) | echo $(pwd) | ||
git add . | git add . | ||
− | git commit -m "$ | + | git commit -m "$DESCRIPTION" |
− | NUMBER=$(git describe | tail -n 1) | + | if [ $(git tag | wc -l) -gt 0 ] ; then |
− | + | NUMBER=$(git describe | tail -n 1) | |
+ | NUMBER=$(echo $NUMBER | cut -f 1 -d "-") | ||
− | + | MAJOR=$(echo $NUMBER | cut -f 1 -d ".") | |
− | + | MINOR=$(echo $NUMBER | cut -f 2 -d ".") | |
− | + | PATCH=$(git describe | cut -f 2 -d "-" | cut -f 1 -d "-") | |
− | PATCH=$ | + | else |
+ | MAJOR=1 | ||
+ | MINOR=0 | ||
+ | PATCH=0 | ||
+ | DESCRIPTION="start release numbering" | ||
+ | git tag -a $MAJOR.$MINOR.$PATCH -m "$DESCRIPTION" | ||
+ | fi | ||
− | + | echo "Version: $MAJOR.$MINOR.$PATCH - $DESCRIPTION" | |
− | echo "Version: $MAJOR.$MINOR.$PATCH" | + | |
Zuerst wird ein Commit durchgeführt. | Zuerst wird ein Commit durchgeführt. | ||
− | + | Falls im aktuellen git-repository noch kein git-tag existiert, wird ein tag erzeugt mit <tt>git tag -a 1.0.0 -m "start release numbering"</tt>. | |
− | + | Aus einem vorhanden <tt>git-tag</tt> werden die Bestandteile der Versionsnummer extrahiert. Die automatisch bei jedem Commit um 1 erhöhte <tt>build-number</tt> wird als '''PATCH''' Nummer verwendet. | |
+ | |||
+ | Die so generierte Versionsnummer wird ausgegeben. | ||
=== Commits anzeigen === | === Commits anzeigen === | ||
Zeile 161: | Zeile 181: | ||
git log --pretty=oneline | git log --pretty=oneline | ||
+ | == Repositories == | ||
+ | === Dateien anzeigen === | ||
+ | git ls-files | ||
+ | === Dateien excluden === | ||
+ | Eine Datei <tt>.gitignore</tt> anlegen. Jene Dateien und Verzeichnisse hineinschreiben, die nicht getrackt werden sollen. | ||
+ | === Dateien entfernen === | ||
+ | git rm -r --cached assets/* | ||
+ | Es werden alle Dateien und Unterverzeichnisse aus <tt>/assets</tt> aus dem Repository entfernt. | ||
+ | == Kopfzeile == | ||
== Workflow == | == Workflow == | ||
* Repo erstellen | * Repo erstellen | ||
Zeile 189: | Zeile 218: | ||
git submodule update | git submodule update | ||
Erst dann werden die Änderungen im Include Verzeichnis im Haupt Repo wirksam. | Erst dann werden die Änderungen im Include Verzeichnis im Haupt Repo wirksam. | ||
+ | == Troubles == | ||
+ | * Pfadspezifikation 'xxxxx' stimmt mit keinen Git bekannten Dateien überein | ||
+ | git add . |
Aktuelle Version vom 5. März 2024, 20:06 Uhr
Achtung: Ich bin purer Anfänger in GIT und ich notiere hier meine ersten Versuche.
- Es kann sein, dass ich manches falsch verstehe und daher diese Informationen zum Teil falsch sind.
Config
Die zentrale Konfigurationsdatei ist im Homeverzeichnis
~/.gitconfig
- Branches ohne Pager auflisten
Standardmäßig wird zur Anzeige ein Pager verwendet, z.B. less
- Um das zu verhindern:
git config --global pager.branch false
- Difftool konfigurieren
git config --global difftool.prompt false git config --global diff.tool kdiff3
- Difftool soll keine Backupdateien erzeugen
Standardmäßig erzeugt GIT nach dem Zusammenführen im Arbeitsverzeichnis eine *.orig
Datei. Folgendes Kommando verhindert dies.
git config --global mergetool.keepBackup false
Branches
Branches anzeigen. Der aktive Branch wird farblich hervorgehoben
git branch
Einen neuer Branch beginnen
git checkout -b "testbranch"
Zum neuen Branch wechseln
git checkout "testBranch"
Eine Datei zu einem anderen Branch verschieben
git add . git commit -m "alles fertig" git checkout anderer_branch ./file.php
Einen Branch löschen
git branch -d "hotfix_1"
Branches zusammenführen
Alle Änderungen commiten, dann
git checkout master git merge "testbranch"
Wenn nicht alle Dateien automatisch zusammengeführt werden können, so gibt es eine Meldung
- Der Editor Kate zeigt die Konflikte an. Nach durchgeführten Änderungen einen Commit machen
# Beispiel git add project/view/file.php git commit
Branch umbenennen
Aktueller Branch
git branch -m neuer_Name
Irgendein Branch
git branch -m alter_Name neuer_Name
Commits
Änderungen anzeigen vor dem Commit
git status
Änderungen anzeigen nach dem Commit
Anzeigen der letzten Commits
git log --oneline
Id kopieren und einfügen
Unterschiede anzeigen mit dem Befehl diff oder mit Hilfe von z.B. KDiff3
git diff <Commit Id> git difftool <Commit Id>
- Eine Datei in verschiedenen Branches vergleichen
git diff master branch_test datei.php git difftool master branch_test datei.php
Dateien ignorieren
Im Repo eine Datei .gitignore anlegen und Dateien und Verzeichnisse eintragen, die in diesem Repo ignoriert werden sollen.
touch .gitignore
Dateien und Verzeichnisse eintragen
# Beispiel protected/runtime/ assets
Globale Konfiguraion
- Konfiguration ändern
git config --global core.excludesfile ~/.gitignore_global
- Datei anlegen und bearbeiten
touch ~/.gitignore_global
# ~/.gitignore_global *.log tmp/
Dateien entfernen
Dateien und Verzeichnisse aus dem Repo entfernen
git rm -r --cached tmp/*
Änderungen
Änderungen vor dem Commit verwerfen
Alle Änderungen im Arbeitsverzeichnis vor einem Commit rückgängig machen
git checkout HEAD *
Die Änderungen werden aus der Staging Area entfernt.
Zu einem früheren Commit zurückkehren
- Zuerst die Commits anzeigen
git log
Zu einem bestimmten Commit zurückkehren und alle späteren Änderungen verwerfen
git reset --hard 8a0181d7b38472a04d90b64dd84a8bc62d138686
Alle Änderungen nach dem Commit 8a0181d7b38472a04d90b64dd84a8bc62d138686
sind hiermit verworfen.
In der Hierarchie zurückgehen
- Zwei Schritte zurück
git checkout HEAD~2
Man befindet sich nun im Zustand eines losgelösten HEAD.
- Hier kann man einen neuen Branch beginnen
git checkout -b <branch_name>
- Zurück zu einem bestimmten Commit
Zuerst den Hash Code des Commits ermitteln
git log
Im folgenden Beispiel wird zu diesem Commit gewechselt und zugleich ein neuer Branch erzeugt
git checkout -b <branch_name> b62c8bd940c04b758ceb0583aec84479ddc56a8b
Letzte Commit Beschreibung ändern
git commit --amend
Release numbering
Die Versionen des GIT Repositories kann man mit Hilfe von tags verwalten.
Eine Versionsnummer setzt sich aus drei Zahlen zusammen:
MAJOR.MINOR.PATCH Beispiel: 1.3.7
In diesem Beispiel ist festgelegt: MAJOR = 1, MINOR = 3, PATCH = 7
Nach einem Commit kann man eine neue Versionsnummer vergeben.
tag -a 1.3.7 -m "new features"
Anzeige der Versionsnummern
git describe
1.3.7-1-gecc4a83
Die Ausgabe zeigt, dass zusätzlich zur Versionsnummer beim Commit eine build-number und der Buchstabe g gefolgt von der abgekürzten commit-Id angehängt wurde.
Vergibt man beim nächsten Commit keine neue Versionsnummer, so wird die build-number automatisch um 1 erhöht.
git describe
1.3.7-2-g0adfd20
Die build-number wird also beim Commit automatisch verändert. Die Versionsnummer bleibt gleich. Sie kann durch den Befehl git tag -a geändert werden.
Info: https://stackoverflow.com/questions/37814286/how-to-manage-the-version-number-in-git
Ich habe jedoch die Versionierung meiner Projekte modifiziert mit Hilfe eines Scripts.
Release numbering - modified
Das folgende Script commit.sh ändert die Versionierung nach eigenen Vorstellungen.
if [ $# -gt 0 ] ; then DESCRIPTION="$*" else read -p "Commit Beschreibung eingeben: " DESCRIPTION fi while [ ! -d .git ] ; do cd .. done echo "------------------" echo $(pwd) git add . git commit -m "$DESCRIPTION" if [ $(git tag | wc -l) -gt 0 ] ; then NUMBER=$(git describe | tail -n 1) NUMBER=$(echo $NUMBER | cut -f 1 -d "-") MAJOR=$(echo $NUMBER | cut -f 1 -d ".") MINOR=$(echo $NUMBER | cut -f 2 -d ".") PATCH=$(git describe | cut -f 2 -d "-" | cut -f 1 -d "-") else MAJOR=1 MINOR=0 PATCH=0 DESCRIPTION="start release numbering" git tag -a $MAJOR.$MINOR.$PATCH -m "$DESCRIPTION" fi echo "Version: $MAJOR.$MINOR.$PATCH - $DESCRIPTION"
Zuerst wird ein Commit durchgeführt.
Falls im aktuellen git-repository noch kein git-tag existiert, wird ein tag erzeugt mit git tag -a 1.0.0 -m "start release numbering".
Aus einem vorhanden git-tag werden die Bestandteile der Versionsnummer extrahiert. Die automatisch bei jedem Commit um 1 erhöhte build-number wird als PATCH Nummer verwendet.
Die so generierte Versionsnummer wird ausgegeben.
Commits anzeigen
- Normale LOG Ansicht
git log
- Eine Zeile pro Commit
git log --pretty=oneline
Repositories
Dateien anzeigen
git ls-files
Dateien excluden
Eine Datei .gitignore anlegen. Jene Dateien und Verzeichnisse hineinschreiben, die nicht getrackt werden sollen.
Dateien entfernen
git rm -r --cached assets/*
Es werden alle Dateien und Unterverzeichnisse aus /assets aus dem Repository entfernt.
Kopfzeile
Workflow
- Repo erstellen
git init
- Dateien zum Repo hinzufügen
git add .
- Commit
Nach Änderungen an Dateien, diese zum Repo hinzufügen
git add . git commit -m "Kommentar"
Submodules
Ein Verzeichnis mit mehrfach genutzten Bibliotheken kann man als Submodul zu einem Repo hinzufügen.
- Ich habe mich vorerst entschieden, meine Projekte ohne Submodules zu organisieren. Ich verwalte die gemeinsam genutzten Bibliotheken in einem eigenen GIT Repo. Um die Synchronisation kümmere ich mich manuell - ohne Verwendung von Submodules.
Include Repo anlegen
cd /srv/www/include git init git add .
Include Repo einbinden in das HauptRepo
cd /srv/www/htdocs/project mkdir includefiles git submodule add ./includefiles cd ./includefiles git add .
Arbeiten mit Submodules
- Alle GIT Befehle im Submodul Verzeichnis beziehen sich auf das Submodul.
- Nach einem Commit oder Branchwechsel im Projekt Repo muss das Submodul upgedatet werden.
git submodule update
Erst dann werden die Änderungen im Include Verzeichnis im Haupt Repo wirksam.
Troubles
- Pfadspezifikation 'xxxxx' stimmt mit keinen Git bekannten Dateien überein
git add .