10 Dinge die man an Git hassen kann
-
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.
-
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:
Benutzt ein Kollege, dem Darcs jetzt zu anstrengend wurde.
-
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.
-
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...
-
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.
-
Shade Of Mine schrieb:
als git Client kann ich SmartGit empfehlen.
Dem kann ich mich nur anschließen. Ich bin kein großer Git-Experte (wir alle hier nicht), komme mit SmartGit aber wunderbar klar.
-
habe das glück, dass meine IDE für die entwicklung auch eine geniale git integration hat:
http://blogs.jetbrains.com/idea/2012/03/simpler-and-more-powerful-ui-for-git-branches/
bin vor ca. 1.5 jahren von svn auf git umgestiegen und habe es nie bereut. habe zunächst pro git gelesen und bin dann mit meinem team einfach ins kalte wasser gesprungen und habe die projekte migriert. haben es nie bereut - im gegenteil!
die git man pages finde ich jetzt auch nicht so toll, aber es gibt haufenweise gute seiten und blogs im netz. github hat auch ne super git doku. pro git ist kostenlos. und bei problemen hat bisher immer kurzes googlen ausgereicht.
-
auch noch nett, um git richtig zu verstehen: