¿Qué ventajas prácticas ofrece Git sobre SVN o Perforce?

Wow, ¿cuánto tiempo tienes?

  • Todos los comandos además de push y fetch (y pull) son locales, lo que significa que log, diff, tag, commit, merge, branch, etc. gritan rápido y funcionan desconectados, en un avión o lo que sea
  • Git fue diseñado teniendo en cuenta la fusión, es excelente para fusionar el desarrollo divergente
  • Git es un kit de herramientas, no una herramienta monolítica, por lo que puede componer fácilmente sus propios flujos de trabajo
  • Git expone los comandos de “plomería”, por lo que puede hacer cosas avanzadas fácilmente porque tiene fácil acceso programático a las partes internas
  • Git es de código abierto, por lo que puede corregir los errores y agregar las características que desee (svn también lo es, pero forzosamente no)
  • Git permite la historia no lineal. Digamos que la persona A revisa la revisión 1, la persona B revisa la revisión 2. La persona A crea la revisión 3, la persona B crea la revisión 4. La revisión 3 agrega una función y la revisión 4 agrega una segunda función que hace lo mismo. En SVN, miras la historia y piensas “La persona B es un imbécil”. En git, miras el historial y entiendes que la revisión 4 se basó en la revisión 2, no en la revisión 3, por lo que la persona B no podría haber usado esa función. La historia de Git representa con mayor precisión lo que realmente sucedió.
  • Git permite la centralización pero no lo requiere. Para usar svn o forzar, necesita un servidor. Para usar git, vaya a un directorio y escriba “git init”. Boom, ahora tienes un repositorio git. Puede hacer que un amigo haga lo mismo, y ahora puede compartir el trabajo entre ellos y colaborar. Si lo desea, puede usar un servidor como github para hacerlo más fácil, pero es completamente opcional.
  • Git garantiza la integridad. Cada confirmación individual es nombrada por el hash sha1 de su propio contenido y todas sus confirmaciones principales. Si tengo un sha1, y usted tiene un sha1, podemos estar absolutamente seguros, módulo malware, de que tenemos contenido idéntico. Esto no es cierto sobre el rendimiento CLN 1234 o la subversión r1234. Además, esta garantía se extiende también en la historia. No hay errores de ocultación o malware en el historial de un proyecto, si algo cambia, también cambia el nombre de cada confirmación.
  • Git tiene firma de código incorporada. Porque para una seguridad realmente seria, el hashing simple no es suficiente (además, sha1 está básicamente roto ahora). Git ha incorporado instalaciones para firmar y verificar firmas en etiquetas y confirmaciones. Puede firmar cualquier cosa, pero firmar “r1234” no * significa * nada. Firmar un git sha1, por otro lado, verifica su confirmación y toda su historia, vea la viñeta de arriba.
  • Git es altamente eficiente. Almacena todo el historial en formato comprimido en delta. SVN mantiene una copia local de cada archivo, por lo que cada pago es 2 veces el tamaño del directorio de trabajo. Git almacena * el historial completo * del repositorio y aún se las arregla para ocupar MENOS espacio que SVN la mayor parte del tiempo.
  • Git es increíblemente rápido. Mientras SVN envía archivos en serie, uno a la vez (como scp), git envía un paquete de objetos comprimidos (más cerca de rsync). Esto lo hace gritar rápido. Git también, gracias a su arquitectura inteligente de estilo hash-tree, puede establecer un apretón de manos con el servidor para determinar exactamente qué objetos deben enviarse y cuáles no. Cuando cambia un archivo, realiza una confirmación y empuja, está enviando aproximadamente 2 objetos al servidor, no todo el contenido de su nuevo árbol de trabajo.

Intentemos responder a la pregunta opuesta: ¿por qué debería quedarse con SVN en lugar de cambiar a SVN (no tengo idea sobre el rendimiento así que excluirlo aquí):

  • El concepto de servidor central es más fácil de entender que un entorno distribuido
  • Debe comprender al menos el concepto básico detrás de git para usar todos sus poderes (al menos un miembro de un equipo debe tener un conocimiento detallado, el resto puede funcionar con pull + merge + push al menos para el comienzo)
  • Muchos nuevos conceptos y palabras para aprender (alijo, índice, rebase, cherrypick, pull + push + fetch, …)
  • Las páginas de ayuda de Git pueden ser dolorosas de leer.

