Es ist und bleibt zu kompliziert und hat zuviel Unsinnigen Overhead. Selbst leiteste Grundfunktionen und Szenarien (wie von Marco genannt) sind nicht oder nur äussert schwer zu bewältigen. Es sollte eine Open Source Lösung geben, die wirklich einfach nur funktioniert. Eine, die im besten Fall sogar noch ein Quäntchen von Configuration Management bietet. Nach sowas suche ich seit Jahren leider vergeblich…
Sehe ich anders, Git braucht Einarbeitungszeit aber Perforce zb auch.
Git ist nicht einfacher oder komplizierter als andere RVS nur eben anders was auch an der dezentralen Natur liegt. Auch Mercurial (hg) arbeitet anders nur die Jungs haben viele der geläufigen Begriffe beibehalten.
Gesendet von meinem Nexus 7 mit Tapatalk 4
Gar nichts ist da kompliziert und Overhead gibts auch keinen, es ist ganz simpel und darum funktioniert es auch. Wer mehr will, soll mehr Zeit investieren und sich mit dem System auseinandersetzen, ganz einfach. Und eben das hast du anscheinend nicht vor.
Ich finde schon, dass GIT schwieriger als SVN ist. SVN ist anfangs leichter. Bei GIT wundert man sich anfangs schon über das ein oder andere “Feature”. Trotzdem bin ich absoluter GIT-Fan und würde das jedem empfehlen.
Es ist nicht schwieriger. Man muss es nur anders angehen. Der wichtigste Punkt den man am Anfang verstehen muss, das man immer ein komplettes Repository hat, auch lokal und nicht nur eine Working Copy.
Schon alleine, dass Du ein lokales und ein entferntes Repository hast, ist doch schon komplexer. Ich habe genug Leute gesehen, die anfangs nicht gepusht haben und sich dann wunderten. Bei SVN kann das überhaupt nicht passieren. 
Komplex != schwierig. Es ist einfach ein Konzept das man verstehen muss.
Wortklauberei. 
Muss man halt auch klarstellen. Und da kommt halt der nächste Vorteil von Git auch zum Augenschein. Einfach ein
git init
und ich habe ein voll arbeitendes Repository ohne irgendwo einen zentralen Speicher zu haben.
Ich würde das eher anders beschreiben: Es ist bei SVN nicht so, dass einem sowas nicht passieren kann. Es ist viel mehr so, dass man auf das zentrale Repo für jede noch so dämliche Aktion, auch für die Logs, angewiesen ist. Oder anders gesagt: Ohne das Ding ist man aufgeschmissen und zwar von vorn bis hinten. Verschlimmert wird das Ganze noch zusätzlich dadurch, dass SVN die Dateien alle einzelnd über den Draht verschickt und das auch noch unkomprimiert. Wenn ich unser Hauptprojekt in der Firma auschecken muss, dann kann ich den Vorgang starten und nach 10min vorbeischauen, wie weit es denn ist. 10min klingt nach viel Zeit? Das letzte mal, als ich das gemacht habe, war das nicht mal zur hälfte fertig und das übers LAN wohl gemerkt. Das liegt einfach an dem Rumschieben der einzelnen Dateien und den Pausen dazwischen und das frisst viel Zeit, selbst wenn es nur 1kb-Dateien sind. Das selbe Projekt mit Git zu klonen dauerte hingegen aber nur wenige Sekunden. Na?
Der grundsätzliche Workflow ist außerdem kaum wirklich anders, weist aber gewaltige Unterschiede auf. Man macht Änderungen und commitet diese. Der einzige Unterschied von den notwendigen Befehlen her ist lediglich der Push und das ist in meinen Augen gleichzeitig auch die Stärke oder der Vorteil. Während ich bei Git rumspielen und einfach rumprobieren kann, wie ich will und später die Änderungen einfach verwerfen kann, weil es doch nicht geklappt hat, kann man das bei SVN nicht. Jedes Commit wird sofort in das zentrale Repo gepusht und ist somit allen zugänglich, wobei das noch gar nicht das Problem ist. Das Problem in meinen Augen ist bereits die Tatsache, dass der „kaputte“ Ansatz bereits überhaupt im Repo drin ist und dadurch nicht nur Speicher frisst, sondern auch noch in der Historie auftaucht. Selbst wenn man mittels Revert die Änderungen zurückspielt, so ist der Müll noch immer drin. Während ich bei Git einen Fehlversuch einfach verwerfen kann, vielleicht noch mit GC den Müll sogar vollständlich aus dem Repo verbannen, weil die Commits dann auch tatsächlich gelöscht werden und nirgends mehr auftauchen. Und genau eben diese kleine Tatsache ist der Grund, warum Git-User jede Menge kleine Commits machen und so wirklich eine Geschichte erzählen, die an jedem einzelnen Punkt geändert werden kann, und SVN-User sich kaum trauen überhaupt was zu commiten, erst recht nicht fehlerhaften Code und dann vor dem Problem stehen, dass sie entweder zu viel verwerfen müssen, weil keine Zwischen-Commits verfügbar sind, oder umgekehrt, das Repository mit dem gesamten Müll zugemüllt haben. Um das ebenfalls mit einer Geschichte zu beschreiben: bei SVN erzählt man keine schöne Geschichte, sondern schreibt oft eher fette Kapitel, die oft sogar fehlerhaft sein können, leider aber nicht in den Papierkorb wandern können, sondern durchgestrichen werden müssen.
Das sind schon allein die Unterschiede bei den Grundlagen der untersten Stufe. Bei Branching wird der Spaß noch viel krasser und genau da hört für mich der Spaß mit SVN endgültig auf! Ein Push als Ausrede ein dezentrales SCM/VCS zu benutzen ist kein Argument.
EDIT:
Um das nochmal klar zu stellen. Ich habe früher auch gerne SVN benutzt, das hat sich aber schlagartig geändert. Git ist in den Grundlagen nicht komplizierter als SVN, ist aber selbst in den Grundlagen bereits flexibler und in meinen Augen mächtiger. Das macht Git in den fortgeschrittenen Abläufen natürlich dann auch recht komplex, aber da kommt wieder die Flexibilität und die Macht ins Spiel, die einem diese Prozesse überhaupt erst ermöglicht und dennoch vergleichsweise sehr einfach und elegant bleibt. Dass man Git als kompliziert betrachtet, ist keine technische Hürde, sondern lediglich die Blockade im Kopf, weil man hier und da einen Befehl mehr absetzen muss und das ja so umständlich scheint. Git ist nicht besser, es ist anders, sicherlich komplexer, aber dafür auch wesentlich flexibler und leistungsfähiger, aber nicht kompliziert!
Bitte nicht nur einzelne Passagen meiner Texte rausziehen und dann irgendwie interpretieren.
Ich bin ein GIT Fan und nutze es, wo es geht. Aber wenn ich die SVN Leute sehe, die auf GIT schwenken, kommen immer wieder Fragen auf. Das war beim Wechsel von CVS auf SVN nicht so, da die Prinzipien ähnlich sind.
GIT ist toll, bedarf aber etwas mehr Verständnis als „alte Systeme“ und benötigt entsprechend Einarbeitungszeit.
Das war ja nicht der Fall, ich habe nichts interpretiert und ich habe auch durch vorherige Posts gesehen, dass du Git nicht verpönst. Mir ist das durchaus bewusst, dass Leute aus SVN da ihre Probleme haben, ich habe Git ja auch gemieden. Aber das ist meinen Augen kein technisches Problem, sondern eine Blockade im Kopf, weil man sich zu viele Gedanken um unwichtige Dinge macht und es sich schon unschmackhaft macht noch bevor man es überhaupt mal gesehen hat oder ausprobiert hat. Das grundlegende Arbeiten ist ja fast gleich. Als Hauptargument fällt aber oft eben der nötige Push, um Änderungen verfügbar zu machen. Aber mal ganz ehrlich, warum macht man sich über sowas überhaupt Gedanken. Bei SVN denkt da doch auch niemand drüber nach und es interessiert auch niemanden, ob die Änderungen für die anderen verfügbar sind oder nicht. Man arbeitet ganz normal (naja, nicht so ganz, eigentlich ja eher ziemlich zaghaft, weil die Verfügbarkeit für andere doch irgendwo im Hinterkopf rumspukt) und dass die Sachen dann eben bereits zentral gelagert sind und alle anderen drauf Zugriff haben, ist wohl in den wenigsten Fällen wirklich gewollt, sondern mehr eine Folge der zentralen Architektur. Da macht sich niemand Gedanken drum. Bei dezentralen VCS wie Git dann aber auf einmal schon. Dann ist die Frage auf einmal ganz wichtig und irgendwann heißt es “hmm ne, das ist mir zu kompliziert” und da denke ich mir eben nur “hallo?”. Eigentlich arbeitet man doch immer fleißig an seinem Feature oder macht sonst was und will sich einfach nur auf die Arbeit konzentrieren. Die Frage, ob anderen etwas zur Verfügung gestellt werden muss, taucht doch erst dann auf, wenn das Feature entweder fertig ist oder es aus irgend einem Grund den Bedarf gibt, dass die Änderungen doch schon für andere verfügbar gemacht werden sollen. Ansonsten ist dieser zentrale Gedanke doch vollkommen irrelevant und damit auch der Push als Problem.
Dass der Umstieg von CVS auf SVN nicht so schwer sein mag, liegt einzig und allein daran, dass SVN im Grunde nichts anderes ist, nur anstatt für jede Datei einzeln Revisionen zu verwalten eben mehrere Dateien in einer Revision zusammenfassen kann, wodurch die Commits auf einmal Sinn ergeben.
Die Stärke von Git fällt einem auch erst auf, wenn man mal eine Ecke über das commit&push auf einem Branch und Remote hinausgeht.
Beispielsweise mit einem schnellen Entwicklerrepo für diverse feature-Branches, an denen jeder rumschraubt, einem Master-Repo vor dem ein Gerrit sitzt und dahinter noch ein Jenkins, der branches bzw gerrit-changes aus den beiden Repos automatisch baut.
Teilt man dann seine Userstories/Changes auf kleine Branches auf, kann man an sehr vielen Stellen gleichzeitig arbeiten ohne sich zu behindern (wenn man dann die Changes noch schnell durchtreibt und klein hält kommt es auch selten mal zu einem Mergeproblem mit mehr als 300 oder 400 Zeilen, meistens geht es durch den 3-Way-Merge von git eh automatisch).
Zur Bedienung:
Ich nutze gerne eine Kombination aus egit in Eclipse und der git-konsole.
Mit egit kann man sehr komfortabel commits/compare/revert erledigen (commit-messages mit change-ids für gerrit inklusive), den ganzen push/pull/merge/cherry-pick/reset-Salat erledige ich über die Konsole.
Konflike bekommt man damit auch nicht, im Workspace reicht meistens ein refresh oder maven-update, wenn man über die Konsole Änderungen gemacht hat.
Die Umstellung von SVN auf git war natürlich etwas Einarbeitungsaufwand, aber mittlerweile möchte ich auf das branch-gehüpfe eigentlich nicht mehr verzichten 
Gruß
[QUOTE=Firephoenix]Die Stärke von Git fällt einem auch erst auf, wenn man mal eine Ecke über das commit&push auf einem Branch und Remote hinausgeht.
Beispielsweise mit einem schnellen Entwicklerrepo für diverse feature-Branches, an denen jeder rumschraubt, einem Master-Repo vor dem ein Gerrit sitzt und dahinter noch ein Jenkins, der branches bzw gerrit-changes aus den beiden Repos automatisch baut.
Teilt man dann seine Userstories/Changes auf kleine Branches auf, kann man an sehr vielen Stellen gleichzeitig arbeiten ohne sich zu behindern (wenn man dann die Changes noch schnell durchtreibt und klein hält kommt es auch selten mal zu einem Mergeproblem mit mehr als 300 oder 400 Zeilen, meistens geht es durch den 3-Way-Merge von git eh automatisch).
Zur Bedienung:
Ich nutze gerne eine Kombination aus egit in Eclipse und der git-konsole.
Mit egit kann man sehr komfortabel commits/compare/revert erledigen (commit-messages mit change-ids für gerrit inklusive), den ganzen push/pull/merge/cherry-pick/reset-Salat erledige ich über die Konsole.
Konflike bekommt man damit auch nicht, im Workspace reicht meistens ein refresh oder maven-update, wenn man über die Konsole Änderungen gemacht hat.
Die Umstellung von SVN auf git war natürlich etwas Einarbeitungsaufwand, aber mittlerweile möchte ich auf das branch-gehüpfe eigentlich nicht mehr verzichten
Gruß[/QUOTE]
Seh ich auch so. +1
Komisch, das SourceTree noch nicht erwaehnt wurde.
Is eine GUI fuer Git, leider nur Mac und Win, wobei die Mac Version deutlich ausgereifter ist. Mit der kann man schon viel machen, aber ich bin dennoch lieber auf der Konsole unterwegs. Da weiss ich einfach besser, was passiert, wenn ich das-und-das mache UND wenn man nicht mehr weiterkommt, kann ein erfahrenerer Kollege genau nachvollziehen, was man gemacht hat.
Uebrigens sollte es nicht wirklich schwer sein, die svn Befehle mit Git nachzubauen (auch wenn mir der Sinn verborgen bleibt):
alias svn_update="git stash && git fetch && git rebase && git stash pop"
alias svn_commit="git commit -a && git push origin master"
Man muesste noch paar mehr Parameter unterstuetzen, also kleine Scripte bauen, dann kann man wie “frueher” arbeiten. :o)
Ich bin eigentlich nahezu ausschließlich auf der Konsole/Shell unterwegs. Bei Eclipse benutze ich für die Commits zwar EGit, aber sonst für nix und unter Windows im Explorer noch TortoiseGit, wenn ich grad keine Konsole auf habe, aber auch nur für Commits. Der ganze Rest findet bei mir in der Konsole/Shell statt, geht schneller und mehr Kontrolle und man ist zudem nicht auf irgendwelche GUI-Tools angewiesen, die auf jeder Plattform völlig unterschiedlich sind (nicht übergreifend existieren) oder sonst was. Da muss ich sagen, da ist TortoiseHg sehr schick gemacht, da es auf jeder Plattform läuft und verfügbar ist, muss man sich nicht umgewöhnen oder sonst was. Aber ich bin kein Mercurial-User, sondern Git-User. Um in die Commits bzw. in ein Repo reinzuschauen, kann man auch gitk nehmen, wenn man keine Lust hat sich das in der Konsole anzuschauen, aber das Arbeiten selbst findet bei mir wie gesagt fast ausschließlich auf der Konsole statt (außer das Commiten).
Was für die Logs ganz nett ist (als alias):
logbranch = log --pretty=format:’%Cred%h%Creset %C(bold magenta)<%an>%Creset%C(yellow)%d%Creset %Cgreen(%cr)%Creset%n%w(80,8,8)%s’ --graph
logall = !git logbranch --all
logfull = log --pretty=format:’%Cred%h%Creset %C(bold magenta)<%an>%Creset%C(yellow)%d%Creset %Cgreen(%cr)%Creset%n%w(80,8,8)%s%n’ --graph --name-status
Aber ich denke mal sowas in der Richtung hat fast jeder irgendwo in der Tüte
Gruß
Meine Favoriten bzgl. Logs: http://durdn.com/blog/2012/11/22/must-have-git-aliases-advanced-examples/
Gesendet von meinem Nexus 7 mit Tapatalk 2
[QUOTE=Sym]
Ich bin ein GIT Fan und nutze es, wo es geht. Aber wenn ich die SVN Leute sehe, die auf GIT schwenken, kommen immer wieder Fragen auf. Das war beim Wechsel von CVS auf SVN nicht so, da die Prinzipien ähnlich sind.
GIT ist toll, bedarf aber etwas mehr Verständnis als “alte Systeme” und benötigt entsprechend Einarbeitungszeit.[/QUOTE]
Im Prinzip absolut richtig. Da ich nur den Wechsel von SVN zu GIT mitgemacht habe, nicht von CVS zu SVN oder andere, habe ich auch nur diesen Vergleich. Ich weiß z.B. auch nicht, wie schwierig oder leicht es wäre, wenn ich direkt mit GIT angefangen hätte. Mit SVN war es jedenfalls für mich schon recht schwierig den Einstieg in die Versionskontrolle zu finden, gerade mit den fortgeschritteneren Themen wie Administration, Konfiguration, Workflows, Teamarbeit, etc.
Mit diesen Vorkenntnissen war es immernoch nicht wirklich einfach in Git den Einstieg zu finden, aber ich wusste durch meine Erfahrung, was ein VCS alles beherrschen muss, wo Git zwar komplexer ist, aber dafür einen echten Mehrwert bietet im Alltag eines Entwicklers.
Was mich mal interessieren würde, ob hier jemand Erfahrungen mit Git im .NET Bereich hat? Unsere .NET Abteilung nutzt derzeit TFS und es steht eine Entscheidung an, ob man nicht auch dort auf GIT wechselt.
Soweit ich weiß haben die neuen TFS Versionen GIT Support builtin.