10 Dinge die man an Git hassen kann

Walli

Dravere schrieb:

Wenn man aber mal drin ist und z.B. das gratis Buch ProGit gelesen hat, kann man mit Git sehr gut arbeiten.

Ich nehme an dass man erst ein Buch lesen muss ist das das Hauptproblem. emacs ist auch deutlich flexibler als nano, aber mit letzterem kann man JETZT schnell auf dem Server was editieren, und nicht erst in 3 Wochen. Die meisten Leute wollen ein VCS um damit ihren Code zu verwalten, und nicht um was über die hohe Kunst der Versionsverwaltung zu lernen. Ich habe git etwas länger verwendet, aber dann irgendwann wieder SVN genommen, als ich gemerkt habe, dass ich viel Zeit mit git verplempere, die ich eigentlich für die Programmierung einsetzen könnte.

Dravere

Walli schrieb:

Dravere schrieb:

Wenn man aber mal drin ist und z.B. das gratis Buch ProGit gelesen hat, kann man mit Git sehr gut arbeiten.

Ich nehme an dass man erst ein Buch lesen muss ist das das Hauptproblem. emacs ist auch deutlich flexibler als nano, aber mit letzterem kann man JETZT schnell auf dem Server was editieren, und nicht erst in 3 Wochen. Die meisten Leute wollen ein VCS um damit ihren Code zu verwalten, und nicht um was über die hohe Kunst der Versionsverwaltung zu lernen.

Ehm, du musst gerade mal die ersten 3 Kapitel lesen, um die grundsätzlichen Dinge von Git zu kennen und es somit verwenden zu können. Die restlichen Kapitel sind nur dazu da, wenn du fehlerhafte Commits hattest oder du dir sonst das Leben erleichtern willst, wo du mit SVN völlig aufgeschmissen wärst.

Für diese 3 Kapitel braucht man keine 3 Wochen. Dafür brauchst du womöglich nicht mal einen Vormittag. Auch SVN oder nano musst man am Anfang erlernen.

Der Rest ist dann nur noch sich darauf einlassen und es anzuwenden.

Gerade zu deinem Beispiel mit Emacs und Nano, finde ich, dass man Git da eher mit Nano gleichsetzen sollte. Früher habe ich mich bei meinen privaten Projekten immer ein wenig drum gedrückt SVN zu nehmen. Ist so verdammt langsam, Branches sind mühsam, Tags ebenfalls, usw. Schon nur ein Repository aufzusetzen ist mit SVN umständlich. Mit Git habe ich inzwischen alle Projekte unter Versionskontrolle, weil es eigentlich so verdammt einfach ist. Man muss nur am Anfang den steilen Hang hinauf, aber danach hat man eine schöne Übersicht.
Wobei ich mich allerdings auch etwas frage, ob der Hang für mich nur steil war, weil ich mich an SVN gewohnt war. Wäre noch interessant zu sehen, wie das Leuten ergeht, welche zuerst Git lernen und erst später SVN.

Und zudem gibt es ja inzwischen auch allerhand Gui-Tools. Sogar welche die unter Windows funktionieren.

Grüssli

Shade Of Mine

Walli schrieb:

Ich nehme an dass man erst ein Buch lesen muss ist das das Hauptproblem.

Nein, das Hauptproblem ist, dass die Leute keine Tools verwenden wollen.

Ich habe zB langezeit den git client von Netbeans verwendet. Ich hatte keine Ahnung von dem ganzen Zeug dass der Autor meint dass man unbedingt verstehen muss. Ich meine remote repo und lokales ist schnell kapiert. Ein commit commit zum lokalen repo ein push commitet zum remote repo. Fertig. Der Rest ist eh easy durch die GUI erklaert. Ein merge? Keine Ahnung wie das haendisch in git geht - ich bekomme 1 Fenster der mir die Dateien vergleicht und ich sage was passieren soll. etc.

SmartGit ist zb ein Standalone client der aber leider kein Blame kann, was ich sehr wichtig finde.

Das Problem sind nur die Tools...

Warum verwendet man git? Nur damit man ein lokales Repo hat und commits rückgängig machen kann? Was bringt das sonst mehr als SVN?

branching

Shade Of Mine

9eun schrieb:

Warum verwendet man git? Nur damit man ein lokales Repo hat und commits rückgängig machen kann? Was bringt das sonst mehr als SVN?

Du entwickelst anders.
Und das ist warum es soviele git fanbois gibt (wobei der Vorteil bei allen DVCS zu finden ist, aber git ist das erste, dass mainstream ist).

Bei svn kannst du nicht dauernd commiten. Du wuerdest gerne - kleine Aenderung und sofort commit. Aber das geht nicht. Weil die Aenderung ist ja vielleicht nicht korrekt. Da muss erstmal der Test durchlaufen. Oder die Aenderung ist nicht vollstaendig kompilierbar. Ein riesiges Nogo. Etwas ins SVN einchecken dass nicht kompilierbar ist...

Aber mit git alles kein thema - weil man nicht pushen muss. ein push ist ein commit an den Server. Erst dann werden die Aenderungen wirksam die man gemacht hat. Vorher ist das nur lokal bei dir.

Dadurch kann man ganz anders entwickeln und das begeistert die Leute. Deswegen gibt es ja auch git-svn gateways. Du hast lokal bei dir ein git repo - und ein push ist dann einfach nur ein commit ins svn.

*rant*

SVN, git, TFS mit Tausend Plug-Ins... der heilige Gral ist noch nicht gefunden. Mercurial sieht von allem am interessantesten aus, da es scheinbar simpel und sauber ist. Geschäftlich ist alles TFS, im Studium lernt man immernoch hautpsächlich SVN, nutzt aber git, da man ja flexibel ist. Irgendwie wäre ein Zwischending aus git+TFS ideal. Ich möchte mich nicht damit beschäftigen müssen und dennoch alle Möglichkeiten offen halten.

Ich habe an git vieles gehasst, was der Autor in seinem Post erwähnt hat, im besonderen diese verdammte Dokumentation. Normalerweise bin ich jemand, der gerne selbst solche Sachen liest und verstehen lernt mit probieren. Aber bei git musste ich aufgeben. Auch mein Kollege, der geschäftlich das Glück hat mit git arbeiten zu müssen und persönlich sehr davon überzeugt ist ("Fanboi"), konnte mir die Konzepte nicht verständlich erklären. Ich habe mich dann einfach in die Schlacht geworfen und irgendwie angefangen, es zu verwenden. Nach ungefähr 20 Wochen intensivster Arbeit damit habe ich langsam ein Gefühl dafür erhalten, wie man git benutzt, aber anfreunden konnte ich mich damit nicht wirklich.

Momentan sind Semesterferien und ich arbeite praktisch nur mit TFS; die neuste Version des TFS ist sehr vereinfacht worden. One-click Installer und voll integriert. Aber der TFS/SharePoint Clusterfuck bleibt natürlich. Da will man schon bald wieder einfach nur SVN nutzen

hustbaer

lolhehe schrieb:

Martin2k schrieb:

Ich kann nur zustimmen. Ich hab mir Git ein paar Stunden angeschaut und fand es grauenhaft. Miese Tools unter Windows und es war einfach alles umstaendlicher und komplizierter als bei SVN.
Mich interessiert Git auf jeden Fall nicht mehr.

ein schweizer taschenmesser ist auch komplizierter als ein brotmesser. aber wenn dir das brotmesser ausreicht, ist doch alles gut.

für mich ist git erste wahl aufgrund des genialen branchings. daher werde ich auch niemals nie mehr svn benutzen. svn branching ist ein schlechter witz.

Das BRANCHING selbst ist mit SVN total unproblematisch. Ich wüsste auch nicht was man da grossartig verbessern könnte/sollte.
Soweit ich weiss kann Git da auch weniger als SVN, insofern man in Git immer nur das gesamte Repository branchen kann, nicht aber einzelne Verzeichnisse.
(Bitte berichtige mich falls das nicht stimmt)

Ich gehe aber davon aus dass du gar nicht das BRANCHING selbst meinst.

pumuckl

Shade Of Mine schrieb:

pumuckl schrieb:

bin ich dann auch irgendwann auf veracity umgestiegen (und weil letzteres einen eigebauten bugtracker hat).

Siehst du bei einem eingebauten Bugtracker irgendwelche Vorteile zu ordentlichen Loesungen wie zB github (hosted) oder chiliproject (selfhosted)?

