Archiv

Posts Tagged ‘Versionsverwaltung’

GitHub for Windows – oder Git einmal einfach

23. Oktober 2012 4 Kommentare

Die Versionsverwaltung Git wird unter Windows immer noch zurückhalten eingesetzt. Auch wenn man mit Helfern wie der Console 2 vieles einfacher machen kann, so bleibt Git doch ein komplexes Kommandozeilen-Tool. Die grafischen Oberflächen konnten einem meist auch nicht wirklich überzeugen – fehlende Befehle und Beschriftungen wie von Subversion her störten den Arbeitsfluss zu sehr.

Dieses Problem fiel auch GitHub auf. Eine Firma die ihr Geld mit Dienstleistungen rund um Git verdient möchte natürlich überall präsent sein. Da es an einem guten GUI für Windows fehlte, machte man halt selber eines.

 

Installation

GitHub for Windows lässt sich von http://windows.github.com/ herunterladen. Im *.exe ist ein Installer verpackt der Git in einer Sandbox installiert. Damit kann man problemlos Git installieren und braucht sich um sein System keine Gedanken zu machen – dies bleibt bis auf die Desktop-Icons unangetastet.

Idealerweise erzeugt man nebenher einen Account bei GitHub und verbindet sich gleich mit diesem. Dies ist nicht notwendig um die Applikation zu nutzen, man hat so aber gleich alle Einstellungen im Client und muss nichts mehr von Hand anpassen.

 

Klonen leicht gemacht

Wie man erwarten darf wurde die Anwendung sehr gut in GitHub integriert. Schaut man sich nun ein Projekt auf GitHub.com an, sieht man in seinem Browser (Firefox, IE und Chrome) den Knopf [Clone in Windows]:

Ein Klick darauf genügt und GitHub for Windows öffnet sich und klont das gerade ausgewählte Repository auf den Rechner.

 

Neues Repository anlegen

Ein neues Repository kann man genau so einfach anlegen wie eines zu klonen. Man kann entweder den Knopf [add] auf der Übersichtsseite anklicken oder den Ordner der als neues Repository geführt werden soll auf die Anwendung ziehen. Der einfach gehaltene Dialog ermöglicht einem einen Namen und eine Beschreibung zu vergeben. Wählt man die Option „Push to GitHub“ wird auch gleich alles konfiguriert um das Repository auf GitHub zu veröffentlichen.

Neben dem .git Ordner wird in diesem Schritt ebenfalls eine .gitignore und .gitattributes Datei angelegt. So werden automatisch all die temporären und benutzerspezifischen Dateien ausgeschlossen, die man meist nicht veröffentlichen will. (Will man diese Dateien doch drin haben kann man .gitignore selber anpassen.)

 

Änderungen speichern und anschauen

Nachdem man seine Änderungen gemacht hat geht es an den commit. Dazu öffnet man das Repository in GitHub for Windows und sieht auf einen Blick was sich verändert hat:

Nach dem man eine passende Beschreibung eingetragen hat genügt es auf [commit] zu klicken und die Änderungen sind als neue Version gespeichert.

Der gleiche Dialog dient einem auch um die Änderungen zu verfolgen. Dazu wählt man in der rechten Spalte die gewünschte Version und sieht alle veränderten Dateien mit den Anpassungen.

 

Änderungen publizieren

Wer seine Arbeit veröffentlichen will wird auch hier von GitHub for Windows unterstützt. Dazu genügt auf dem Repository ein Klick auf [push to github]. Im Dialog genügt es den Namen zu überprüfen (und bei Bedarf zu ändern) und mit einem weiteren Klick auf [push] wird das Repository zu GitHub hochgeladen:

Hat man dies einmalig gemacht genügt ein Klick auf [sync] um die lokale Arbeitsversion mit dem Repository auf GitHub abzugleichen.

 

Wenn mal etwas schiefläuft

