Git vs Team Foundation Server [cerrado]

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, incluyendo todo el historial.

Un beneficio de tener el repositorio completo en las máquinas de su desarrollador son redundantes en caso de que el servidor muera. Otra buena ventaja es que puede mover su copia de trabajo de un lado a otro entre revisiones sin hablar con el servidor, lo que puede ser útil si el servidor está inactivo o simplemente no se puede contactar.

Para mí, la verdadera ventaja es que puedes enviar conjuntos de cambios a tu repositorio local sin hablar con el servidor o infligir cambios potencialmente inestables en tu equipo (es decir, romper la compilación).

Para ejemplo, si estoy trabajando en una característica grande, me podría tomar una semana para codificar y probarlo 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 borro toda mi copia de trabajo? Si no me he comprometido todo el tiempo corro el riesgo de perder mi trabajo. Eso no es un control de versiones efectivo, y TFS es susceptible a esto.

Con DVCS, puedo comprometerme constantemente sin preocuparme por romper el build, porque estoy confirmando mis cambios localmente. En TFS y otros sistemas centralizados no existe el concepto de un check-in local.

Ni siquiera he entrado en cuánto mejor ramificación y fusión es en DVCS, pero usted puede encontrar toneladas de explicaciones aquí en SO o a través de Google. Puedo decirles por experiencia que ramificar y fusionar en TFS no es bueno.

Si el argumento para TFS en su organización es que funciona mejor en Windows que Git, sugeriría Mercurial, que funciona muy bien en Windows there hay integración con el Explorador de Windows (TortoiseHg) y Visual Studio (VisualHg).

La gente necesita bajar el arma, alejarse de la cornisa, y pensar por un minuto. Resulta que hay ventajas objetivas, concretas e innegables para los DVC que marcarán una GRAN diferencia en la productividad de un equipo.

Todo se reduce a Ramificar y Fusionar.

Antes de DVCS, el principio guía era "Ora a Dios para que no tengas que entrar en ramificación y fusión. Y si lo haces, al menos pídele que lo deje ser muy, muy simple."

Ahora, con DVCS, ramificación ( y la fusión) es mucho mejor, el principio rector es, "Hacerlo en la gota de un sombrero. Le dará un montón de beneficios y no le causará ningún problema."

Y eso es un GRAN refuerzo de productividad para cualquier equipo.

El problema es que, para que la gente entienda lo que acabo de decir y se convenza de que es verdad, primero tienen que invertir en una pequeña curva de aprendizaje. No tienen que aprender Git o cualquier otro DVC en sí ... solo necesitan aprender cómo hace Git ramificando y fusionando. Lee y relee algunos artículos y publicaciones de blog, tomándolo con calma y trabajando hasta que lo veas. Eso podría tomar la mayor parte de 2 o 3 días completos.

Pero una vez que vea eso, ni siquiera considerará elegir un no DVCS. Porque realmente hay ventajas claras, objetivas y concretas para los DVC, y las mayores ganancias están en el área de ramificación y fusión.

Original : @Rob, TFS tiene algo llamado " Shelving" que aborda tu preocupación por comprometer el trabajo en progreso sin que afecte a la compilación oficial. Me doy cuenta de que ve el control de versiones central como un obstáculo, pero con respecto a TFS, la comprobación de su código en el estante se puede ver como una fuerza b/c, entonces el servidor central tiene una copia de su trabajo en progreso en el raro caso de que su máquina local se bloquee o se pierda/robe o necesite cambiar de marcha rápidamente. Mi el punto es que TFS debe ser elogiado adecuadamente en esta área. Además, la ramificación y la fusión en TFS2010 se ha mejorado de las versiones anteriores, y no está claro a qué versión se refiere cuando dice"... por experiencia, la ramificación y fusión en TFS no es buena."Descargo de responsabilidad: Soy un usuario moderado de TFS2010.

Editar Dic-5-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 "revisar" el archivo, lo que simplemente borra el atributo readonly en el archivo para que TFS sepa que debe vigilarlo. Es un flujo de trabajo inconveniente. La forma en que preferiría que funcionara es que simplemente detecta automáticamente si he hecho un cambio y no se preocupa/molesta con los atributos del archivo en absoluto. De esta manera, puedo modificar el archivo ya sea en Visual Studio, o Bloc de notas, o con cualquier herramienta que me plazca. El sistema de control de versiones debe ser lo más transparente posible a este respecto. Hay una extensión del Explorador de Windows ( TFS PowerTools ) que le permite trabajar con sus archivos en el Explorador de Windows, pero que no simplifica mucho el flujo de trabajo.

Además de todo lo que se ha dicho (

Https://stackoverflow.com/a/4416666/172109

Https://stackoverflow.com/a/4894099/172109

Https://stackoverflow.com/a/4415234/172109

), lo cual es correcto, TFS no es solo un VCS. Una característica importante que proporciona TFS es la funcionalidad de seguimiento de errores integrada de forma nativa. Los conjuntos de cambios están vinculados a problemas y podrían rastrearse. Varias políticas para check-ins son compatible, así como la integración con el dominio de Windows, que es lo que tienen las personas que ejecutan TFS. La interfaz gráfica de usuario estrechamente integrada con Visual Studio es otro punto de venta, que atrae a menos que el promedio mouse and click developer y su gerente.

Por lo tanto, comparar Git con TFS no es una pregunta adecuada. La pregunta correcta, aunque poco práctica, es comparar Git con solo la funcionalidad de VCS de TFS. En eso, Git sopla TFS fuera del agua. Sin embargo, cualquier equipo serio necesita otras herramientas y aquí es donde TFS proporciona un destino de parada.

Si tu equipo usa TFS y quieres usar Git, es posible que quieras considerar un puente de "git a tfs". Esencialmente trabajas día a día usando Git en tu computadora, luego cuando quieres enviar tus cambios los envías al servidor TFS.

Hay un par por ahí (en github). Usé uno en mi último lugar (junto con otro desarrollador) con cierto éxito. Véase:

Https://github.com/spraints/git-tfs

Https://github.com/git-tfs/git-tfs

Después de algunas investigaciones entre los pro y los contras, la compañía con la que estaba involucrado también decidió ir por TFS. No porque GIT no sea un buen sistema de control de versiones, sino lo más importante para la solución ALM totalmente integrada que ofrece TFS. Si solo la función de control de versiones era importante, la elección probablemente podría haber sido GIT. Sin embargo, la curva de aprendizaje GIT empinada para los desarrolladores regulares no puede subestimarse.

Ver una explicación detallada en mi entrada de blog TFS como un verdadero plataforma tecnológica cruzada.

Todo lo distribuido de Git es realmente genial. da algunas características que los Shelvesets no tienen (en el producto actual) como las opciones locales de reversión y confirmación (como La característica localhistory de Eclipse). Podría aliviar esto usando ramas de desarrolladores, pero seamos honestos, a muchos desarrolladores no les gusta ramificar y fusionar un poco. Me han pedido que active la función de "pago exclusivo" de estilo antiguo en TFS un par de veces con demasiada frecuencia (y me lo han negado todas y cada una tiempo).

Creo que muchas grandes empresas tienen bastante miedo de permitir que un desarrollador simplemente traiga toda la historia a un espacio de trabajo local y se la lleve (a un nuevo empleador, por ejemplo)... Robar una instantánea es malo, pero quitar toda una historia es aún más problemático. (No es que no pudieras obtener un historial completo de TFS de lo que querías)...

Se menciona que es una gran manera de hacer copias de seguridad, lo cual es genial para el código abierto nuevamente donde el mantenedor original podría detenerse para cuidar y elimina su versión, pero para un plan empresarial esto de nuevo se queda corto para muchas empresas, ya que no hay una asignación clara de responsabilidad para mantener copias de seguridad. Y sería difícil averiguar qué versión usar si el 'proyecto' principal desaparece de alguna manera. Lo que tendería a designar un repositorio como principal / central.

Lo que más me gusta de Git es la opción Push/Pull, donde puedes contribuir fácilmente código a un proyecto sin la necesidad de tener derechos de confirmación. Supongo que podría usar usuarios y shelvesets muy limitados en TFS para imitar esto, pero no es tan poderoso como la opción Git. La ramificación entre proyectos de equipo también podría funcionar, pero desde una perspectiva administrativa no es realmente factible para muchas organizaciones, ya que agregar proyectos de equipo agrega una gran cantidad de gastos administrativos.

También me gustaría añadir a las cosas mencionadas en el área de control no fuente. Características como el Seguimiento de los Artículos de Trabajo, la generación de informes y la automatización de la compilación (incluida la gestión del laboratorio) benefíciese enormemente de un repositorio central líder. Estos se vuelven mucho más difíciles cuando se utiliza un modelo distribuido puro, a menos que se haga uno de los nodos principales (y por lo tanto volver a un modelo menos distribuido).

Con TFS Basic que viene con TFS 11, podría no estar lejos de esperar un TFS distribuido que le permita sincronizar su TFS basic local con un TFS central en la era TFS 12+. Voy a poner mi voto por eso en el uservoice !

Para mí la principal diferencia son todos los archivos ancilliary que TFS agregará a su solución (.vssscc) para' soportar ' TFS - hemos tenido problemas recientes con estos archivos que terminan asignados a la rama incorrecta, lo que lleva a una depuración interesante...