GIT: Unterschied zwischen den Versionen

Aus Mediawiki Ferdinand Gruber
Zur Navigation springen Zur Suche springen
 
(43 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 16: Zeile 16:
  
 
== Branches ==
 
== Branches ==
Branches anzeigen. Der aktive Branch wird farblich hervorgehoben - <tt>openSuse</tt>
+
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 ===
Voraussetzung: Alle Änderungen commiten, dann
+
Alle Änderungen commiten, dann
 
  git checkout master
 
  git checkout master
 
  git merge "testbranch"
 
  git merge "testbranch"
=== Merge Konflikt ===
 
 
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
Merge wiederholen
 
git merge "testbranch
 
  
 
=== Branch umbenennen ===
 
=== Branch umbenennen ===
Zeile 48: Zeile 45:
  
 
== Commits ==
 
== Commits ==
=== Geänderte Dateien anzeigen ===
+
=== Änderungen anzeigen vor dem Commit ===
 
  git status
 
  git status
=== Dateien vergleichen ===
+
=== Änderungen anzeigen nach dem Commit ===
* Eine bestimmte Datei in verschiedenen Branches vergleichen
+
==== 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
Datei in grafischem Difftool anzeigen und bearbeiten (Konfiguration siehe oben)
 
 
  git difftool master branch_test datei.php
 
  git difftool master branch_test datei.php
 +
 
=== Dateien ignorieren ===
 
=== Dateien ignorieren ===
* Eine globale <code>.gitignore</code> Datei anlegen
+
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
* GIT Konfiguration ändern
+
 
  git config --global core.excludesfile ~/.gitignore_global
+
  # ~/.gitignore_global
* Excludefile bearbeiten
+
*.log
# Beispiel
 
 
  tmp/
 
  tmp/
* Dateien aus dem Repo entfernen
 
git rm --cached tmp/*
 
  
=== Zu einem früheren Commit wechseln ===
+
=== Dateien entfernen ===
==== Änderungen verwerfen ====
+
Dateien und Verzeichnisse aus dem Repo entfernen
git restore <Datei>
+
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
===== Commits verwerfen =====
 
 
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
oder
+
 
git commit --amend "neue Beschreibung"
 
 
=== 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.
  
Die Versionsnummer setzt sich aus drei Zahlen zusammen:
+
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.  
Bei jedem folgenden Commit wird die <tt>build-number</tt> dann automatisch um 1 erhöht.
+
 
 +
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 - modifiziert ===
+
Info: https://stackoverflow.com/questions/37814286/how-to-manage-the-version-number-in-git
Das folgende Script <tt>commit.sh</tt> ändert die Versionierung nach eigenen Vorstellungen. Die PATCH Nummer wird automatisch um 1 erhöht.
 
  
Vor dem erstmaligen Aufruf dieses Scripts muss, wie oben beschrieben, mit dem Kommando <tt>git tag -a</tt> eine Versionsnummer festgelegt werden.
+
Ich habe jedoch die Versionierung meiner Projekte modifiziert mit Hilfe eines Scripts.
#!/bin/bash
+
 
# commit.sh
+
==== Release numbering - modified ====
+
Das folgende Script <tt>commit.sh</tt> ändert die Versionierung nach eigenen Vorstellungen.  
 
  if [ $# -gt 0 ] ; then
 
  if [ $# -gt 0 ] ; then
     commitText="$*"
+
     DESCRIPTION="$*"
 
  else
 
  else
     read -p "Commit description: " commitText
+
     read -p "Commit Beschreibung eingeben: " DESCRIPTION
 
  fi
 
  fi
 
   
 
   
Zeile 134: Zeile 144:
 
  done
 
  done
 
   
 
   
projectDir=$(pwd)
 
 
  echo "------------------"
 
  echo "------------------"
 
  echo $(pwd)
 
  echo $(pwd)
 
  git add .
 
  git add .
  git commit -m "$commitText"
+
  git commit -m "$DESCRIPTION"
 
   
 
   
  NUMBER=$(git describe | tail -n 1)
+
  if [ $(git tag | wc -l) -gt 0 ] ;  then
NUMBER=$(echo $NUMBER | cut -f 1 -d "-")
+
    NUMBER=$(git describe | tail -n 1)
 +
    NUMBER=$(echo $NUMBER | cut -f 1 -d "-")
 
   
 
   
MAJOR=$(echo $NUMBER | cut -f 1 -d ".")
+
    MAJOR=$(echo $NUMBER | cut -f 1 -d ".")
MINOR=$(echo $NUMBER | cut -f 2 -d ".")
+
    MINOR=$(echo $NUMBER | cut -f 2 -d ".")
PATCH=$(echo $NUMBER | cut -f 3 -d ".")
+
    PATCH=$(git describe | cut -f 2 -d "-" | cut -f 1 -d "-")
  PATCH=$(expr $PATCH + 1)
+
  else
 +
    MAJOR=1
 +
    MINOR=0
 +
    PATCH=0
 +
    DESCRIPTION="start release numbering"
 +
    git tag -a $MAJOR.$MINOR.$PATCH -m "$DESCRIPTION"
 +
fi
 
   
 
   
git tag -a  $MAJOR.$MINOR.$PATCH -m "$commitText"
+
  echo "Version: $MAJOR.$MINOR.$PATCH - $DESCRIPTION"
  echo "Version: $MAJOR.$MINOR.$PATCH"
+
 
 
Zuerst wird ein Commit durchgeführt.
 
Zuerst wird ein Commit durchgeführt.
  
Dann werden aus dem vorhanden <tt>git-tag</tt> die Bestandteile der Versionsnummer extrahiert. Die PATCH-Nummer wird um 1 erhöht.  
+
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.  
  
Anschließend wird ein neuer <tt>git-tag</tt> erzeugt mit der neuen Versionsnummer als Parameter.
+
Die so generierte Versionsnummer wird ausgegeben.
  
 
=== Commits anzeigen ===
 
=== Commits anzeigen ===
Zeile 163: 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 191: 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 .