Le presenté a Git a mi equipo de desarrollo, y todos lo odian excepto yo. Quieren reemplazarlo con Team Foundation Server. Siento que este es un gran paso atrás, aunque no estoy muy familiarizado con TFS. ¿Alguien con experiencia puede comparar el soporte de ramificación en TFS con la ramificación de Git? Además, en general, ¿cuáles son los pros y los contras de TFS? ¿Lo odiaré después de usar Git durante algunos años?
263
Respuestas:
Creo que la declaración
hace que los residuos más discusión: cuando se mantenga el uso de Git, van a culpar que si algo va mal.
Además de esto, para mí Git tiene dos ventajas sobre un VCS centralizado que más aprecio (como lo describió en parte Rob Sobers ):
Pero como dije: creo que estás luchando en una batalla perdida: cuando todos odian a 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ás seguro de que harás un desarrollo exitoso con ese personal?
¿Realmente todas las personas odian a Git o están influenciadas por algunos líderes de opinión? Encuentra a los líderes y pregúntales cuál es el problema. Convénzalos y convencerás al resto del equipo.
Si no puedes convencer a los líderes: olvídate de usar Git, toma el TFS. Te hará la vida más fácil.
fuente
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 extraen una copia de trabajo, que es una instantánea del código en un momento específico. Con Git, los desarrolladores clonan el repositorio completo en sus máquinas, incluida toda la historia.
Una ventaja de tener el repositorio completo en las máquinas de su desarrollador es la redundancia en caso de que el servidor falle. Otro beneficio adicional es que puede mover su copia de trabajo de un lado a otro entre revisiones sin tener que hablar con el servidor, lo que puede ser útil si el servidor está inactivo o simplemente no se puede acceder.
Para mí, la verdadera bendición es que puede enviar conjuntos de cambios a su repositorio local sin hablar con el servidor ni infligir cambios potencialmente inestables en su equipo (es decir, romper la compilación).
Por ejemplo, si estoy trabajando en una función grande, podría llevarme 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 estoy acercando al final de la semana y accidentalmente borro toda mi copia de trabajo? Si no he estado comprometiéndome todo el tiempo, corro el riesgo de perder mi trabajo. Eso no es un control de versión efectivo, y TFS es susceptible a esto.
Con DVCS, puedo comprometerme constantemente sin preocuparme por romper la compilación, porque estoy comprometiendo mis cambios localmente . En TFS y otros sistemas centralizados no existe el concepto de un registro local.
Ni siquiera me he referido a la mejor ramificación y fusión en DVCS, pero puedes encontrar toneladas de explicaciones aquí en SO o en Google. Puedo decirle 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: hay integración con Windows Explorer (TortoiseHg) y Visual Studio (VisualHg).
fuente
La gente necesita bajar el arma, alejarse de la repisa y pensar por un minuto. Resulta que hay ventajas objetivas, concretas e innegables para DVCS que marcarán una GRAN diferencia en la productividad de un equipo.
Todo se reduce a Ramificación y Fusión.
Antes de DVCS, el principio rector era "Reza a Dios para que no tengas que ramificarte y fusionarte. Y si lo haces, al menos suplícale que sea muy, muy simple".
Ahora, con DVCS, la ramificación ( y fusión ) se ha mejorado mucho, el principio rector es: "Hágalo de inmediato . Le dará muchos beneficios y no le causará ningún problema".
Y eso es un ENORME refuerzo de productividad para cualquier equipo.
El problema es que, para que la gente entienda lo que acabo de decir y esté convencida de que es cierto, primero tienen que invertir en una pequeña curva de aprendizaje. No tienen que aprender Git o cualquier otro DVCS en sí mismo ... solo necesitan aprender cómo Git se ramifica y fusiona. Lea y vuelva a leer algunos artículos y publicaciones de blog, tomándolo con calma y analizándolo hasta que lo vea. 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 DVCS, y las mayores victorias están en el área de ramificación y fusión.
fuente
Original : @Rob, TFS tiene algo llamado " Estantería " que aborda su preocupación por comprometer el trabajo en progreso sin que afecte a la compilación oficial. Me doy cuenta de que ve el control central de la versión como un obstáculo, pero con respecto a TFS, revisar su código en el estante puede verse como una fortaleza b / c, entonces el servidor central tiene una copia de su trabajo en progreso en el raro caso su máquina local falla o se pierde / es robada o necesita cambiar de marcha rápidamente. Mi punto es que se debe alabar adecuadamente a TFS en esta área. Además, la ramificació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 ramificar y fusionar en TFS no es bueno". Descargo de responsabilidad: soy un usuario moderado de TFS2010.
Editar 5-dic-2011 : Para el OP, una cosa que me molesta acerca de TFS es que insiste en configurar todos sus archivos locales en "solo lectura" cuando no está trabajando en ellos. Si desea hacer un cambio, el flujo es que debe "retirar" el archivo, lo que simplemente borra el atributo de solo lectura en el archivo para que TFS sepa vigilarlo. Ese es un flujo de trabajo inconveniente. La forma en que preferiría que funcione es que solo detecta automáticamente si he realizado un cambio y no se preocupa / molesta en absoluto con los atributos del archivo. De esa manera, puedo modificar el archivo, ya sea en Visual Studio o en el 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 de Windows Explorer ( TFS PowerTools) que le permite trabajar con sus archivos en el Explorador de Windows, pero eso no simplifica mucho el flujo de trabajo.
fuente
Además de todo lo que se ha dicho (
), 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 ser rastreados. Se admiten diversas políticas para registros, así como la integración con el dominio de Windows, que es lo que tienen las personas que ejecutan TFS. La GUI estrechamente integrada con Visual Studio es otro punto de venta, que atrae a desarrolladores y clics de mouse y clics por
debajo del promedio.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 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 único.
fuente
Si su equipo usa TFS y desea usar Git, puede considerar un puente "git to tfs". Esencialmente, usted trabaja día a día usando Git en su computadora, luego, cuando desea enviar sus cambios, los envía al servidor TFS.
Hay una pareja por ahí (en github). Utilicé uno en mi último lugar (junto con otro desarrollador) con cierto éxito. Ver:
https://github.com/spraints/git-tfs
https://github.com/git-tfs/git-tfs
fuente
Después de una investigación entre los pros y los contras, la compañía con la que estaba involucrado también decidió ir a TFS. No porque GIT no sea un buen sistema de control de versiones, sino lo más importante por la solución ALM totalmente integrada que ofrece TFS. Si solo la función de control de versiones fuera importante, la opción probablemente haya sido GIT. Sin embargo, la pronunciada curva de aprendizaje GIT para desarrolladores regulares no puede subestimarse.
Vea una explicación detallada en mi blog TFS como una verdadera plataforma de tecnología cruzada .
fuente
Todo lo distribuido de Git es realmente genial. ofrece algunas características que los Shelvesets no tienen (en el producto actual), como las opciones locales de reversión y confirmación (como la función de historia local de Eclipse ). Puede aliviar esto utilizando ramas de desarrollador, 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 con demasiada frecuencia (y lo denegué cada vez).
Creo que muchas grandes empresas tienen mucho miedo de permitir que un desarrollador solo 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 quitarle 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 excelente manera de hacer una copia de seguridad, lo cual es excelente para el código abierto nuevamente, donde el responsable original podría dejar de preocuparse y eliminar su versión, pero para un plan empresarial esto nuevamente 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 determinar qué versión usar si el 'proyecto' principal desaparece de alguna manera. Lo cual tendería a designar un repositorio como líder / central.
Lo que más me gusta de Git es la opción Push / Pull, donde puedes contribuir fácilmente con código a un proyecto sin la necesidad de tener derechos de compromiso. Supongo que podría usar usuarios muy limitados y estanterías 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 sobrecarga administrativa.
También me gustaría agregar a las cosas mencionadas en el área de control no fuente. Las características como el seguimiento de elementos de trabajo, la creación de informes y la automatización de compilación (incluida la gestión de laboratorio) se benefician enormemente de un repositorio líder central. Estos se vuelven mucho más difíciles cuando usa un modelo distribuido puro, a menos que haga que uno de los nodos lidere (y así regrese a un modelo menos distribuido).
Con TFS Basic con TFS 11, es posible que no esté muy lejos de esperar un TFS distribuido que le permita sincronizar su TFS básico local a un TFS central en la era TFS 12+. ¡Pondré mi voto por eso en la voz del usuario !
fuente
checkincomando (en lugar de rcheckin). Pero prefiero volver a controlar porque es más la forma git de hacer las cosas y es por eso que elegimos usar git;)Para mí, la principal diferencia es todos los archivos auxiliares que TFS agregará a su solución (.vssscc) para 'admitir' TFS: hemos tenido problemas recientes con estos archivos que terminan asignados a la rama incorrecta, lo que conduce a una depuración interesante ...
fuente
.gitcarpeta para rastrear todos los detalles del repositorio. TFS, como mínimo, modificará sus archivos.sln(¿o son los.csproj?) Para colocar la ubicación del repositorio remoto en él.