¿Qué extrañas? Nunca lo sabrás hasta que lo hayas probado. Agregué una capa git opcional sobre TFS (¿similar a forzar?) Quizás hace dos años en el trabajo. Unos meses más tarde todos lo estaban usando y nadie quiere volver. Cosas que más nos gustan:

  • Actuación. Incluso debajo de las ventanas. Para casi todas las operaciones.
  • Podemos trabajar sin conexión (el servidor central está a 9 zonas horarias de distancia)
  • Guardar cambios, incluido el historial, sin ponerlos en la línea principal (ramas de funciones fáciles)
  • Mover código entre PC fácilmente (de nuevo con ramas de funciones)
  • Arreglar errores tontos sin que nadie lo note (enmendar)
  • ¡Culpa! ¡¡En segundos!! (¿Quién cambió esa línea y por qué?)
  • No es mucho lo que no puedes hacer con git: ¿borrar un archivo del historial? ¿Cambiar el nombre de un autor en cada commit? ¿Fusionar un repositorio en otro? ¿Crear un nuevo repositorio desde una subcarpeta? ¡No hay problema! (bueno … al menos es posible;))

He usado tanto Svn como git durante muchos años. Tu perspectiva me parece demasiado perlada, y tus premisas son extrañas.

  • No hace que los “commits sean más complicados”; en realidad, git es mucho más ergonómico que Svn en el uso diario (solo –p solo es una característica asesina).
  • No es que los compromisos locales sean “mejores”; solo que puede hacerlo si su flujo de trabajo lo sugiere. Uno podría argumentar igualmente que el repositorio central no necesita ver cada confirmación WIP, o estar sujeto a la inflexibilidad que eso implica.
  • ¿De qué manera el compromiso local no funciona bien con las “pruebas unitarias automatizadas”? Obviamente funciona bien con las pruebas unitarias locales (sus desarrolladores pueden ejecutar pruebas unitarias locales en trabajos no comprometidos o comprometidos, ¿no?), Y las ramas de características se pueden probar de forma remota en cualquier momento (esta es una configuración trivial de CI / CD que nosotros usar en la mayoría de los proyectos).
  • ¿Falla del disco duro? Si tiene desarrolladores que trabajan en sucursales durante días, semanas, meses, para que eso sea de algún interés como riesgo, es probable que sea un antipatrón que deba abordar de todos modos. Pero … tenemos una solución para la “falla del disco duro” y no está obligando a las confirmaciones remotas; son copias de seguridad, que son necesarias sin importar qué VCS use.

Lo que te falta es la experiencia real con Git para hacer una comparación realista.

Las confirmaciones locales le permiten preparar el parche mucho mejor antes de cargarlo. Puede tener varias versiones del mismo parche y solo cargar la que desee. Por lo general, estos parches tienen un solo propósito.

Trabajo con Android, y Android se distribuye en alrededor de 1000 repositorios git separados (uno para cada aplicación / módulo). Además, cada repositorio tiene un espejo de las mismas ramas que corresponden a un proyecto separado.

El 99% de las veces todos los proyectos comparten el mismo código. Así que simplemente agarra el parche de una rama y lo coloca en otra. Para los lugares que difieren, por ejemplo, el código específico del conjunto de chips, desea la capacidad de extraer un parche de una rama que normalmente no usa pero comparte el mismo conjunto de chips, y aplicarlo a su proyecto.

Básicamente, lo que sucede es que divide el código en commits y lo vuelve a armar en otro lugar. Esto le brinda mucha libertad y tiene un gran beneficio que simplifica su trabajo considerablemente y le proporciona un arnés adecuado para la seguridad. Las cosas que son fáciles de hacer son útiles. Las cosas que son dañinas son difíciles de hacer.

Además, estos pequeños parches son muy fáciles de administrar y revisar código. Especialmente usando cosas como gerrit.