Git vs Team Foundation Server [cerrado]
Presenté Git a mi equipo de desarrollo y todos lo odian excepto yo. Quieren reemplazarlo con Team Foundation Server. Siento que esto es un gran paso atrás, aunque no estoy muy familiarizado con TFS. ¿Alguien con experiencia puede comparar el soporte de bifurcación en TFS con la bifurcación de Git? Además, en general, ¿cuáles son los pros y los contras de TFS? ¿Voy a odiarlo después de usar Git durante algunos años?
Creo que la declaración
todos lo odian menos yo
hace que cualquier discusión adicional sea un desperdicio: cuando sigas usando Git, te culparán si algo sale mal.
Aparte de esto, para mí Git tiene dos ventajas sobre un VCS centralizado que aprecio más (como lo describe en parte Rob Sobers ):
- Copia de seguridad automática de todo el repositorio: cada vez que alguien accede al repositorio central, obtiene un historial completo de los cambios. Cuando se pierde un repositorio: no te preocupes, toma uno de los presentes en cada estación de trabajo.
- Acceso al repositorio sin conexión: cuando estoy trabajando en casa (o en un avión o tren), puedo ver el historial completo del proyecto, cada registro, sin iniciar mi conexión VPN para trabajar y puedo trabajar como si estuviera en el trabajo . : check-in, check-out, sucursal, cualquier cosa.
Pero como dije: creo que estás librando una batalla perdida: cuando todos odian Git, no uses Git. Podría ayudarte más saber por qué odian a Git en lugar de intentar convencerlos.
Si simplemente no lo quieren porque es nuevo para ellos y no están dispuestos a aprender algo nuevo: ¿está seguro de que realizará un desarrollo exitoso con ese personal?
¿Realmente todas las personas odian a Git o están influenciadas por algunos líderes de opinión? Encuentre a los líderes y pregúnteles cuál es el problema. Convéncelos y convencerás al resto del equipo.
Si no puedes convencer a los líderes: olvídate de usar Git, elige TFS. Te hará la vida más fácil.
La diferencia clave entre los dos sistemas es que TFS es un sistema de control de versiones centralizado y Git es un sistema de control de versiones distribuido.
Con TFS, los repositorios se almacenan en un servidor central y los desarrolladores obtienen una copia de trabajo, que es una instantánea del código en un momento específico. Con Git, los desarrolladores clonan todo el repositorio en sus máquinas, incluido todo el historial.
Un beneficio de tener el repositorio completo en las máquinas de su desarrollador es la redundancia en caso de que el servidor falle. Otra buena ventaja es que puedes mover tu copia de trabajo de un lado a otro entre revisiones sin siquiera hablar con el servidor, lo que puede ser útil si el servidor no funciona o simplemente no se puede acceder a él.
Para mí, la verdadera ventaja es que puedes enviar conjuntos de cambios a tu repositorio local sin siquiera hablar con el servidor o infligir cambios potencialmente inestables en tu equipo (es decir, romper la compilación).
Por ejemplo, si estoy trabajando en una función importante, puede que me lleve una semana codificarla y probarla por completo. No quiero registrar el código inestable a mitad de semana y romper la compilación, pero ¿qué sucede si me acerco al final de la semana y accidentalmente borré toda mi copia de trabajo? Si no me he comprometido todo el tiempo, corro el riesgo de perder mi trabajo. Ese no es un control de versiones efectivo y TFS es susceptible a esto.
Con DVCS, puedo confirmar constantemente sin preocuparme por interrumpir la compilación, porque estoy confirmando mis cambios localmente . En TFS y otros sistemas centralizados no existe el concepto de check-in local.
Ni siquiera he explicado cuánto mejor es la ramificación y la fusión en DVCS, pero puedes encontrar toneladas de explicaciones aquí en SO o a través de Google. Puedo decirles por experiencia que ramificarse y fusionarse en TFS no es bueno.
Si el argumento a favor de TFS en su organización es que funciona mejor en Windows que Git, sugeriría Mercurial, que funciona muy bien en Windows; hay integración con Windows Explorer (TortoiseHg) y Visual Studio (VisualHg).
La gente necesita dejar el arma, alejarse de la cornisa y pensar por un minuto. Resulta que DVCS tiene ventajas objetivas, concretas e innegables que marcarán una ENORME diferencia en la productividad de un equipo.
Todo se reduce a ramificar y fusionar.
Antes de DVCS, el principio rector era "Ora a Dios para que no tengas que ramificarte y fusionarte. Y si lo haces, al menos pídele que te permita ser muy, muy simple".
Ahora, con DVCS, la ramificación ( y la fusión ) ha mejorado tanto que el principio rector es: "Hazlo en un abrir y cerrar de ojos. Te brindará muchísimos beneficios y no te causará ningún problema".
Y eso supone un ENORME impulso a la productividad para cualquier equipo.
El problema es que, para que la gente entienda lo que acabo de decir y esté convencida de que es verdad, primero tienen que invertir en una pequeña curva de aprendizaje. No tienen que aprender Git ni ningún otro DVCS... sólo necesitan aprender cómo Git realiza ramificaciones y fusiones. Lea y vuelva a leer algunos artículos y publicaciones de blogs, tómelo con calma y analícelos hasta que los vea. Eso podría llevar la mayor parte de 2 o 3 días completos.
Pero una vez que vea eso, ni siquiera considerará elegir un sistema que no sea DVCS. Porque realmente existen ventajas claras, objetivas y concretas para DVCS, y las mayores ganancias se encuentran en el área de ramificación y fusión.
Original : @Rob, TFS tiene algo llamado " Shelving " que aborda su preocupación sobre la confirmación del trabajo en progreso sin que afecte la compilación oficial. Me doy cuenta de que ve el control de versiones central como un obstáculo, pero con respecto a TFS, registrar su código en el estante puede verse como una ventaja porque, en el raro caso, el servidor central tiene una copia de su trabajo en progreso. su máquina local falla, se pierde o se la roban, o necesita cambiar de marcha rápidamente. Mi punto es que TFS debería recibir los elogios adecuados en esta área. Además, la bifurcación y fusión en TFS2010 se ha mejorado con respecto a versiones anteriores, y no está claro a qué versión se refiere cuando dice "... por experiencia, que la bifurcación y fusión en TFS no es buena". Descargo de responsabilidad: soy un usuario moderado de TFS2010.
Editar 5 de diciembre de 2011 : Para el OP, una cosa que me molesta de TFS es que insiste en configurar todos sus archivos locales en "solo lectura" cuando no está trabajando en ellos. Si desea realizar un cambio, el flujo es que debe "proteger" el archivo, lo que simplemente borra el atributo de solo lectura del archivo para que TFS sepa que debe vigilarlo. Ese es un flujo de trabajo inconveniente. La forma en que preferiría que funcionara es que simplemente detecta automáticamente si he realizado un cambio y no se preocupa ni molesta en absoluto con los atributos del archivo. De esa manera, puedo modificar el archivo en Visual Studio, en el Bloc de notas o con cualquier herramienta que desee. El sistema de control de versiones debe ser lo más transparente posible a este respecto. Existe una extensión del Explorador de Windows ( TFS PowerTools ) que le permite trabajar con sus archivos en el Explorador de Windows, pero eso no simplifica mucho el flujo de trabajo.
