10 Dinge die man an Git hassen kann
-
Shade Of Mine schrieb:
Ich verwende idR Tools statt der Commandline und damit sind alle Punkte bis auf das rebase weg.
Ja, wir auch. SmartGit ftw!
-
iGit schrieb:
Warum laufen bei Git eigentlich so viele Fanatiker rum, die das Ding als den Heiligen Gral preisen, und das auf eine äusserst penetrante Art und Weise?
Weiß ich auch nicht. Offenbar bewegst du dich in den falschen Foren, wenn dir solche Leute häufiger begegnen.
-
Christoph schrieb:
iGit schrieb:
Warum laufen bei Git eigentlich so viele Fanatiker rum, die das Ding als den Heiligen Gral preisen, und das auf eine äusserst penetrante Art und Weise?
Weiß ich auch nicht. Offenbar bewegst du dich in den falschen Foren, wenn dir solche Leute häufiger begegnen.
Du warst noch nie im IRC zu diesem Forum oder?
-
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.
-
Ich find jetzt zwar auch nicht grade, dass git der Oberknaller ist, aber das liegt jetzt nicht am mangelnden klicki-bunti
Und erst recht nicht daran, dass ich Äpfel mit BirnenWürstchen vergleiche und mich wundere, dass git ja so ganz anders ist als SVN (immerhin sind die Leute nicht bei CVS stehen geblieben).Ich finds einfach zu überladen, vor allem rebase und ähnliche bomb-the-repo features sind fragwürdig, daher bin ich dann auch irgendwann auf veracity umgestiegen (und weil letzteres einen eigebauten bugtracker hat). Aber grundsätzlich sind DVCS und CVCS nunmal zwei Paar Schuhe, deshalb ist SVN immer ein schlechter Vergleich.
-
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)?
PS:
bis auf vermutlich mal einfacher zu konfigurieren
-
Shade Of Mine schrieb:
Und dass github scheinbar eine komplizierte Struktur hat, ist nun auch nicht unbedingt ein git Fehler. Ich pushe bei mir zB ins repo und sofort kann jemand anderer pullen. Da ist kein Zwischenschritt notwendig.
bei github ist da auch kein zwischenschritt notwendig, sofern du push rechte für das repo hast.
der zwischenschritt (aka fork + pull request) ist nur notwendig, wenn du KEINE push rechte hast, was bei open source und/oder sehr großen projekten oft der fall ist.
ansonsten ist github genauso einfach wie ein git init --bare.
-
lolhehe schrieb:
bei github ist da auch kein zwischenschritt notwendig, sofern du push rechte für das repo hast.
der zwischenschritt (aka fork + pull request) ist nur notwendig, wenn du KEINE push rechte hast, was bei open source und/oder sehr großen projekten oft der fall ist.
Alles klar. Das macht komplett Sinn. Dann verstehe ich die Kritik daran nicht.
-
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.
-
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.
-
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
-
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
-
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.
-
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
-
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.
-
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.
-
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
