proggen.org

Tag!
Ich habe nun einige Zeit mit "git" als VCS (Version Control System) gearbeitet, und möchte euch nun ein bisschen Honig ums maul schmieren.

Zuerstmal, was ist GIT ?
Am besten ist hierzu ein Zitat:

man 1 git hat geschrieben:git - the stupid content tracker

Und genau das ist er auch. Er ist ein relativ "dummer" content tracker, also er verfolgt Änderungen an Dateien. Am besten einzusetzen ist er natürlich als Versionskontrollsystem von Softwereprojekten, aber man kann problemlos andere Dateien verfolgen, von denen man "Sinnvoll" diffs erstellen kann. (grob gesagt menschlich lesbare Dateien). Wieso er "dumm" ist, möchte ich später erwähnen.
Git wurde von Linus Torvalds (Name bekannt?) begonnen, heute sind noch viele andere an git's Entwicklung beteiligt. Git wurde geschaffen um die (gigantische) Entwicklung des Linux Kernels in geregelte Bahnen zu bringen.

Wie funktioniert git?
Sagen wir, ihr habt ein Projekt das mit git verwaltet wird. Ihr macht eine Änderung, speichert sie und "commitet" sie dann. "commiten" bedeutet, dass ihr alles was ihr seit dem letzten "commit" geändert habt vom Versionsverwaltungssystem aufgenommen wird. Ihr erstellt dann eine kleine Beschreibung und schon ist die Änderung gespeichert. Das könnt ihr immer wieder machen, bis euch mal einfällt, dass ihr mal in irgendeiner Version irgendeinen Codeschnipsel hattet, den ihr jetzt braucht. Hättet ihr kein VCS, pech gehabt. Änderungen weg. Mit git allerdings kein Problem, einfach die richtige Version auschecken kopieren, in die neue einfügen und passt.

Lokal vs. Netzwerk
Wo werden eure Daten gespeichert? Nun, würdet ihr SVN oder CVS verwenden wäre die Antwort "auf nem Zentralen repository irgendwo im Internet".
Nicht so bei git. Ihr könnt ohne Internetverbindung commiten, Änderungen durchführen und speichern lassen. Kommt ihr wieder ins Netz, könnt ihr eure lokalen Änderungen "pushen", und sie sind dann wieder am Zentralen server.
Ob lokal, oder auf einem Server, ihr habt die Wahl.

Einige features
Hier sind einige nette Features aufgezählt:

