In einem fiktiven Projekt werden Daten erzeugt und ausgewertet. Das Projekt besteht aus folgenden drei Dateien:
generate_data.py
from math import sin, pi
from random import gauss
from numpy import linspace
def noisy_sine_wave(x, period, phase, noise=0.1):
return sin((x + phase) / period * 2 * pi) + gauss(mu=0, sigma=noise)
if __name__ == '__main__':
start = 0
stop = 10
num_points = 100
for x in linspace(start, stop, num_points):
y = noisy_sine_wave(x, period=4.0, phase=3.0)
print x, y
plot_data.plt
set terminal png
set output "sine_wave.png"
plot "sine_wave.dat" using 1:2
generate_and_plot.sh
python generate_data.py >sine_wave.dat
gnuplot plot_data.plt
Zum Ausprobieren: Speichert man die drei Dateien im gleichen Verzeichnis, werden durch Aufruf von
$ bash generate_and_plot.sh
die fiktiven Daten erzeugt und eine grafische Darstellung in die Datei sine_wave.png
geschrieben.
Die oben gezeigten Dateien waren die “alte Version” des Projekts.
Nach einiger Zeit wurde das fiktive Projekt weiterentwickelt und der Inhalt der Dateien ist jetzt dieser (“neue Version”):
generate_data.py
from math import sin, pi
from random import gauss, uniform
from numpy import linspace
def noisy_sine_wave(x, period, rel_phase, noise=0.1):
return sin((x / period + rel_phase) * 2 * pi) + gauss(mu=0, sigma=noise)
if __name__ == '__main__':
start = 0
stop = 10
num_points = 100
T = uniform(3.8, 4.2)
ph = uniform(0.7, 0.8)
slope = uniform(0.5, 0.6)
for x in linspace(start, stop, num_points):
y = noisy_sine_wave(x, period=T, rel_phase=ph)
print x, y + x * slope
plot_data.plt
set terminal png
set output "sine_wave.png"
set xlabel "X values"
set ylabel "Y values"
set grid
set key top left
measured_data = "sine_wave.dat"
# initial guess for the fit parameters
period = 4
phase = 3
f(x) = sin((x + phase) / period * 2 * pi) + a * x
fit f(x) measured_data using 1:2 via phase, period, a
plot measured_data using 1:2 lc "black" title "Measured data", \
f(x) lc "red" title "Best fit"
generate_and_plot.sh
python generate_data.py >sine_wave.dat
gnuplot plot_data.plt
Konfiguriere Git:
$ git config --global user.name <Vorname> <Nachname>
$ git config --global user.email <E-Mail-Adresse>
Diese beiden Angaben braucht Git, um einen Autor in die Commits einzutragen.
$ git config --global color.ui auto
Damit sieht die Ausgabe von Git übersichtlicher aus.
$ git config --global core.editor <Name des Editors>
Hiermit legt man fest, welcher Texteditor von Git gestartet wird, wenn eine Eingabe (z.B. Commitmessage) verlangt ist. Am einfachsten nimmt man gedit
oder nano
. Experten können natürlich auch vim
oder emacs
benutzen.
Die Einstellungen müssten in der Datei ~/.gitconfig
gespeichert sein. Prüfe es mit cat
o.ä. nach!
Das fiktive Projekt ist in einem Git-Repository unter der Adresse https://sus.ziti.uni-heidelberg.de/Lehre/WS1617_Tools/GIT/uebung.git
enthalten.
Klone das Repository und benutze gitk
, git log
und git show
, um es zu betrachten und die Entwicklungsgeschichte nachzuverfolgen.
Mache ein paar Änderungen an den Dateien des Projekts, oder lösche eine Datei, und benutze git status
, git diff
und git checkout
(z.B. mit Option -p
), um die Änderungen wieder rückgängig zu machen und um dich zu vergewissern, dass der ursprüngliche Zustand wiederhergestellt ist.
Stelle die Entwicklungsgeschichte des Projekts nach.
Lege ein neues, leeres Repository an und füge die “alten” Versionen der drei Dateien hinzu.
Im Verlauf der Entwicklung des fiktiven Projekts von der “alten” zur “neuen” Version wurden verschiedene Dinge verändert:
Erzeuge einzelne Commits, die jeweils genau ein neues “Feature” beinhalten.
Benutze git add
und git reset
(evtl. mit der Option -p
), um den Inhalt des Index genau zu kontrollieren. Benutze git diff
und git diff --cached
, um zu prüfen, dass der Index genau die gewünschten Änderungen enthält.
Am Ende, nach einigen Commits, sollen die Dateien mit den “neuen” Versionen übereinstimmen und anhand der Commitmessages soll es möglich sein, nachzuvollziehen, welche Features durch welche Änderungen im Code bewirkt wurden.
Das Skript generate_and_plot.sh
sollte nach jedem Commit fehlerfrei laufen und eine PNG-Grafik erzeugen.
In gitk betrachtet sollte das Repository also zu dem in Aufgabe 2 geklonten vergleichbar sein.
Bildet Zweier- oder Dreiergruppen.
Wählt das in Aufgabe 3 entstandene Repository eines Gruppenmitglieds aus. Die anderen Gruppenmitglieder legen sich einen eigenen Klon davon an.
Alle in der Gruppe machen nun unabhängig voneinander kleine Änderungen in den Skripten (z.B. Zahlenwerte, Farben oder Beschriftungen).
Synchronisiert die Repositories mit git fetch
untereinander und versucht mit git merge
eine Version zu erzeugen, die alle Änderungen enthält. Nutzt gitk --all
um die Beziehungen zwischen den Repositories zu veranschaulichen.
einfache Variante: sprecht euch ab, so dass die einzelnen Änderungen unabhängig voneinander sind, so dass es keine Merge-Konflikte gibt
schwierige Variante: macht jeweils Änderungen an der gleichen Stelle im Code, so dass voraussichtlich Merge-Konflikte entstehen. Versucht, die Konflikte aufzulösen.