Nicht immer gelingen einem allen Änderungen im ersten Anlauf. GitHub for Windows hat dafür auf der Repository-Seite 2 hilfreichen Funktionen:

  • [Revert commit] erzeugt einem die Gegenaktion zum gemachten Commit. Was man dort gelöscht hatte ist nun wieder drin und was hinzugekommen ist wird entfernt.
  • [Rollback to this commit] verwirft alle Änderungen zurück bis zur ausgewählten Version. Ist dies die letzte Version kann man den letzten Commit nochmals verändern. Andernfalls löscht es alle Änderungen die seit der ausgewählten Version gemacht wurden.

Genügt einem dies nicht kann man über [Tools] / [open a shell here] auf der Kommandozeile auf alle Git-Befehle zurückgreifen.

 

Nicht nur GitHub

Mit GitHub for Windows kann man jedes beliebige Git-Repository verwalten. Da GitHub private Repositories nur gegen Bezahlung anbietet greife ich gerne auf den Service von Bitbucket zurück.
Um das Repository mit Bitbucket zu verknüpfen muss man den Settings-Dialog auf dem Repository öffnen und die URL gemäss den Angaben von Bitbucket einfügen. Von da an gehen alle Aktionen genauso wie sie auch mit GitHub laufen.

 

Fazit

GitHub for Windows ist aus meiner Sicht der derzeit beste Client für Git auf Windows. Die Funktionalität der GUI-Anwendung deckt das ab was man als „normaler“ Anwender mit Git machen will. Soll es doch einmal nicht genügen stehen einem mehrere konfigurierte Konsolen zur Verfügung.

Das problemlose Zusammenspiel mit anderen Hostern wie Bitbucket macht dieses Tool auch für all diejenigen interessant, die nicht mit GitHub arbeiten wollen.

Schlagworte: ,

Von Subversion zu Git migrieren

2. Oktober 2012 Kommentare aus

Der Wechsel von Subversion zu Git für die Versionsverwaltung ist an sich ein einfacher Vorgang. Da das Web aber voller veralteter Anleitungen ist steht man bald einmal in einer Sackgasse. Nachdem es mir auch so ergangen ist habe ich hier meine Lösungsansätze für Git 1.7.9.5 zusammengetragen.

 

History: Übernehmen oder verwerfen?

Die wohl wichtigste Frage bei der Migration dreht sich um die Änderungsgeschichte. Soll jeder einzelne je gemachter Commit übernommen werden? Oder will man nur einen bestimmten Stand migrieren? Bei beiden Ansätzen lassen sich Argumente dafür und dagegen finden. Wichtig ist das man diese Entscheidung überlegt trifft, da ein nachträgliche Änderung mit viel Arbeit verbunden ist.

 

Variante ohne History

Kann man auf die History verzichten ist die Migration sehr einfach. Es genügt den aktuellen Stand im SVN-Repository zu exportieren und damit ein Git-Repository zu initialisieren. Dies kann man sowohl mit grafischen Tools wie TortoiseSVN und GitHub for Windows machen wie auch direkt über die Kommandozeile.

svn export svn+ssh://user@localhost/svn/jgraber
cd jgraber
git init
git add .
git commit -m "init migrated repo"

 

Variante mit History

Wenn die History erhalten bleiben soll hilft git svn. Dies wird bei GitHub for Windows mitgeliefert und ist unter Linux über apt-get installierbar. Als Vorarbeit benötigen wir einen Checkout aus Subversion:

svn co svn+ssh://user@localhost/svn/jgraber
cd jgraber
svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt
cat authors-transform.txt
jgr = Johnny Graber <dev@JGraber.ch>

Zeile 3 erstellt eine Liste mit allen Personen die jemals in dieses Subversion Repository eingecheckt haben. Diese Liste benötigt man um die Usernamen von Subversion in die von Git her bekannten Autoren (im Format Vorname Nachname ) umzuwandeln. Sobald die Datei authors-transform.txt korrekt ausgefüllt ist geht es weiter mit der Migration:

git svn clone svn+ssh://user@localhost/svn/jgraber --no-metadata -A authors-transform.txt --stdlayout ../git_jgraber
cd ../git_jgraber