• Git ist schnell!! Ihr werdet kaum ein VCS finden, dass git in der geschwindigkeit schlägt. Ob commits, pushs, checkouts oder sonstwas, git ist hurtig.
• "Billige" branches: Ihr könnt problemlos branches (abzweigungen eures Projekts) erstellen, an mehreren branches gleichzeitig arbeiten und dann die änderungen wieder zusammenmischen. Und das ohne erhöhten Speicheraufwand!
• Automatische formattierung von Patches als Mail: habt ihr eine Mailing- Liste, oder sendet ihr eure änderung einfach so gerne per Mail, könnt ihr mit "git format-patch" eine schön formattierte Mail mit den Änderungen erstellen. Ein kleines Beispiel aus meinem jetzigen Projekt, erstellt mit "git format-patch 345d145..fdc4817". Daraus entsteht eine nette kleine Datei namens "0001-aenderungs-nachricht-kopfzeile.patch", die so aussieht:

  Code: Alles auswählen

  From fdc48175486fbb6ced3124af90fb719b69682846 Mon Sep 17 00:00:00 2001
  From: Alexander Korsunsky <fat.lobyte9@gmail.com>
  Date: Thu, 30 Apr 2009 14:32:12 +0200
  Subject: [PATCH] Fixed missing includes
  
  * src/client/control/commands.hpp, src/client/control/notifications.hpp:
     - Fixed build error related to missing include files
  * config.mak:
     - Adapted configuration file for personal needs
  ---
   build/config.mak                     |    2 +-
   src/client/control/commands.hpp      |    2 +-
   src/client/control/notifications.hpp |    4 ++--
   3 files changed, 4 insertions(+), 4 deletions(-)
  
  diff --git a/build/config.mak b/build/config.mak
  index fb2de8a..b1cf148 100644
  --- a/build/config.mak
  +++ b/build/config.mak
  @@ -19,7 +19,7 @@ LIBDIRS :=
   
   # boost library names follow a certain pattern
   BOOST_PREFIX :=
  -BOOST_SUFFIX := -gcc42-mt-1_35
  +BOOST_SUFFIX := -mt
   
   # wxWidgets flags and libraries
   WX_FLAGS := `wx-config --cxxflags`
  diff --git a/src/client/control/commands.hpp b/src/client/control/commands.hpp
  index e073227..272cb04 100644
  --- a/src/client/control/commands.hpp
  +++ b/src/client/control/commands.hpp
  @@ -34,7 +34,7 @@
   #ifndef COMMANDS_HPP
   #define COMMANDS_HPP
   
  -#include <string>
  +#include "bytes.hpp"
   
   namespace nuke_ms
   {
  diff --git a/src/client/control/notifications.hpp b/src/client/control/notifications.hpp
  index 3203fef..13e75f7 100644
  --- a/src/client/control/notifications.hpp
  +++ b/src/client/control/notifications.hpp
  @@ -34,10 +34,10 @@
   #ifndef NOTIFICATIONS_HPP
   #define NOTIFICATIONS_HPP
   
  -#include <string>
  -
   #include <boost/function.hpp>
   
  +#include "bytes.hpp"
  +
   namespace nuke_ms
   {
   namespace control
  -- 
  1.6.2.1
  
  

  Hübsch, nicht wahr? Aber es ist nicht nur Hübsch, ihr könnt solche Patches nun per E-Mail verschicken. Wenn ihr euren mail-client richtig konfiguriert, dann könnt ihr mit "git cherr-pick" die patches aus der Mailbox auslesen und auf euer repository anwenden.
• Nachträgliches editieren von Commits: Vertippt in der lognachricht? Vergessen Datei zu adden? Kompiliert auf einmal nicht? Kein problem: mit git kann man die commits nachträglich noch ändern.
• Jeder commit hat eine eindeutig identifiezierte Nummer. Diese Nummer ist ein SHA- hash der änderungsdatei, das bedeutet keiner kann unbemerkt auf die Idee kommen über nacht das Repository zu ändern.
• Und vieles mehr

User Interface
Git folgt der typischen Unix-philosophie: es besteht aus einem Haufen kleiner Tools, die zwar wenig können das dafür aber gut. Hier sind wir beim punkt "stupid content tracker" angekommen: git tut genau das was ihr sagt. Es hilft euch natürlich und schützt euch vor fehlern. Wenn ihr allerdings wisst was ihr tut, könnt ihr mit git viele schlimme Dinge anstellen.
Das garantiert eine gute erweiterbarkeit: es gibt mittlerweile viele kleine Helfertools, die ihr zusätzlich Installieren könnt. Viele davon sind bereits in eurer Distribution integriert. Meistens wird git aus der Kommandozeile verwendet. Lasst euch davon aber nicht abschrecken! Nach einiger Zeit beherrscht ihr die wichtigsten git kommandos im Schlaf. Zugegeben sind manche befehle etwas länger und kryptischer als bei anderen Versionssystemen, aber auch daran gewöhnt man sich.
Auf Wunsch gibts die Ausgabe auch in Farbe (sehr zu empfehlen), alle Ausgaben länger als eine Konsole kommen automatisch in euren lieblingspager (z.B. less) und auch die Lognachrichten werden mit dem lieblingseditor (z.b. vim) editiert. Wer eine gut funktionierende bash- Autovervollständigung hat (z.B. Debian/Ubuntu Paket bash-completion), hat schon gewonnen.
Optional gibts auch eine GUI, die ich zugegebenermaßen noch nie verwendet habe, die allerdings auch recht nett aussieht: http://www.spearce.org/2007/01/git-gui-screenshots.html

Arbeitsweise
Git wurde ursprünglich für das gigantische Projekt des Linux Kernels entwickelt, ist also darauf ausgerichtet bei bedarf von vielen Leuten verwendet zu werden.
Das funktionert unter anderem durch seinen dezentralen Aufbau: jede Arbeitskopie des Repositories ist ein vollständiges Repository mit allen Dateien und mit der ganzen Entwicklungsgeschichte (der Festplattenverbrauch ist aber trotzdem nur sehr gering).
Jedes neue Feature kann in einem seperaten "Entwicklungszweig" genannt "branch" entwickelt werden, der beim Hauptzweig - dem "master branch" - startet. Wenn das gewünschte Feature fertig ist, wird es dann in den Hauptzweig zurückgemischt, auch "mergen" genannt. Somit bleib der Hauptzweig zu jedem Zeitpunkt funktionsfähig, während in den feature branches durchaus mal experimentiert werden darf.


Dokumention
Bis jetzt ist mir aufgefallen, dass git sehr sehr gut dokumentiert ist. Zu jedem einzelnen git befehl gibt es eine ausführliche Manpage. Es gibt auch zwei tutorials, die ebenfalls als manpage abrufbar sind (man 7 gittutorial, man 7 gittutorial-2).
Auf der git-webseite http://git-scm.com/ sind die manpages als HTML Seiten, und noch viele viele andere Dokumentation zu finden, angefangen vom Crashkurs bis hin zur Entwicklerdokumentation.

Prominte Projekte
Wenn ihr git verwendet, seid ihr nicht alleine auf der Welt. Sehr viele FLOSS Projekte verwenden git als ihr Versionsverwaltungssystem:

• Git (na was sonst...)
• Linux Kernel (ihr wisst schon, das Ding das auf jedem Linux computer dieser Welt läuft...)
• Wine
• GNOME
• VLC
• X.Org

Obwohl das nur beweist, dass git "mainstream software" ist und das nichts über die Qualität aussagen würde... Aber es wird schon einen Grund haben wieso diese Projekte git verwenden.


GIT und SVN
Git schlägt meiner meinung nach SVN um längen. Nichtsdestotrotz gibt es noch genug Projekte da draußen, die mit SVN arbeiten. Mit git-svn kann man SVN repositories als GIT repositories auschecken, daran entwickeln und die Änderungen sogar wieder zurück ins SVN repository übertragen.

Gratis git repository hosting
Es gibt einige Websites, die eure repositories für Lau hosten. Das wären zum Beispiel
GitHub ist eher eine Community um git herum, als dass es einfach nur repos hosten würde
http://repo.or.cz/ ist einfach nur ein großes git repository.
SourceForge sollte nun jeder kennen. Sourceforge hostet seit einiger Zeit auch git repositories.
BerliOS, das bessere Sourceforge. Hostet allerlei OpenSource projekte, bietet viele Services, und das für Lau und in Deutschland.


Gits Problemzonen
Hier möchte ich nun doch ein paar Dinge erwähnen, die mir nicht so gut gefallen.

• Ihr könnt keine leeren Verzeichnise verfolgen Ist, so, tatsache. Das ist ein Problem das auf dem Aufbau einer internen Datei begründet ist. Es gibt ein Workaround, nämlich leere und/oder versteckte Dateien in das Verzeichnis zu legen, aber das ist keine seriöse Sache. Allerdings soll erwähnt sein, dass das kein grundsätzliches Problem ist, es hat sich einfach nur keiner hingesetzt und das erledigt. Hier der Thread auf der Kerneltrap mailing list: http://kerneltrap.org/mailarchive/git/2007/7/17/251902
  Nervt tierisch, wenn ich ehrlich bin
• Nicht so ganz einfach zu bedienen. Git hat viele features ist sehr sehr mächtig, hat aber auch entsprechend viele Parameter. Bis man wirklich durchblickt hat was was macht und welche optionen es braucht dauert es seine Zeit. Komplizierte Dinge ohne nachzugooglen zu erledigen ist nicht leicht. Auch ist es für mich im moment schwer den Überblick über alle möglichkeiten von git zu bekommen.
• Man kann ECHT was kaputt machen. Dass man im nachhinein das Repository verändern kann ist Segen und Fluch zugleich. Den Segen hab ich bereits vorgestellt. Der Fluch sieht so aus: vertippt man sich (selten) oder tut man etwas ohne wirklich eine Ahnung zu haben (häufig) kanns durchaus passieren dass wirklich was schiefgeht, und das Repository so verändert ist dass der ursprüngliche Zustand nicht mehr wiederherzustellen ist.
  Deswegen sollte man vom repo immer backups haben (zumindest das geht sehr leicht), und beim pushen sehr (SEHR) gut aufpassen.
  Hier ein Tipp vom Idioten zum Idioten:
  Wenn ihr ein repository im Internet habt, und ihr den "master" branch pushen wollt, FINGER WEG VON DER "--force" bzw. "-f" OPTION!!! Niemalsniemalsniemalsniemals verwenden! Wenn ihr das tut naht die Apokalypse, die Erde tut sich auf, alle Repositories dieser Welt fallen in den Spalt und es regnet Merge- konflikte!
  Wieso so dramatisch? Gestern war ein schlechter Tag für mich. Weil er anscheinend noch nicht schlecht genug war, hab ichs geschafft mit der -f option mein repository ziemlich zu verkrüppeln. Heute war ich glücklicherweise konzentrierter und konnte den Schaden größtenteils beheben.
• Zum hosten auf Servern braucht man einen eigenen git-deamon. Das ist zwar klar, denn für SVN braucht man das auch. Andere Systeme, wie zum Beispiel Bazaar begnügen sich aber auch mit einem einfachen FTP oder WebDAV Server. Wäre sehr nett, wenn git das auch könnte.
• Windows support. Git ist OpenSource und wurde von OpenSource-entwicklern für OpenSource-entwickler geschrieben. Das führende Betriebssystem in der OpenSource Gemeinde ist nunmal Linux, und so ist und wird git auch immer auf Linux hin ausgerichtet sein. ABER:
  Es gibt zwei Windowsports: einen "nativen", nämlich msysgit, das MinGW Bibliotheken verwendet und mehr oder weniger verwendbar ist und dann gibt es noch git in Cygwin, das allerdings ziemlich langsam und relativ anstrengend zu bedienen sein soll.
  Nicht vergessen, das Projekt entwickelt sich noch, das bedeutet die Situation kann sich durchaus ändern.

Weiterführende Links
Wikipedia, als mehr oder weniger neutrale beschreibung:
http://en.wikipedia.org/wiki/Git_(software)

Als erstes zu erwähnen sei die Git Homepage. Dort findet ihr die neueste Version, genug Dokumentation und alles was mit Git zu tun hat:
http://git-scm.com/

Das Git wiki, durchaus Informativ und enthält viele Artikel. Attribut: Lesenswert
http://git.or.cz/gitwiki

Hier nochmal ne Ausführliche erklärung, warum Git so toll ist: (Achtung, Unbefangenheit kann nicht garantiert werden)
http://whygitisbetterthanx.com/

Ein recht gutes Tutorial das die Basics gut rüberbringt:
einfach in die Konsole tippen wenn das entsprechende Paket installiert ist.
Alternativ:
http://www.kernel.org/pub/software/scm/ ... orial.html

Ein paar Seiten zum Workflow mit git, die ich gerade im Browser offen habe:
http://www.neeraj.name/blog/articles/78 ... ith-github
http://www.eyrie.org/~eagle/notes/debian/git.html
http://reinh.com/blog/2009/03/02/a-git- ... teams.html
http://blog.madism.org/index.php/2007/0 ... note-138-1
http://blog.hasmanythrough.com/2008/12/ ... ch-pattern

Abschließende Worte
Zugegeben, der Artikel war nicht wirklich neutral. Sollte er auch nicht sein, denn ich bin im Moment ziemlich begeistert von Git, weil es mir die Arbeit sehr erleichtert und absichert. Und mal ganz ehrlich, es ist schon was cooles wenn man am Ende seines Tages nach einem "git push" mit der Nachricht xx bestätigt bekommt, wie fleißig man war

Deswegen mein Aufruf an alle:
Einfach mal ausprobieren! Ihr werdet positiv überrascht sein, wenn ihr bisher svn verwendet habt. Wenn nicht dann werdet ihr den Nutzen eines Versionskontrollsystems schnell zu schätzen lernen.

Ich hoffe auf viele kommentare:
Wie findet ihr Git? Werdet ihr es probieren? Wie findet ihr meinen Text?
Natürlich könnt ihr hier auch Probleme und Fragen posten. Ich werde sicher nicht alle beantworten können, ich bin auch kein Git-Profi, allerdings werde ich mein bestes versuchen.

In diesem Sinne,
Happy Git

mfg, fat-lobyte

Hi, habe deinen interessanten Beitrag gelesen und denke auch seit geraumer Zeit über git nach. Zur Zeit nutze ich SVN über den Apache Webserver (SVN Extension). Da ich letztens ziemliche Probleme mit SVN hatte, da ich Comitts nicht ändern konnte u.a. denke ich nun darüber nach, mein Repository auf git umzustellen (umzuwandeln). Hast du dein SVN Repo erfolgreich von svn auf git umgewandelt? Besteht da eine Gefahr?

whitenexx hat geschrieben:Da ich letztens ziemliche Probleme mit SVN hatte, da ich Comitts nicht ändern konnte

Geht theoretisch auch mit SVN - man braucht aber Filter und muss das Repository neu Aufbauen... Echt komplizierte Geschichte Da bist du mit git wirklich gut bedient.

whitenexx hat geschrieben:Hast du dein SVN Repo erfolgreich von svn auf git umgewandelt? Besteht da eine Gefahr?

Ja, das habe ich tatsächlich, das ging auch recht einfach. Die Sache ist nur die, ich hatte keine Tags und keine Branches in meinem SVN Repo, deswegen ging alles etwas leichter. Aber ich denke das sollte trotzdem kein großes Problem sein.
Dein Freund heißt hier "git-svn", das ist bei Debian/Ubuntu ein eigenes Paket, keine Ahnung wies bei deiner Distro ist.
Hier ist ne kleine Anleitung:
http://github.com/guides/import-from-subversion
Aber ich glaube das ursprüngliche Konvertieren ist nur der Befehl Wenn du auch noch eine richtige Zuordnung der Autoren willst, dann musst du ein kleines "authors-file" schreiben, ist aber kein großes Ding. Steht alles im Link drinnen.

[edit]Da fällt mir gerade ein... Ein Tipp: Mach backups! Ganz ganz viele! Vom SVN Repo, wenn dus geschafft hast vom Git Repo, dann am besten noch tägliche Backups... Nicht dass git so instabil wäre - ich habe nur am Anfang ziemlich oft mein Repository geschrottet, einfach nur weil ich noch nicht so viel Ahnung von git hatte. Du kannst natürlich auch Vorsichtig sein und die Manpages lesen - aber so ist es lustiger [/edit]

Magst Du zu GIT was ins Wiki schreiben?

Xin hat geschrieben:Magst Du zu GIT was ins Wiki schreiben?

Was hast du dir so ungefähr vorgestellt? Eine kurze Einleitung oder eher ein kleines Tutorial?
An sich ist git recht gut dokumentiert und es gibt auch mehrere Tutorials dazu. Eins davon ist das "offizielle", man 7 gittutorial [1]. Ein Projekt zur Übersetzung der manpages ins Deutsche ist am laufen [2], und beim letzten Blick aufs "gittutorial"[3] sahs auch so aus, als ob das nicht so schlecht übersetzt wäre.
Außerdem hat so ziemlich jedes Projekt das git verwendet ebenfalls nützliche Tips auf Lager [4][5], und dann gibts natürlich noch Github [6].
Also ums kurz zu machen - ein wirkliches Tutorial aufzuziehen würde ich für etwas überflüssig halten. Am ehesten noch eine kleine Einleitung mit anschließender Linksammlung,
Oder meintest du eher einen Text darüber was git ist und was es kann, so wie im Sinne des oberen Posts?

[1] http://www.kernel.org/pub/software/scm/ ... orial.html
[2] http://repo.or.cz/w/gitman-de.git
[3] http://repo.or.cz/w/gitman-de.git?a=blo ... ;hb=master
[4] http://wiki.winehq.org/GitWine
[5] http://github.com/rails/rails/tree/master
[6] http://github.com/guides/home

Man siehe auch mal wieder bei Google Video rein.
Zum Beispiel spricht Randal Schwartz
und Linus selbst

Was ich ins Wiki stellen würde:

Einen groben Überblick darüber, was GIT kann und wie man das mit GIT macht.
Im Endeffekt eine Art "Schnellanweisung", die jemanden, der noch nie mit git gearbeitet hat in die Lage versetzt, grundlegendes Versionsmanagement damit zu betreiben.
Dann noch eine Sammlung "Weiterführender" Links, die allerdings auf unsere linkseite ausgelagert werden sollte.

fat-lobyte hat geschrieben:Oder meintest du eher einen Text darüber was git ist und was es kann, so wie im Sinne des oberen Posts?

Vorrangig ein Kurztutorial in Deutsch.

Aktuell interessiert mich ein Hinweis darauf, wie man einen Repository-Server aufbaut.

Xin hat geschrieben:Vorrangig ein Kurztutorial in Deutsch.

Mal sehen wann sich Zeit findet.

Xin hat geschrieben:Aktuell interessiert mich ein Hinweis darauf, wie man einen Repository-Server aufbaut.

Blöd, damit kenn ich mich nun gar nicht aus
Nein ernsthaft, bin reiner User bis jetzt hats noch gereicht.
Aber nach 5 minuten googeln siehts so aus, also wär ein einfaches Repository nicht allzu schwer: http://blog.commonthread.com/2008/4/14/ ... git-server

Ein "full blown" Git repository, mit WebDAV, gitweb und allem drum und dran dagegen etwas komplizierter:
http://www.kernel.org/pub/software/scm/ ... r-http.txt

Und da gibts ja noch den git-daemon: http://devhobby.blogspot.com/2008/04/qu ... aemon.html

Sorry, ich persönlich kann da nicht aushelfen.

fat-lobyte hat geschrieben:Und da gibts ja noch den git-daemon: http://devhobby.blogspot.com/2008/04/qu ... aemon.html
Sorry, ich persönlich kann da nicht aushelfen.

Ich versuche mich an dem Daemon... aktuell stelle ich fest, dass ich runsv nicht kenne...

Ich schätze der Part des Tutorials geht dann an mich.