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:
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.man 1 git hat geschrieben:git - the stupid content tracker
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:
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.
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 - 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
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
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
Code: Alles auswählen
man gittutorialAlternativ:
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
