¿Qué control de fuente necesito para un proyecto grande en una empresa promedio? [cerrado]

Sé que Git es ideal para proyectos de código abierto. Pero me preguntaba: para una empresa con 20 programadores que trabajan en un proyecto de 1 año, ¿qué sistema de control de fuente es deseable? Por lo que escuché, Git usa tirar; ¿No sería menos que deseable tener que pasar por otra persona para obtener sus cambios en el tronco principal? ¿Especialmente cuando todos trabajan al mismo tiempo?

Ese es solo un ejemplo del que me preguntaba. Sé cómo usar SVN, pero incluso en mi último trabajo no lo usamos en nuestros proyectos, ya que todo se hizo en PHP y, por lo general, eran proyectos independientes de 1 semana. Acabo de tener SVN para mi código local y no necesitaba usarlo con otros.

Entonces, ¿qué son buenos controles de fuente y específicamente por qué es bueno para esto?

Use lo que su equipo le resulte cómodo. Todos los sistemas de control de versiones hacen aproximadamente lo mismo de manera similar; no hay razón para reinventar la rueda porque "podría funcionar mejor". Si su equipo no se siente cómodo con nada, elija la opción que tenga la integración más fácil con el IDE estándar de su equipo.

Mercurial es excelente, distribuido y gratuito.

Creo que depende del nivel de soporte que necesite.

Uso git en casa para mis proyectos divertidos cuando tener un problema me cuesta tiempo, pero puedo pasar el tiempo aprendiendo lo que necesito para solucionarlo.

En el trabajo utilizamos Perforce porque es imprescindible contar con soporte técnico 24/7. Tenemos personas trabajando en el código en Nueva York, Alemania, Irlanda y Japón todo el tiempo. Si hay un problema, tenemos que obtener una respuesta lo antes posible. En mi experiencia, las personas en Perforce realmente saben lo que están haciendo y son receptivas a las sugerencias.

Si bien creo que esta pregunta es amplia y debería abordarse por empresa, en función de su marco de TI y las estructuras de red / desarrollo, creo que el aspecto más importante de elegir el control de fuente / versión no es qué aplicación utiliza, pero si su uso está prácticamente estructurado y aplicado.

La estructura y la aplicación del uso son los aspectos más importantes del control de versiones.

Planifique con anticipación y haga que todos participen. Hacer cumplir el uso. No solo con programadores, sino con todo lo relacionado con proyectos (documentos, imágenes, etc.).

SVN es una buena aplicación, y se puede integrar con muchos complementos (incluido el seguimiento de errores / tareas), no necesita un servidor separado y es gratis.

También hay otras buenas aplicaciones de control de fuente, como dijo @EricBoersma:

Use lo que su equipo le resulte cómodo.

Simplemente tenga los procesos y las mejores prácticas en su lugar, y compre a aquellos que puedan imponerlo.

Tienes algunas ideas erróneas sobre cómo funciona git. Enviar una solicitud de extracción a un controlador de acceso es solo una forma de hacerlo. Hay muchas otras formas de configurarlo, incluso exactamente como svn, que es exactamente cuántas personas comienzan antes de que se sientan lo suficientemente cómodas para personalizar. Con un DVCS como git, tiene suficientes opciones para estructurar su control de origen en torno a su flujo de trabajo, en lugar de al revés.

Solía ​​tener la opinión de que el control de código fuente era solo una herramienta, y que cada uno de los productos hacía más o menos lo mismo. Y luego el punto de estos sistemas de control de versiones distribuidos hizo clic conmigo.

El control de versiones distribuido le permite tener más de un repositorio central. Imagine los cambios de código que migran desde el repositorio del desarrollador local, al repositorio de características, al repositorio del producto, al repositorio de QA y finalmente al repositorio lanzado.

Personalmente utilizo un producto comercial llamado Kiln, que se basa en Hg, pero la característica clave es el control de versión distribuido . Revoluciona el flujo de nuevo código del desarrollador a un producto lanzado.

Usted sabe cómo usar SVN, luego use SVN: solo migre a un DVCS si necesita algo en ellos.

Lo realmente importante es que use algo que le guste usar, que sea fácil de usar. Martin Fowler realizó una encuesta rápida y simple sobre VCS, los resultados son muy interesantes.

Configuré git en mi último trabajo donde estábamos trabajando en un proyecto de tamaño similar (15 desarrolladores, proyecto de 18 meses) y funcionó bien.

La forma en que lo configuramos fue:

Teníamos un servidor git que era nuestro servidor git autorizado centralizado. Se desaconsejó que los miembros del equipo se separaran directamente para que todos los cambios fueran al servidor central.

Utilizamos la rama maestra como la rama de producción principal, con etiquetas para cada lanzamiento. Cada módulo en el proyecto era un submódulo git. Cada submódulo tenía ramas para cada miembro del equipo. Se asignó un mantenedor (generalmente el autor original) a cada submódulo, y fueron responsables de manejar las solicitudes de extracción de otros miembros del equipo y de emitir solicitudes de extracción al líder del equipo que actualizaría el submódulo en la rama principal cuando estuviera listo para integrarse en la rama de producción. Utilizamos etiquetas para identificar confirmaciones que completaron una característica específica, o que correspondían a un lanzamiento.

Le daría al Team Foundation System (TFS) de Microsoft al menos un buen aspecto. De sus comentarios deduzco que no es una tienda de Microsoft. Sin embargo, según tengo entendido, es que hay un complemento Eclipse bastante robusto si usas ese IDE para el desarrollo.

Los mecanismos de fusión y ramificación funcionan tan bien como cualquiera de los otros sistemas de control de fuente (mejor que svn, en mi experiencia, y casi tan buenos como el rendimiento), pero lo que realmente brilla son los aspectos de seguimiento y gestión de proyectos del producto, y La automatización integrada para compilaciones y despliegues.

Si está escribiendo una aplicación basada en la web, eche un vistazo al marco de prueba de IU automatizado y al marco de prueba de carga que puede construir y configurar en un tiempo bastante corto. Una característica elegante: simulación de navegadores móviles integrados en las pruebas de carga.