Vorlage:Auschecken

Der Tuxbox Quellcode wird bei Sourceforge bereitgestellt. Dort befinden sich die Hauptentwicklungszweige des Projektes in Form von 5 Git-Repositries

HINWEIS:

Die Struktur der momentan verfügbaren Repositories, entspricht in etwa der Modulstruktur, wie man sie vor Umstellung von CVS auf Git kannte, wobei es noch zu diversen Anpassungen kommen dürfte. Welche Art diese Anpassungen sind, ist noch nicht vollständig geklärt. Weitere Hintergründe dazu im Tuxbox-Forum.

Klonen der Repositories

• Erzeuge ein Verzeichnis tuxbox-cvs und wechsle in dieses Verzeichnis:

mkdir tuxbox-cvs
cd tuxbox-cvs

Klonen

Die Methoden zum Klonen unterscheiden sich je nach Nutzer. Normalerweise wird nur lesender Zugriff auf die Quellen benötigt, wohin gegen Entwickler Schreibrechte für Änderungen zum Upstream benötigen. Eine Erstellung eines Patches ist aber unabhängig davon jederzeit möglich! Der Zugriff für Developer unterschiedet daher in der Art des Zugriffs. Bei Sourceforge wird dies über einen SSH ermöglicht.

Benutzer	Developer
REPLIST="apps boot cdk driver hostapps sandbox" for f in $REPLIST ; do git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f done Dies geht auch über http: REPLIST="apps boot cdk driver hostapps sandbox" for f in $REPLIST ; do git clone http://git.code.sf.net/p/tuxbox-cvs/$f $f done	REPLIST="apps boot cdk driver hostapps sandbox" for f in $REPLIST ; do git clone ssh://[user_name]@git.code.sf.net/p/tuxbox-cvs/$f $f done

Nach dem Klonen befinden sich 5 Repos in ../tuxbox-cvs

Auf einen Branch wechseln

Standardmäßig wird automatisch nach dem Klonen auf den Master-Branch gewechselt. Möchte man aber z.B. schon beim Klonen einen anderen Branch haben, welcher bisher nur im Remote Repository vorhanden ist, wird dieser direkt so geklont (hier am Beispiel des devel-Branches):

#clone the devel-branch
git clone -b devel git://git.code.sf.net/p/tuxbox-cvs/cdk cdk

Oder so natürlich auch nachträglich, wenn der master bereits geklont wurde:

$ git checkout -b devel origin/devel
Branch devel set up to track remote branch devel from origin.
Switched to a new branch 'devel'

Einen bestimmten tag klonen

Um z.B. nur einen absgeschlossenen Enwicklungsstand zu klonen, kann man auch direkt ein Tag klonen (hier als Beispiel 'last_oldmake_head'):

#clone tag 'last_oldmake_head' 
$ git clone -b last_oldmake_head  http://git.code.sf.net/p/tuxbox-cvs/cdk cdk
Cloning into 'cdk'...
remote: Counting objects: 14069, done.
remote: Compressing objects: 100% (3890/3890), done.
remote: Total 14069 (delta 10137), reused 13919 (delta 9989)
Receiving objects: 100% (14069/14069), 5.12 MiB | 1.19 MiB/s, done.
Resolving deltas: 100% (10137/10137), done.
Note: checking out '652adb038c89d4fd21dc62a89867bdae57ae3612'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

Klonen mit Vorbereitung zum Bearbeiten der Sourcen

Wer (intensiv) Änderungen am Quellcode vornehmen möchte, legt üblicherweise einen lokalen Zweig (Branch) an, auf dem man arbeitet. Auch dies kann man vorab schon beim Klonen erledigen und einen lokalen Zweig namens [USERNAME]_local anlegen und darauf wechseln. Der Master-Branch ist zur Bearbeitung prinzipiell Tabu, siehe auch: Development:Git Workflow.

REPLIST="apps boot cdk driver hostapps sandbox"
for f in  $REPLIST ; do
	git clone git://git.code.sf.net/p/tuxbox-cvs/$f $f 
	cd $f
	git checkout -b `logname`_local
	cd ..
