Tasa de adopción corporativa de Git?

Recientemente surgió una discusión entre algunos colegas sobre cómo en la industria actual del software existen dos mundos separados:

  1. Orientado a FOSS
  2. Corporativo

Pregunta

¿Cuánto usa Git en entornos corporativos?

¿Cuál es su experiencia con Git en un entorno corporativo?

Por lo que vale, utilizamos git en mi lugar de trabajo. Todos están bastante contentos con eso. Por supuesto, ninguna persona en particular podrá decirle qué tan común es.

Sospecho que la prevalencia continua de cvs / svn tiene mucho más que ver con la inercia que con cualquier otra cosa. Definitivamente estuvieron entre las mejores (si no las mejores) elecciones durante mucho time **, y un gran número de desarrolladores han tenido la oportunidad de aprender a usarlas bien. Si la mayoría de su fuerza laboral ya se siente cómoda con ellos, y son lo suficientemente buenos, ¿cuántas empresas podemos realmente esperar probar algo nuevo?

Otro factor común en las decisiones de las corporaciones tiene que ver con una especie de estigma asociado al software libre. Las personas tienden a asociar el costo y el valor monetario, percibiendo que los productos más caros son mejores (Por ejemplo, he leído sobre un estudio de psicología donde a las personas se les dio el mismo vino dos veces y se les dijo que uno era más caro. como probar mejor). Con el software, hay cierta verdad en esta actitud: a menudo puede comprar alguna garantía de soporte y mantenimiento con un producto. Todos sabemos que los proyectos de código abierto establecidos pueden ganar fácilmente (más probadores, más escritores de documentation, versiones más rápidas de correcciones de errores …), pero estoy seguro de que esto todavía motiva a muchas compañías a comprar productos VCS / SCM. Sin embargo, esta no es la razón por la que las personas están usando cvs / svn.

** ¡Por favor, no flamewars! Soy un fanático acérrimo de Git, pero sé que no siempre ha existido. Por supuesto, algunos todavía no están de acuerdo, como Linus Torvalds:

Durante los primeros 10 años de mantenimiento del kernel, usamos literalmente tarballs y parches, que es un sistema de administración de control de fuente mucho mejor que CVS … El lema de Subversion por un time fue "CVS hecho bien", o algo así, y si comienzas con ese tipo de eslogan, no hay ningún lugar donde puedas ir. No hay forma de hacer CVS correctamente.

No creo que sea una opinión lo que importa, sino hechos. Además, a las empresas de código cerrado generalmente no les gusta revelar los detalles de su architecture interna. Entonces … No creo que haya una respuesta completa y correcta a esta pregunta.

Para las compañías o compañías recién establecidas que nunca han usado control de versiones antes, no hay costo de migration para git.

Y para los desarrolladores novatos, git es más adecuado porque los desarrolladores / administradores senior pueden guiarlos para "manipular" un mejor historial de revisión antes de pasar al server central. Dígales que se git commit --amend si encuentran algo malo en la historia.

Si se usa CVCS, puede producirse un caos cuando varios usuarios han cometido su código. No hay ningún lugar para practicar cómo producir un buen compromiso.

La única preocupación es el número de revisión, si necesita ese número como número de versión del producto. Porque git usa hash. Puede necesitar git describe u otro método como solución alternativa.

No lo sé, pero usamos Microsoft Visual Source Safe 6.0 . Están buscando comprar la nueva versión. Cuando propuse git o svn , me saludaron con la mano diciéndome que eran libres (como en la cerveza), por lo tanto malo.

Puedo esperar que las corporaciones usen cualquier POS que haya alnetworkingedor y que les cueste dinero desde entonces.

Descargo de responsabilidad: la publicación anterior es solo mi humilde opinión, no sé cómo se toman las decisiones.

Sospecho que la fuerza detrás de no mudarse a git no es "libre es malvado" sino que tiene un gran costo de migration. Si una gran corporación intenta migrar a otro sistema, corre el riesgo de romper algo.

El retorno monetario de mudarse a un mejor sistema debe pnetworkingecirse y compararse con los costos directos (fáciles de calcular) e indirectos (pérdida de productividad temporal, progreso de construcción interrumpido, integración con el sistema de seguimiento de errores …). Dado que nadie sabe cómo calcular los costos indirectos, los que toman las decisiones pueden preferir suponer que los costos son enormes.

Me encontré con esto mientras buscaba una manera de usar Git en mi lugar de trabajo. Lamento decepcionar, pero no estoy "en contra de" el software libre, es solo que Git no funcionará para nosotros sin ayuda. Es posible que tengas una idea de la aparición de Git si intentas entender antes de llamar a los nombres.

Intereting Posts