¿Por qué Git es mejor que Subversion?
He estado usando Subversion durante algunos años y después de usar SourceSafe , me encanta Subversion. Combinado con TortoiseSVN , realmente no puedo imaginar cómo podría ser mejor.
Sin embargo, hay un número creciente de desarrolladores que afirman que Subversion tiene problemas y que deberíamos pasar a la nueva generación de sistemas de control de versiones distribuidos, como Git .
¿Cómo mejora Git a Subversion?
Git no es mejor que Subversion. Pero tampoco es peor. Es diferente.
La diferencia clave es que está descentralizado. Imagine que es un desarrollador que está de viaje, desarrolla en su computadora portátil y desea tener control de fuente para poder retroceder 3 horas.
Con Subversion, tiene un problema: el repositorio SVN puede estar en una ubicación a la que no puede acceder (en su empresa y no tiene Internet en este momento), no puede comprometerse. Si desea hacer una copia de su código, literalmente debe copiarlo y pegarlo.
Con Git, no tienes este problema. Su copia local es un repositorio y puede comprometerse con ella y obtener todos los beneficios del control de código fuente. Cuando recupere la conectividad con el repositorio principal, podrá comprometerse con él.
Esto parece bueno al principio, pero tenga en cuenta la complejidad adicional de este enfoque.
Git parece ser lo "nuevo, brillante y genial". No es de ninguna manera malo (después de todo, hay una razón por la que Linus lo escribió para el desarrollo del Kernel de Linux), pero siento que muchas personas se suben al tren del "Control de fuente distribuida" solo porque es nuevo y está escrito por Linus Torvalds, sin realmente saber por qué/si es mejor.
Subversion tiene problemas, pero también Git, Mercurial, CVS, TFS o lo que sea.
Editar: Esta respuesta tiene ahora un año y todavía genera muchos votos a favor, así que pensé en agregar algunas explicaciones más. En el último año desde que escribí esto, Git ha ganado mucho impulso y apoyo, particularmente desde que sitios como GitHub realmente despegaron. Estoy usando Git y Subversion hoy en día y me gustaría compartir algunas ideas personales.
En primer lugar, Git puede resultar muy confuso al principio cuando se trabaja de forma descentralizada. ¿Qué es un control remoto? y ¿Cómo configurar correctamente el repositorio inicial? Hay dos preguntas que surgen al principio, especialmente en comparación con el simple "svnadmin create" de SVN, el "git init" de Git puede tomar los parámetros --bare y --shared, lo que parece ser la forma "adecuada" de configurar una configuración centralizada. repositorio. Hay razones para esto, pero añade complejidad. La documentación del comando "checkout" es muy confusa para las personas que cambian: la forma "correcta" parece ser "git clone", mientras que "git checkout" parece cambiar de rama.
Git REALMENTE brilla cuando estás descentralizado. Tengo un servidor en casa y una computadora portátil mientras estoy de viaje, y SVN simplemente no funciona bien aquí. Con SVN, no puedo tener control de fuente local si no estoy conectado al repositorio (Sí, conozco SVK o las formas de copiar el repositorio). Con Git, ese es el modo predeterminado de todos modos. Sin embargo, es un comando adicional (git commit confirma localmente, mientras que git push origin master empuja la rama maestra al control remoto llamado "origen").
Como se dijo anteriormente: Git agrega complejidad. Dos modos de crear repositorios, verificar versus clonar, confirmar versus enviar... Tienes que saber qué comandos funcionan localmente y cuáles funcionan con "el servidor" (supongo que a la mayoría de la gente todavía le gusta un "repositorio maestro" central ).
Además, las herramientas siguen siendo insuficientes, al menos en Windows. Sí, hay un complemento de Visual Studio, pero sigo usando git bash con msysgit.
SVN tiene la ventaja de que es MUCHO más sencillo de aprender: ahí está su repositorio, todos los cambios se realizan hacia él, si sabe cómo crear, confirmar y pagar y está listo para comenzar y puede recoger cosas como bifurcaciones, actualizaciones, etc. más adelante. en.
Git tiene la ventaja de que es MUCHO más adecuado si algunos desarrolladores no siempre están conectados al repositorio principal. Además, es mucho más rápido que SVN. Y por lo que he oído, el soporte para ramificaciones y fusiones es mucho mejor (lo cual es de esperar, ya que estas son las razones principales por las que se escribió).
Esto también explica por qué genera tanta expectación en Internet, ya que Git se adapta perfectamente a proyectos de código abierto: simplemente bifurque, confirme sus cambios en su propio bifurcación y luego pídale al responsable del proyecto original que realice los cambios. Con Git, esto simplemente funciona. De verdad, pruébalo en Github, es mágico.
Lo que también veo son puentes Git-SVN: el repositorio central es un repositorio de Subversion, pero los desarrolladores trabajan localmente con Git y el puente luego envía sus cambios a SVN.
Pero incluso con esta larga adición, sigo manteniendo mi mensaje central: Git no es mejor ni peor, simplemente es diferente. Si necesita "Control de fuente sin conexión" y está dispuesto a dedicar más tiempo a aprenderlo, es fantástico. Pero si tiene un control de fuente estrictamente centralizado y/o tiene dificultades para introducir el control de fuente en primer lugar porque sus compañeros de trabajo no están interesados, entonces la simplicidad y las excelentes herramientas (al menos en Windows) de SVN brillan.
Con Git, puedes hacer prácticamente cualquier cosa sin conexión, porque cada uno tiene su propio repositorio.
Crear ramas y fusionarlas es realmente fácil.
Incluso si no tiene derechos de confirmación para un proyecto, aún puede tener su propio repositorio en línea y publicar "solicitudes push" para sus parches. Cualquiera a quien le gusten sus parches puede incorporarlos a su proyecto, incluidos los mantenedores oficiales.
Es trivial bifurcar un proyecto, modificarlo y seguir fusionándolo en las correcciones de errores de la rama HEAD.
Git funciona para los desarrolladores del kernel de Linux. Eso significa que es realmente rápido (tiene que serlo) y se adapta a miles de contribuyentes. Git también utiliza menos espacio (hasta 30 veces menos espacio para el repositorio de Mozilla).
Git es muy flexible, muy TIMTOWTDI (Hay más de una forma de hacerlo). Puede utilizar cualquier flujo de trabajo que desee y Git lo admitirá.
Finalmente, está GitHub , un excelente sitio para alojar sus repositorios Git.
Desventajas de Git:
- es mucho más difícil de aprender porque Git tiene más conceptos y más comandos.
- las revisiones no tienen números de versión como en subversion
- Muchos comandos de Git son crípticos y los mensajes de error son muy poco amigables para el usuario.
- carece de una buena GUI (como la gran TortoiseSVN )
Otras respuestas han hecho un buen trabajo al explicar las características principales de Git (que son geniales). Pero también hay muchas pequeñas formas en las que Git se comporta mejor y me ayuda a mantener mi vida más sana. Estas son algunas de las pequeñas cosas:
- Git tiene un comando "limpio". SVN necesita desesperadamente este comando, considerando la frecuencia con la que volcará archivos adicionales en su disco.
- Git tiene el comando 'bisectar'. Es agradable.
- SVN crea directorios .svn en cada carpeta (Git solo crea un directorio .git). Cada script que escriba y cada grep que realice deberá escribirse para ignorar estos directorios .svn. También necesita un comando completo ("svn export") sólo para obtener una copia sana de sus archivos.
- En SVN, cada archivo y carpeta puede provenir de una revisión o rama diferente. Al principio, suena bien tener esta libertad. Pero lo que esto realmente significa es que hay un millón de formas diferentes de arruinar completamente su caja local. (por ejemplo, si "svn switch" falla a la mitad o si ingresa un comando incorrecto). Y la peor parte es: si alguna vez te encuentras en una situación en la que algunos de tus archivos provienen de un lugar y otros de otro, el "estado svn" te dirá que todo es normal. Necesitará hacer "svn info" en cada archivo/directorio para descubrir qué tan raras son las cosas. Si el "estado de git" te dice que las cosas son normales, entonces puedes confiar en que las cosas realmente son normales.
- Tienes que informar a SVN cada vez que mueves o eliminas algo. Git simplemente lo resolverá.
- Ignorar la semántica es más fácil en Git. Si ignora un patrón (como *.pyc), se ignorará para todos los subdirectorios. (Pero si realmente desea ignorar algo para un solo directorio, puede hacerlo). Con SVN, parece que no hay una manera fácil de ignorar un patrón en todos los subdirectorios.
- Otro elemento relacionado con ignorar archivos. Git hace posible ignorar configuraciones "privadas" (usando el archivo .git/info/exclude), lo que no afectará a nadie más.