done

Nur um es sinnbildlich zu verdeutlichen, entspricht nun dieser lokale Zweig im Kontext zur früheren Arbeitsweise mit CVS als nicht verteiltes VCS, dem frisch ausgecheckteten Stand vom CVS-Server, mit dem man arbeitet. Der Master-Branch schlußfolglich wäre Quasi der CVS-Server, auf dem man für gewöhnlich keinen Schreibzugriff hat.

Abgleichen des lokalen Standes mit dem Remote Repositories

Für alle Repos können diese Scripte zum Updaten verwendet werden.

Einfaches Abgleichen ohne vorhandene lokale Änderungen

Je nachdem, ob man schon einen lokalen Branch mit eigenen Änderungen angelegt hat oder nicht, muss man auch unterschiedlich vorgehen. Die folgenden Beipiele sollen mögliche Wege aufzeigen. Lokal kann das natürlich anders aussehen, aber prinzipiell sollten diese Beispiele die Vorgehensweise verdeutlichen.

ohne lokalen Branch

# this will update all repos in your clone directory
# change to the directory that contains all repositories and execute this script
# ensure that you have changed to branch 'master' !
REPLIST="apps boot cdk driver hostapps"
DIR=`pwd`
GITPULL="git pull --rebase origin master"

#pull all
for f in  $REPLIST ; do
	cd $DIR/$f
	$GITPULL
	cd ..
done

mit lokalen Branch

REPLIST="apps boot cdk driver hostapps"
DIR=`pwd`
GITPULL="git pull --rebase origin master"

#pull all
for f in  $REPLIST ; do
	cd $DIR/$f
	git checkout master
	$GITPULL
	git checkout [dein_branch]
	git rebase master
	cd ..
done

Konflikte beim Abgleichen

Git kann lokale Änderungen in der Regel recht gut mit dem Remote-Stand mergen, jedoch kann es trotzdem zu Konflikten kommen. Diese müssen dann natürlich von Hand aufgelöst werden.

Git kann dafür verschiedene Mergtools verwenden, die man ebenfalls voreinstellen kann. Zu den unterstützten Mergetools zählen unter anderem:

• kdiff3
• tkdiff
• meld
• xxdiff
• emerge
• vimdiff
• gvimdiff
• ecmerge
• opendiff

Empfehlenswert wäre z.B. Kdiff3. Vorausgesetzt das Mergetool ist installiert, kann man dies so einstellen:

$ git config --global merge.tool kdiff3

Abgleichen bei vorhandenen noch nicht eingetragenen lokalen Änderungen

Wenn Änderungen vorhanden sind, die noch nicht comittet wurden, wird sich GIT mit Sicherheit beschweren und verlangen, dass man diese erst comitten soll. Abgeschlossene Änderungen sollte man natürlich comitten, aber wenn es notwendig ist, hilft es auch die Änderungen kurz "zu parken". Hier besteht die Möglichkeit mit git stash, seine Änderungen vorübergehend "wegzulegen" und mit git stash pop wieder einzupflegen. Diese "Parkmethode" ist jedoch nicht für größere Änderungen geeignet.

ohne lokalen Branch

REPLIST="apps boot cdk driver hostapps"
DIR=`pwd`
GITPULL="git pull --rebase origin master"
 
#pull all
for f in  $REPLIST ; do
	cd $DIR/$f
	git stash
	$GITPULL
	git stash pop
	cd ..
done

auf lokalen Branch

REPLIST="apps boot cdk driver hostapps"
DIR=`pwd`
GITPULL="git pull --rebase origin master"
 
#pull all
for f in  $REPLIST ; do
	cd $DIR/$f
	git stash
	git checkout master
	$GITPULL
	git checkout [lokaler_branch]
	git stash pop
	cd ..
done

HINWEIS:

Obwohl es eigentlich keiner Erklärung bedarf, soll aber hier trotzdem darauf hingewiesen werden, dass es nach einem Update in der Regel notwendig ist, ein neues configure durchzuführen!