Dieser Befehl funktioniert nur wenn das Repository dem Standard mit den Verzeichnissen /trunk, /branches und /tags folgt. Hat man einen anderen Aufbau gewählt beendet sich git svn ohne Fehlermeldung. Die Lösung für dieses Problem ist das Weglassen der Option “--stdlayout“.

Branches übernehmen
Durch die bisherigen Aktionen wurde nur der Trunk von SVN in den Master bei Git überführt. Falls man unter SVN Branches verwendete müssen diese nun explizit übernommen werden. Dazu holt man sich erst eine Übersicht über alle Branches und übernimmt diese dann einzeln:

$ git branch -av
  1.0              2ef18cb Release 1.0 bugfixes
* master           e64eda5 litte changes on trunk
  remotes/1.0      2ef18cb Release 1.0 bugfixes
  remotes/tags/1.0 8604640 Release 1.0
  remotes/tags/1.1 9059098 bugfixed version 1.1
  remotes/trunk    e64eda5 litte changes on trunk
git checkout -b <local_branch> remotes/<remote_branch>
git branch -d -r <remote_branch>

Der letzte Befehl entfernt den Verweis auf den ursprünglichen Branch in SVN. Will man nicht mehr zurücksynchronisieren hat der Remote-Branch seinen Zweck erfüllt und kann entfernt werden.

Tags übernehmen
Wie die Branches müssen auch die Tags übernommen werden. Da SVN einem nicht zwingt Tags nur für einzelne Markierungen zu nutzen sollte man erst prüfen ob nicht ein Tag als Branch verwendet wurde. Ist dies der Fall migriert man diesen Tag wie einen Branch.

Sobald man nur noch „richtige“ Tags hat kann man diese Befehle für eine Übernahme nutzen:

$ git branch -av
  1.0              2ef18cb Release 1.0 bugfixes
* master           e64eda5 litte changes on trunk
  remotes/tags/1.0 8604640 Release 1.0
  remotes/tags/1.1 9059098 bugfixed version 1.1
git tag <local_tag> remotes/tags/<remote_tag>
git branch -d -r <remote_tag>

$ git tag
t1.0
t1.1

 

Ab zu GitHub

Als letzten optionalen Schritt kann man das migrierte Repository zu GitHub oder Bitbucket hochladen. Dazu legt man über die Weboberfläche des jeweiligen Anbieters ein neues Repository an. Die URL zu diesem Repository kann man nun dem lokalen hinzufügen und die Daten hochladen:

git remote add origin ssh://git@bitbucket.org/jgraber/
git push -u origin master
git push --tags
git push origin <branch>

 

Fazit

Ein Repository von Subversion nach Git zu migrieren ist gar nicht so schwer. Alles was man dazu braucht ist eine aktuelle Anleitung und eine Arbeitskopie die man auch einmal löschen kann. Sollte jemand einen einfacheren Weg für die Migration kennen würde ich mich über einen Kommentar freuen.

Schlagworte:

Eine bessere Konsole für Git

21. April 2012 Kommentare aus

In letzter Zeit nutze ich auch unter Windows immer öfters Git. Dank dem Projekt Git for Windows braucht man nach dem Download nur den Installationsassistenten durchzuklicken und man kann los legen.

Die mitgelieferte Git-Konsole bietet leider nur wenige Verbesserungen gegenüber dem mit Windows ausgelieferten cmd.exe. Um einen Text zu kopieren und wieder einzufügen sind nach wie vor die gleichen Verrenkungen nötig.

 

Console2 als Alternative

Mit Console2 gibt es eine Alternative zu cmd.exe die sich mit einigen Anpassungen auch sehr gut als Umgebung für Git anbietet. Am einfachsten richtet man sich einen eigenen Tab für Git ein. Dazu kann man unter Edit / Settings den Einstellungsdialog starten und den Punkt Tabs öffnen:

 
Für meine Konsole habe ich diese Werte gesetzt:

Feld Wert
Title: GIT
Icon: C:\Program Files (x86)\Git\etc\git.ico
Shell: C:\Program Files (x86)\Git\bin\sh.exe --login -i

 

