Vielen Unternehmen haben nun mal Angst den gesamten Quellcode plus die gesamte History auf die Rechner zu transportieren...abgesehen davon eigenen sich einige Projekte in der Industrie dazu nicht...da helfen auch Submodules in Git nicht...die sind nicht wirklich Nutzbar geschweige denn bequem...Die andere Frage ist auch: Will ich überhaubt die gesamte Historie mit auf dem Rechner haben..
Also ein Unternehmen, dass Angst vor Entwicklern mit Zugriff auf den Quelltext hat, duerfte nicht lange existieren - oder ich versteh deinen Satz ueberhaupt nicht.
Wenn du einmal mit Git gearbeitet hast (besonders in einem (wirklich) groessen Projekt), dann wirst du den Vorteil verstehen, die History komplett lokal vorhanden zu haben. Schonmal ein "Blame" (bzw. Annotate) mit SVN probiert? Das kann u.U. seeehr lange dauern, deswegen wird es selten eingesetzt. Mit Git dauert das selbst bei den sehr haeufig geaenderten Dateien (mit einer entsprechend langen History) nur wenige Augenblicke - weil ja alles lokal da ist. Alleine das ist schon ein Vorteil.
Was ist an Branching/Mergen einfach? Das ist egal womit ob mit SVN oder Git ... Wenn Du mit 150 Branches arbeitest ist es egal...ob mit SVN oder Git...bei beiden fällst Du richtig auf die sch...ze wenn Du nicht ein ordentliches Branching Konzept hast...
Mit Git ist Branchen/Mergen wirklich einfach. Der Grund dafuer ist, dass sich Git genau merkt, wann jemand was und wie gemergt hat. SVN macht das inzwischen auch (indem es die SVN Properties dafuer missbraucht). Nur kann man dabei so viele Fehler machen (z.B. im falschen Verzeichnis mergen, wodurch die kompletten SVN Merge-Properties durcheinander gehauen werden koennen). Danach hat man ein echtes Problem. Bei Git kann man nicht viel kaputt machen. Alles was man zum zentralen Repo pusht, kann man wieder rueckgaengig machen, man kann Commits umsortieren, man kann einen einzelnen defekten Commit wieder rausnehmen und was noch alles. Deswegen wuerd ich schon behaupten, dass das Mergen mit Git einfacher ist und besser funktioniert, als mit jedem anderen VCS zuvor.
Definitiv
nicht sagen wuerde ich, dass Git generell besser ist und man das jetzt ueberall sofort einfuehren muss. Dennoch passiert es derzeit sehr oft.
Hm. in wie fern? Weil es angeblich schneller ist ? oder wie ? Hier geht es um das Branchen/Mergen und das geht mit SVN und Git...
Git ist definitiv viel schneller. Viiiiel schneller. Am Anfang wollte ich gar nicht glauben, dass es wirklich
so schnell zwischen den Branches wechseln kann. In diesem Projekt hier (ca 20k Klassen, also schon groesser), dauert das Wechseln zwischen dem ersten Commit im Git (ca. 3 Jahre alt) und dem aktuellsten Stand ca 5 Sekunden. Dabei wird nahezu jede Datei angefasst und geaendert.
---
* Maven vs Ant
Hier bin ich selbst eher gespalten. Ich persoenlich setz fuer nahezu alle privaten "Gruene-Wiese" Projekte Maven ein. Ich werd mir aber demnaechst definitiv Gradle anschauen, dass buzzt ja grad ziemlich rum.
In einem Projekt hab ich das Buildsystem neu erstellt, nachdem die alten Ant Script unwartbar geworden sind. Nach laengerer Recherche hab ich mich allerdings gegen Maven und fuer Ant mit Ivy entschieden. Die Gruende waren vielfaeltig, das groesste Problem aber war, dass das Projekt bereits aus sehr viel Quellcode ohne grossartige Strukturierung in Module bestand - mit Maven hast du aber immer die Limitierung, dass am Ende nur genau ein Artefakt rauskommen darf. Und in diesem Projekt sind am Ende sehr viele Artefakte entstanden und eine Aufteilung in Module war sogut wie unmoeglich.
Inzwischen kommen eigentlich alle Entwickler ziemlich gut mit dem Ant Zeug klar. Ich hab das aber auch in viele kleinere Ants aufgeteilt, die alle ein Basis-Ant einbinden und fest definierte Targets haben (muessen). Ganz aehnlich also wie bei Maven, aber eben mit der voellen Freiheit, wie alles ablaeuft, funktioniert und aussieht.
* IDE
Sollte jeder Entwickler selbst entscheiden duerfen. Meine Empfehlung ist IntelliJ IDEA (hat btw auch ne super Android Unterstuetzung, auch in der freien Version). Warum wird eigentlich immer vergessen, das wenigstens mit in die Auswahl zu nehmen?
* JBoss/Glassfish
Ich hab bisher im Java Umfeld nur Erfahrung mit JBoss - und die sind eher schlecht ;-) Das Problem ist dort imho, dass Updates auf neue Versionen ziemlich schwierig sind (vor allem bei aelteren Projekten). Wir haengen immer noch bei einer 4er Version, einfach weil die Umstellung mit extrem viel Arbeit verbunden ist (jaja, das Projekt ist nicht besonders dolle gemacht, aber es ist im produktiven Einsatz und das bereits seit mehreren Jahren).
Glassfish setz ich mit JRuby ein, da gabs bisher gar keine Probleme (ich sag nur "gem install glassfish").
Das muss aber rein gar nichts heissen, hier fehlt mir konkrete Erfahrung, um die beiden miteinander vergleichen zu koennen.
* Testing
Ich nehm JUnit, bin damit zufrieden. Fuer Webanwendungen hab ich schon Selenium hergenommen (allerdings fuer ein JRuby Projekt) und war damit recht zufrieden (nachdem das endlich auf dem CI lief... Headless-Mode & Firefox mit Selenium is der Hass ;-) ).
Man sind das viele Fragen ^^
Edit: Wenn du Git einsetzt, dann unbedingt auch Gerrit ansehen. Das Ding hat unsre Produktivitaet wirklich massiv gesteigert, da es (fast) unmoeglich ist, Build-Breaks zu verursachen. Gerrit ist ein Codereviewtool mit der genialen Eigenschaft, Commits von Teammitgliedern in einer isolierten Umgebung zu bauen und zu testen und erst wenn der Commit korrekt ist, landet er im Master-Branch. Das ist wirklich genial!