Die Work Items in Veracity unterliegen auch der Versionskontrolle (bzw. kommt wohl erst noch), so dass Bugs, die auf Branch A gefixt sind, auf Branch B noch offen sind. Genauso werden sie zusammen mit den anderen Daten per push/pull übermittelt (geht auch einzeln). Chiliproject kannte ich noch nicht, selfhosted war aber essentiell, weil ich auch offline auf den Tracker zugreifen wollte, sowohl schreibend als auch lesend.

Noch ein Punkt der "Spaß" macht: Repos sind nicht an eine einzelne Working Copy gebunden, sondern liegen separat. So kann man zu einem Repo mehrere Working Copies haben.

git branching funktioniert komplett anders als in svn. ein branch in svn ist eine kopie des gesamten repositories (oder halt eines teiles). in git ist ein branch nichts anderes als ein pointer auf ein commit.

dementsprechend einfach (in form von leichtgewichtig) ist es in git, einen branch anzulegen und zu mergen. es werden keine dateien durch die gegend kopiert sondern einfach nur commits eingecheckt und die parent pointer entsprechend gesetzt.

das ist alles so tausend mal einfacher und schneller und komfortabler und weniger fehleranfällig als in svn.

so einfach, dass ich jeden tag x mal branche und merge, quasi bei jeder neuen aufgabe, die anfällt. das hat den großen vorteil, dass man parallel an mehreren sachen arbeiten kann und auch jederzeit zwischen den aufgaben switchen kann, ohne dass sich die codeänderungen gegenseitig in die quere kommen. man kann problemlos mehrere lösungsansätze ausprobieren und am ende die beste lösung mergen und die anderen verwerfen.

als ich noch svn genutzt habe, da habe ich branching gehasst. es hat lange gedauert und das mergen war grauenvoll, vor allem in größeren teams.

@hustbaer: du solltest git branching einfach mal ausprobieren (hast du ja bisher offenbar nicht getan).

einfach mal die ersten paar kapitel von pro git durchlesen und gleich dabei selbst ausprobieren. macht tierisch spaß und danach hat man alle basics drauf, die man wissen muss, um mit git super zurecht zu kommen.

pumuckl

lolhehe schrieb:

es hat lange gedauert und das mergen war grauenvoll, vor allem in größeren teams.

Ich denke vor allem das Mergen ist das eigentliche Problem.

Es gibt ein ziemlich gutes, frei erhältliches Buch über VCS, auch online einsehbar: http://www.ericsink.com/vcbe/html/bk01-toc.html

Shade Of Mine schrieb:

Nein, das Hauptproblem ist, dass die Leute keine Tools verwenden wollen.

Ja, vom Standpunkt mancher Entwickler vielleicht. Ich arbeite u.a. remote auf Systemen, die ich nicht administrieren kann und wo ich i.d.R. nur eine Shell habe. Hier helfen die grafischen Tools mir herzlich wenig. Das Problem bei git ist auch nicht das Alltagszeug, sondern die Hilflosigkeit, wenn mal was nicht funktioniert. Das UI ist von Haus aus einfach fucked up und die Dokumentation dazu ist zu technisch. Bevor ich die lese, kann ich mir auch gleich den Code ansehen. Mag sein, dass es klasse Tools gibt, aber ich arbeite taeglich auf 2-3 verschiedenen Systemen. Und so lange es da nichts schoenes gibt, was 1) gewissen Usability-Anspruechen genuegt und 2) mindestens auf OS X und Ubuntu laeuft, brauche ich mir die nicht anzuschauen. Empfehlungen nehme ich gerne entgegen, denn git ist eigentlich vom Konzept her super und aufgrund der vielen Vorzuege wuerde ich es gerne verwenden. Allerdings nicht zu dem Preis, dass ich bloatige Tools oder gar auf jedem System ein anderes Frontend verwenden muss.

Nachtrag: Taugen die GitHub-Tools etwas, oder kann man die nur auf deren Servern verwenden? Die OS X-Version sieht ja recht sexy aus, und unter Linux scheint es zumindest ein Eclipse-Plugin zu geben. Sind die von der Bedienung her aehnlich? Weiss jemand was dazu?