Mit diesen Einstellungen kann man mit den gleichen Eingabemöglichkeiten wie von der Git-Konsole her gewöhnt arbeiten. Zusätzlich hat man aber all den Komfort der einem Console2 bietet, wie das einfache kopieren von Text durch markieren oder ein Einfügen über einen Klick aufs Mausrad.

 

Schlagworte:

Github Gist: Code-Schnipsel einfach veröffentlichen

29. November 2011 1 Kommentar

Mir fehlte es für lange Zeit an einer guten und einfachen Möglichkeit um Code-Schnipsel öffentlich zu machen. Für ganze Projekte finde ich die Kombination von Mercurial und Bitbucket sehr gut. Aber um eine einzelne Datei oder gar nur eine Methode publizieren zu können ist diese Lösung zu aufwändig.

Vor kurzem bin ich beim durchstöbern von Github auf Gist gestossen. Über eine sehr einfache Weboberfläche kann man die Schnipsel mit einem Namen versehen und veröffentlichen. Wenn man will kann man noch die Sprache wählen, womit dann auch die Syntaxhervorhebung stimmt.

Um Gist zu nutzen braucht man nur einen Account bei Github. Man muss weder Git installiert haben noch gross darüber Bescheid wissen. Wenn man später einmal ein „richtiges“ Projekt daraus machen möchte steht dem nichts im Weg: Ein Gist ist ein vollwertiges Git-Repository und verfügt damit von Anfang an über eine Historisierung.

Ich finde Gist eine sehr gute Idee und bin gespannt was sich dadurch alles für Möglichkeiten eröffnen.

Schlagworte: , ,

svn export – oder wie man die .svn Verzeichnisse los wird

Wer mit Subversion arbeitet wir sich sicher schon gefragt haben wie man die .svn Verzeichnisse aus allen Unterordner loswerden kann. Dies ist vor allem bei Webseiten ein Thema, wo die ganze Seite mit all ihren Unterverzeichnissen möglichst 1:1 auf den Webserver soll.

In der Regel werden die meisten Leute eine dieser beiden Ansätze verfolgen:

  1. Alle .svn Ordner von Hand löschen
  2. Die .svn Ordner drin lassen und hoffen das es niemand bemerkt

Der erste Ansatz ist aufwendig und wird innert kürzester Zeit für den zweiten Ansatz fallen gelassen. Das sollte man aber nicht tun.

 
Wieso .svn Verzeichnisse nicht ins Web gehören
In den .svn Ordnern liegen sehr viele Daten die man nicht unbedingt über einen Webserver der Öffentlichkeit freigeben möchte. Subversion legt intern eine Kopie aller unter Versionsverwaltung stehenden Dateien an und legt diese im .svn Ordner ab. Kennt man sich ein bisschen mit der Ablagestruktur aus kann man recht einfach den Quellcode einer PHP oder ASP.Net Seite kommen. Vom abkupfern der Funktionalität zum stehlen DB-Passworts ist es dann oft nur ein kleiner Schritt. Die Metadaten von Subversion müssen also auf eine einfache Art entfernt werden.

 
svn export
Subversion hat für diese Aufgabe den Befehl export. Dieser funktioniert fast wie checkout, räumt aber all die .svn Verzeichnisse weg. Die so erhaltene Kopie beinhaltet nichts mehr was auf Subversion schliessen lässt – ein commit der Änderungen ist damit aber auch nicht mehr möglich!

So kann man den export Befehl aufrufen:

svn export https://svn.origo.ethz.ch/ataraxis/ ataraxisExport

Verfügt man bereits über eine lokale Arbeitskopie (mit allen .svn Verzeichnissen), kann man auch diese als Quelle nutzen:

svn export ataraxis ataraxisOhneSvnOrdner

 
Fazit
Mit dem simplen Befehl svn export kann man ohne grossen Aufwand die lästigen .svn Verzeichnisse vor der Veröffentlichung entfernen.

Schlagworte: ,
Follow

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 254 Followern an