Unter Git kann man mittels:
git add test.txt
eine Datei dem Repository hinzufügen. Beim nächsten:
git commit
befinden sich die entsprechenden Dateien dann im Repository. Möchte man nun aber eine bestimmte Datei im Commit doch nicht hinzufügen, so geschieht dies mittels:
git reset test.txt
Beim anschließenden Commit wird diese Datei dann nicht mehr berücksichtigt.
Weitere Informationen gibt es unter:
http://stackoverflow.com/questions/348170/undo-git-add-before-commit
Man nehme die Git Repositories A und B:
A
|_.git
|_file01.txt
|_file02.txt
|_file03.txt
B
|_.git
|_Zeugs
|_image01.txt
|_image02.txt
|_image03.txt
Im Verzeichnisbaum sieht das ganze dabei so aus:
*
|_A
|_B
Nun soll der Inhalt des Repositories B im Repository A landen. Wichtig hierbei ist das die History erhalten bleiben soll. Dazu legen wir in Repository A einen Branch an und laden das Repository B in diesen. Im Repository A öffnen wir eine Konsole und geben dort folgendes ein:
git remote add other ../B git fetch other git checkout -b tmpBranch other/master git checkout master git merge tmpBranch git branch -d tmpBranch git remote rm other git push
Sollte es nach dem „merge tmpBranch“ zu Konflikten kommen, so müssen diese gelöst werden und das ganze dann mittels „git commit“ bzw. „git commit -a“ fixiert werden. Danach sieht das Repository dann so aus:
A
|_.git
|_Zeugs
|_file01.txt
|_file02.txt
|_file03.txt
|_image01.txt
|_image02.txt
|_image03.txt
Für Git Neulinge das ganze nochmal ein wenig genauer. Mittels „git remote add other ../B“ wird dem Repository A ein neuer Remote hinzugefügt. Die Daten aus diesem werden dann mittels „git fetch other“ geladen und anschließend werden diese „git checkout -b tmpBranch other/master“ in einen neuen Branch namens „tmpBranch“ gepackt.
Nun machen wir mit „git checkout master“ den Masterbranch wieder zum aktiven Branch und mergen den „tmpBranch“ mittels „git merge tmpBranch“ in den Masterbranch. Danach wird der „tmpBranch“ mittels „git branch -d tmpBranch“ gelöscht und der nicht mehr benötige Remote mittels „git remote rm other“ entfernt.
Nun wird das ganze noch mit „git push“ auf den Remote des Repositories gepusht und fertig ist die Überführung.
Weitere Informationen gibt es unter:
http://de.wikipedia.org/wiki/Git
http://progit.org/book/de/ch3-4.html
http://de.gitready.com/beginner/2009/01/25/branching-and-merging.html
http://stackoverflow.com/questions/1683531/how-to-import-existing-git-repository-into-another
Vor ein paar Tagen gab es einen Artikel darüber wie man den SSH Schlüssel für GitHub unter Ubuntu hinzufügt. Heute gibt es das ganze für Windows. Nach der Installation von TortiseGit starten wir die Git Bash welche im Startmenü zu finden ist. Dort erzeugen wir dann den SSH Schlüssel mittels:
ssh-keygen -t rsa -C ""
Diese Schlüssel fügen wir nun unter GitHub (https://github.com/account/ssh) hinzu. Dazu öffnen wir die Datei id_rsa.pub welche sich im Ordner .ssh befindet. Der .ssh Ordner ist dabei in den Eigenen Dateien zu finden.
Das Problem an dieser Variante ist das damit das auschecken nur in der Git Bash aber nicht direkt in TortiseGit funktioniert, da dieses einen anderes Schlüsselformat nutzt. Um einen Schlüssel im PuTTY Format zu erzeugen muss zuerst die Software PuTTYgen.exe (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) heruntergeladen werden. Nach dem Start der Anwendung sieht das ganze so aus:
Dort drücken wir auf den Button Generate und bewegen die Maus in dem leeren Bereich um Zufallsdaten für die Schlüsselgenerierung zu liefern. Nachdem der Schlüssel erzeugt würde, drücken wir die Buttons Save public key und Save private key um die beiden Schlüssel zu sichern. Der Public Key kann dabei direkt aus der Anwendung in das GitHub Profil kopiert werden.
Beim git clone muss nun nur noch die PuTTY Private Key Datei angeben werden und schon sollte auch hier das auschecken auch hier ohne Probleme funktionieren.
Weitere Informationen gibt es unter:
http://help.github.com/win-set-up-git/
Bei Gerrit handelt es sich um ein Reviewsystem auf Git Basis. Die Software wird unter anderem vom Android Projekt benutzt. Gerrit selbst ist dabei in Java geschrieben. Deshalb sollte dieses natürlich installiert werden:
apt-get install openjdk-6-jre-headless
Nach der Installation von Java legen wir für Gerrit einen extra Benutzer an und wechseln in seinen Kontext:
adduser gerrit su gerrit cd ~gerrit
Im Homeverzeichnis des Nutzers angekommen laden wir das Kompilat von Gerrit herunter und starten den Initialisierungsvorgang:
wget http://gerrit.googlecode.com/files/gerrit-2.2.1.war chmod 744 gerrit-2.2.1.war java -jar gerrit-2.2.1.war init -d review
Das „review“ bezeichnet hierbei das Verzeichnis in welchem Gerrit die entsprechenden Dateien anlegt, welche für den Betrieb der Software benötigt werden.
Im ersten Schritt fragt Gerrit ob der Ordner angelegt und initialisiert werden soll, was wir mit Yes beantworten. Alle anderen Meldungen bestätigen wir mit der Entertaste bis wir zum Punkt „Email Delivery“ kommen. Hier geben wir die Daten für einen SMTP Server ein über welchen Gerrit die Mails verschickt. Bei der Frage nach der „Canonical URL“ sollte die URL eingegeben werden unter der das System später erreichbar sein soll z.B. „http://review.invertika.org“.
Nach der Konfiguration startet Gerrit und ist dann per Browser erreichbar. Nachdem man sich einen Account registriert hat ist man automatisch in der Gruppe „Administrators“. Nun sollte man unter Settings -> SSH Public Keys den entsprechenden Schlüssel hinterlegen. Mittels
ssh -p 29418 nutzername@host
z.B.
ssh -p 29418
kann man nun überprüfen ob der Server den Schlüssel akzeptiert. Das ganze sollte dann so aussehen:
**** Welcome to Gerrit Code Review ****
Hi seeseekey, you have successfully connected over SSH.
Unfortunately, interactive shells are disabled.
To clone a hosted Git repository, use:git clone ssh://:29418/REPOSITORY_NAME.git
Nachdem die grundlegende Konfiguration angelegt ist, kann damit begonnen werden, ein Projekt anzulegen. Dies geschieht allerdings nicht über die Weboberfläche, sondern per SSH:
ssh -p 29418 nutzername@host gerrit create-project -n projektname
z.B.
ssh -p 29418 gerrit create-project -n sandbox
Damit ist das Projekt dann angelegt. Nun muss noch das bestehende Repository in das Gerrit System überführt werden. Dazu wird zuerst das bereits bestehende Repository geclont:
git clone :Invertika/sandbox.git
Dann pushen wir das Repository in das neue Gerrit Projekt:
cd sandbox git remote rm origin git remote add origin ssh://:29418/sandbox.git git push ssh://:29418/sandbox.git HEAD:refs/heads/master
Kommt es beim Push zu der Meldung:
Permission denied (publickey).
muss der entsprechende SSH Schlüssel zu dem Nutzer in Gerrit angetragen werden. Ist die Mailadresse eines Commiters nicht bekannt kann es zu folgendem Fehler kommen:
remote: ERROR: In commit 9228f67aa9113fa73c80f36e81cb5a62bf930c6c remote: ERROR: committer email address manaserv@herse.(none) remote: ERROR: does not match your user account. remote: ERROR: remote: ERROR: The following addresses are currently registered: remote: ERROR: remote: ERROR: remote: ERROR: To register an email address, please visit: remote: ERROR: http://review.invertika.org/#settings,contact
Hier hilft es dem Projekt die entsprechenden Rechte zu geben damit die Identität „gefälscht“ werden darf. Ansonsten kann noch der Fehler:
! [remote rejected] HEAD -> master (prohibited by Gerrit)
auftreten. Auch hier hilft die temporäre Anhebung der Rechte für das jeweilige Projekt, da man normalerweise nicht in den Master Branch schreiben darf (was aber beim ersten Anlegen des Projektes gewollt ist).
Nachdem das Projekt angelegt ist kann man es sich mittels:
git clone ssh://:29418/sandbox.git
auf die Festplatte holen. Möchte man Gerrit neustarten, stoppen oder starten so sieht das wie folgt aus:
review/bin/gerrit.sh restart review/bin/gerrit.sh stop review/bin/gerrit.sh start
Weitere Informationen gibt es unter:
http://code.google.com/p/gerrit/
http://www.rockbox.org/wiki/GerritDemoGuide
http://de.wikipedia.org/wiki/Gerrit_%28Software%29
http://gerrit.googlecode.com/svn/documentation/2.1.5/config-replication.html
http://unethicalblogger.com/2009/12/07/code-review-with-gerrit-a-mostly-visual-guide.html
http://gerrit.googlecode.com/svn-history/r6114/documentation/2.1.7/error-you-are-not-committer.html
Möchte man eine Subversion (SVN) Integration im Visual Studio, so nutzt man in den meisten Fällen AnkhSVN. Möchte man so etwas nun auch für Git, so sollte man sich den Git Sourcecode Provider anschauen welcher auf Codeplex unter http://gitscc.codeplex.com/ zu finden ist. Das AddIn unterstützt dabei Visual Studio 2008 und 2010, ist Open Source und steht unter der Ms-PL.
Weitere Informationen gibt es unter:
http://de.wikipedia.org/wiki/Git
http://de.wikipedia.org/wiki/Visual_Studio
http://de.wikipedia.org/wiki/Apache_Subversion