Remote aendern tue ich kaum, und wenn ich zumindest auf meinen Arbeitsrechnern schon mal was grafisches haette, was halbwegs konsistent bedienbar ist, dann wuerde ich git mal wieder in Betracht ziehen wollen.

nman

Ich hab jetzt keine Lust, mir wieder einen ganzen VCS-Thread anzutun oder zu erklaeren warum ich mit Git sehr zufrieden bin, deswegen aber noch lange keine Probleme mit anderen modernen DVCS wie etwa Mercurial habe, aber vielleicht hilft das hier ja irgendjemandem:

http://www.git-legit.org/

Benutzt ein Kollege, dem Darcs jetzt zu anstrengend wurde.

nman

Walli_ schrieb:

Nachtrag: Taugen die GitHub-Tools etwas, oder kann man die nur auf deren Servern verwenden?

Die sind sehr auf GitHub ausgelegt. Dafuer (und wohl fuer GitHub Enterprise) zwar spitze, aber das sind GitHub-Clients, nicht Git-Clients.

Unter OSX verwende ich oefters gitx als huebscheres gitk. (Praktisch zur Uebersicht ueber Branches etc.)

Ein paar Bekannte benutzen Tower und sind davon recht angetan.

edit: Gity hat auch seine Fans.

Shade Of Mine

Walli_ schrieb:

Ja, vom Standpunkt mancher Entwickler vielleicht. Ich arbeite u.a. remote auf Systemen, die ich nicht administrieren kann und wo ich i.d.R. nur eine Shell habe.

Und dann entwickelst du dort auf nano? Oder wie genau schreibst du dort Code?

Shade Of Mine schrieb:

Und dann entwickelst du dort auf nano?

Ist die Frage ernst gemeint? Dass das mit Nano ein Beispiel war, kann man nur mutwillig nicht verstehen, oder?

Shade Of Mine schrieb:

Oder wie genau schreibst du dort Code?

Auf diesen Systemen selber schreibe ich kaum Code, eventuell mal kleine Aenderungen, die man leicht mit jedem x-beliebigen Editor den man zur Verfuegung hat eintippen kann. Allerdings moechte man gerne Inputs und entsprechend produzierten Output von Rechnungen verwalten. Hier war git gut, so lange alles nach Plan lief. Bei Konflikten ist es in eine derartige Frickelei ausgeartet, dass ich die Schnauze schnell voll hatte. Mag sein, dass ich git einfach nicht verstanden habe. Aber ich moechte nicht, dass die Bedienung eines derartigen Brot-und-Butter-Tools mir derartige Einarbeitung abverlangt. Nicht, wenn ich die Zeit auch sinnvoller nutzen kann und mich dafuer mit einem halb so 'maechtigen' Tool zufrieden geben muss.

@nman: Danke, werde ich mal ausprobieren!

lolhehe schrieb:

fazit: git ist zu kompliziert für leute, die nicht bereit sind, etwas neues zu lernen.

Oder: Es ginge so viel besser... ich bin müde...

Shade Of Mine

Für was genau willst du git verwenden?
Ich verstehe es einfach nicht.

als git Client kann ich SmartGit empfehlen.

Shade Of Mine schrieb:

Für was genau willst du git verwenden?
Ich verstehe es einfach nicht.

Um meinen Code, dessen Eingabe und Ausgaben, Texte und sonstiges zu verwalten. Mir ist es wichtig auch nach laengerer Zeit noch zu wissen, welche Ergebnisse mit welcher Version meines Codes erzeugt wurden, und welche Inputs ich verwendet habe. Im Prinzip also nichts, was SVN nicht auch koennte. Git ist damals bei mir rausgefallen, weil ein zerschossenes Repository mich mal ewig lange beschaeftigt hat, und ich beim besten Willen keinen Grund erkennen konnte, warum es eigentlich so weit gekommen ist. Allerdings hat mich der letzte Post von lolhehe wieder neugierig gemacht. Fuer einzelne Aufgaben im Entwicklungsprozess jeweils Branches zu erstellen und nachher wieder reinzumergen ist in SVN wirklich ein Krampf. Auch das mit den GIT-to-SVN Gateways klingt nach einer guten Idee.

Shade Of Mine schrieb:

als git Client kann ich SmartGit empfehlen.

Danke. Vom Plattform-Support her sieht es ziemlich optimal aus.