GIT-Tutorial: Erweitertes Mergen

GIT-Tutorial: Übersicht

Ausgangspunkt

Wir verwenden das Repository aus der Kapitel GIT-Tutorial: Grundlagen (lokales Repository).

Wenn nicht vohanden, ist es schnell hergestellt:

 BASE=/opt/git/
 sudo mkdir -p $REP
 sudo chmod uog+rwx $REP
 cd $BASE
 git clone git://f-r-e-i.de/backup
 cd backup
 git remote rm origin

Das Repository wird aus dem Netz kopiert "(clone")und dann der Rückbezug zum Depot entfernt ("remote rm"). Ohne das Entfernen wären Branche sichtbar, die wir hier nicht brauchen. Nähreres siehe GIT-Tutorial: Verwenden eines zentralen Repositories.

 gitk

Änderung im Branch "dev"

Unser Backupscript soll dokumentieren, von wann bis wann es gelaufen ist.

Brav nach Konvention wird dies nicht im Produktivzweig master, sondern im Entwickungszweig "dev" geändert:

 cd /opt/git/backup
 git checkout dev
 cat >backup.sh <<'EOS'
#! /bin/bash
CONF=/etc/backup/$HOST.conf
if [ ! -f $CONF ] ; then
  echo "SRC=/home\nTRG=/data/backup" > $CONF
fi
source $CONF
date "+%Y.%m.%sd %H:%M: Starting backup $SRC" >>/var/log/backup.log
cp -a $SRC $TRG
date "+%Y.%m.%sd %H:%M: Finished" >>/var/log/backup.log
EOS

Und ab ins Repository:

 git commit -m "Logging" -a
 git tag -m "V0.3dv Logging" v0.3dv

Die Releasenotes anpassen:

 echo >>releasenotes.txt "V0.3dv: Logging"
 git commit -m "Release notes completed" -a

Neuer Branch "experim"

Einfach nur Kopieren ist nicht der Weisheit letzter Schluss: Dateien bleiben im Backup stehen, wenn sie im Orginal gelöscht werden. Außerdem wird jede Datei immer kopiert, auch wenn sie sich nicht geändert hat. rsync kann das besser als cp.

Für diese neue Entwickung machen wir einen neuen Zweig auf, wobei wir vom Produktivzweig ausgehen:

 git checkout master
 git branch experim
 git checkout experim

Switched to branch 'experim'

Hier die Quellcodeänderung:

 perl -pi -e 's/cp/rsync \$1 --delete'/ backup.sh
 echo "V0.3ex: rsync instead of cp" >>releasenotes.txt 
 git commit -m "rsync instead of cp" -a
 git tag -m "V0.3ex rsync instead of cp" v0.3ex

Stand vor dem Mergen

 git log --graph --pretty=oneline --abbrev-commit --branches

* d999ce7 Release notes completed
* 22e6899 Logging
| * 24861a3 rsync instead of cp
|/
* 96b634d hostspezifischen Konfiguration
* bc515ac Release-Notes für V0.1
* cac8976 /bin/bash statt /bin/sh
* df23146 Backup mittels Kopieren

Graphisch anspruchvoller ist die Ausgabe von gitk:

 gitk --all

Mergen

Der Zweig experim soll jetzt in den Zweig dev übernommen werden:

 git checkout dev
 git merge -v experim

Auto-merging backup.sh
CONFLICT (content): Merge conflict in backup.sh
Auto-merging releasenotes.txt
CONFLICT (content): Merge conflict in releasenotes.txt
Automatic merge failed; fix conflicts and then commit the result.

Konflikt erkennen...

Was ist passiert? Es ist ein Konflikt ist aufgetreten, und zwar in beiden Dateien.

 git status

# On branch dev
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#       both modified:      backup.sh
#       both modified:      releasenotes.txt

Git sagt uns, dass beide Dateien geändert wurden, schauen wir uns die Änderungen an:

 cat backup.sh

#! /bin/bash
CONF=/etc/backup/$HOST.conf
if [ ! -f $CONF ] ; then
  echo "SRC=/home\nTRG=/data/backup" > $CONF
fi
source $CONF
<<<<<<< HEAD
date "+%Y.%m.%sd %H:%M: Starting backup $SRC" >>/var/log/backup.log
cp -a $SRC $TRG
date "+%Y.%m.%sd %H:%M: Finished" >>/var/log/backup.log
=======
rsync $1 --delete -a $SRC $TRG
>>>>>>> experim

GIT hat die Bereiche markiert, die einen Konflikt darstellen: Die beiden Branche dev und experim haben eine gemeinsame Historie bis zum Tag v0.2. Dann wude die letzte Zeile in dev durch die letzten 3 Zeilen ersetzt, in experim durch eine andere Zeile.

 cat releasenotes.txt

V0.1: Backup durch kopieren
V0.2: Nutzen einer hostspezifischen Konfiguration
<<<<<<< HEAD
V0.3dv: Logging
=======
V0.3ex: rsync instead of cp
>>>>>>> experim

...und beheben

GIT kann nicht entscheiden, was korrekt ist. Das müssen wir schon selbst erledigen: Wir entfernen die Markierungen und verschieben die letzte Zeile zwischen die Log-Zeilen:

 cat >backup.sh <<'EOS'
#! /bin/bash
CONF=/etc/backup/$HOST.conf
if [ ! -f $CONF ] ; then
  echo "SRC=/home\nTRG=/data/backup" > $CONF
fi
source $CONF
date "+%Y.%m.%sd %H:%M: Starting backup $SRC" >>/var/log/backup.log
rsync $1 --delete -a $SRC $TRG
date "+%Y.%m.%sd %H:%M: Finished" >>/var/log/backup.log
EOS

Bei den Releasenotes ist es noch einfacher, hier braucht es nur ein Entfernen der Konfliktmarkierungen. Zusätzlich tragen wir gleich die Version V0.3 ein:

 perl -ni -e 'print unless /^(<<|==|>>)/;' releasenotes.txt
 echo "V0.3: Logging and rsync" >>releasenotes.txt

Jetzt bleib uns noch, GIT über das Fertigstellen der Konfliktlösung zu informieren...

 git add backup.sh releasenotes.txt

... und mit einem Commit den Merge abzuschließen:

 git commit -m "Logging and rsync" -a
 git tag -m "Logging and rsync" v0.3
 gitk --all

Zusammenführen aller Branche

Die Version in dev hat sich bewährt, daher soll sie jetzt für alle 3 Zweige gelten: Wir mergen dev und experim nach master:

 git checkout master
 git merge dev experim

Fast-forwarding to: dev
Already up-to-date with experim
Merge made by octopus.
backup.sh        |    4 +++-
releasenotes.txt |    2 ++
2 files changed, 5 insertions(+), 1 deletions(-)
mode change 100644 => 100755 backup.sh
 gitk --branches