Servidor Git vs Team Foundation [cerrado]

263

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?

git tfs tfvc

— Jacko
fuente

24

Te enfrentas a una batalla cuesta arriba en este caso. Git no es tan maduro como svn / hg / tfs en Windows, lo que no molesta mucho a los veteranos de git, pero es un gran dolor de cabeza para los recién llegados.

— Marcelo Cantos

77

@Jacko: He estado evaluando git-for-Windows en las últimas semanas. Si bien ha mejorado notablemente desde la última vez que lo vi hace aproximadamente un año, todavía está muy lejos de estar listo para el horario estelar con los desarrolladores típicos de Windows. Por ejemplo, el complemento VS es francamente lamentable. No es más que un montón de opciones de menú debajo de la barra del menú principal, que silenciosamente fallan si se selecciona la solución en lugar de un proyecto. No puedo obtener la herramienta de confirmación para indexar trozos y líneas, que es la razón principal por la que uso git, y llegar a git gui (que es una atrocidad completa, desde un punto de vista de usabilidad) es, en el mejor de los casos, incómodo.

— Marcelo Cantos

66

Sin embargo, seré honesto contigo; me mata dejar caer git. Contrariamente a la opinión popular de que los dos están a la par, creo que el modelo de git es mucho más poderoso y lógico. Mercurial no tiene nada que coincida con el índice de git, y odio su enfoque de ramificación. El concepto de etiquetas de Git que se mueve y sincroniza entre repos es muy elegante. Los marcadores de Mercurial son lo único que se acerca y son un PITA para configurar para todos. Sin embargo, la conclusión es que el éxito es más probable con svn → Mercurial que svn → git, dado el personal y la madurez relativa de las herramientas.

— Marcelo Cantos

44

Sí, Git gobierna cuando se trata de poder y elegancia. Pero no todos están preparados para ello.

— Jacko

77

@JamesReategui: Personalmente pienso ( stackoverflow.com/a/11362998/520162 ) que la integración de un VCS en un IDE es un meandro. Imagínese si cambia su IDE principal mañana. ¿Qué pasa si deja caer VS para Eclipse? ¿Estás realmente dispuesto a aprender una nueva integración de VCS? Git es excelente en la línea de comandos ( stackoverflow.com/a/5645910/520162 ). Aprende y descubrirás un mundo increíblemente poderoso de control de versiones.

— eckes

273

Creo que la declaración

todos lo odian excepto yo

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 ):

copia de seguridad automática de todo el repositorio: cada vez que alguien se retira del repositorio central, obtiene un historial completo de los cambios. Cuando se pierde un repositorio: no se preocupe, tome uno de los presentes en cada estación de trabajo.
Acceso a repositorios 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 al trabajo y puedo trabajar como si estuviera en el trabajo : registro, salida, sucursal, cualquier cosa.

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.

— Eckes
fuente

22

Golpea, eckes. Me culpan cada vez que algo sale mal. No ellos mismos por no aprender cómo funciona. Para mí, Git está tan cerca de la perfección como alguna vez he experimentado en un sistema de control de versiones.

— Jacko

15

Por otro lado, TFS incluye el seguimiento de defectos / elementos de trabajo, informes, ... y otras funciones. Entonces, Git vs TFS en la funcionalidad VCS solo está perdiendo el punto de TFS.

— Richard

55

@Dan see rebase, filter-tree ...

— Artefacto

77

@Artefacto Lo sé, pero luego cambian todas las etiquetas de confirmación y todos los metadatos (discusiones de revisión de código, etc.) quedan huérfanos o deben actualizarse. Sin embargo, un mes con TFS me ha convencido de que no está en la liga de Git como sistema de control de versiones. Git libera al desarrollador para que sea productivo en formas que deben ser experimentadas para ser entendidas. La rama como metáfora del bloc de notas es perversamente poderosa.

— Dan Solovay

66

@ Richard argumentaría que es una desventaja de TFS: una vez que estás dentro, estás dentro. Hace todo mediocre y no te da una opción al respecto. Existen herramientas mucho, mucho mejores para rastrear elementos de trabajo, informes y gestión de proyectos.

— Ben Collins

102

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).

— Rob Sobers
fuente

55

Si piensa en ir con Mercurial, Joel Spolsky tiene un excelente sitio de tutoría para educar a su equipo: hginit.com

— Martin Owen

3

Vale la pena mencionar que git es perfectamente capaz de emular un sistema centralizado, y es común tener un servidor git primario para todos los usuarios, simplemente no tiene que hacerlo de esa manera.

— Tim Abell

77

Si está trabajando en una funcionalidad que podría romper otras cosas, ¿no podría simplemente crear una rama en TFS? Claro, la sucursal está en un servidor central, pero ¿eso realmente importa? Parece que efectivamente puede hacer lo mismo en ambos: parece más una cuestión de qué IDE está utilizando y qué tan bien integrado está el sistema de control de versiones con él.

— William

13

Si está trabajando en una función grande que potencialmente podría interrumpir al equipo, se recomienda usar una rama de características y luego, cuando esté listo, fusionarse con la rama de desarrollo.

— Mike Cheel

9

@ MikeCheel Este es un gran comentario. También podría crear un Estante de su código todos los días y eliminarlos cuando finalmente registre su función (pero la idea de ramificación es una mejor manera de hacerlo)

— RPDeshaies

86

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.

— Flores de charlie
fuente

3

Gracias Charlie. Lo sé, y tú lo sabes, pero es difícil llegar a las personas que dicen cosas como "la integración del control de código fuente con Visual Studio es la característica más importante para mí"

— Jacko

58

Lo sé. Un amigo y yo estábamos analizando esta analogía: imagina que necesitas una base de datos relacional seria. Usted evalúa SQL Server, Oracle y MS Access. Terminas eligiendo Access porque tiene la GUI más bonita, a pesar de que no puede escalar, no impone muy bien la integridad referencial, etc. La ramificación y la fusión son la carne y la papa absoluta de un sistema de control de versiones. Cualquier otra característica es solo un poco de brillo en el lateral. Pero las personas están tomando decisiones basadas en el brillo.

— Charlie Flowers

17

Si bien tiendo a estar de acuerdo con sus declaraciones, no veo por qué la ramificación y fusión de Git es "mejor" simplemente porque es un sistema "distribuido". No estoy seguro de que ser un DVCS tenga algo que ver con su capacidad para fusionarse. Me encantaría una explicación de por qué la fusión es más fácil en un sistema distribuido. En mi experiencia, que es principalmente Git y Svn, la fusión en SVN es terrible no porque sea un VCS centralizado, sino porque no realiza un seguimiento adecuado de las revisiones en las ramas como lo hace GIT.

— CodingWithSpike

8

@ rally25rs - Estoy de acuerdo con la mayoría de eso. No hay razón para que un VCS no pueda ser bueno fusionándose también. Todavía no hay ninguno (que yo sepa). Pero la parte con la que no estoy de acuerdo es "simplemente escribiendo mejores rutinas de fusión que resolvieron mejor los conflictos". La salsa secreta no está en las rutinas de fusión más inteligentes, sino en adoptar un enfoque fundamentalmente diferente de la información que almacena en el repositorio y cómo la organiza. Principalmente, hacer de Commits la base del estado interno. Los commits no son solo un atornillado genial ... son la base de las capacidades.

— Charlie Flowers

10

@ rally25rs está totalmente de acuerdo con respecto a: se compromete a ser la unidad atómica de trabajo. No solo la mayoría de los sistemas centralizados no organizan los datos de esta manera, sino que desalientan el tipo de trabajo momento a momento que los desarrolladores tienen que hacer para hacer un buen trabajo de bifurcación y fusión. Los sistemas distribuidos fomentan lo que yo llamo commits "apropiados" (pequeños compromisos independientes de trabajo relevante con buenas descripciones) y los sistemas centralizados fomentan lo que yo llamo "bombas diff" donde te escondes en una cueva hasta que estás listo y luego sueltas días (o semanas) de trabajo en el sistema. ¿Adivina qué tipo se fusiona mejor?

— Ben Collins

45

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.

— Lee Grissom
fuente

2

Esto responde a la pregunta, no debería ser un comentario, incluso si tuviera el representante.

— SingleNegationElimination

8

FYI - TFS "11" ya no requiere el bit de solo lectura si está utilizando espacios de trabajo locales, que es el valor predeterminado ahora. Descubre de forma inteligente qué archivos se cambian desde cualquier aplicación. Brian Harry tiene más información sobre las mejoras aquí: blogs.msdn.com/b/bharry/archive/2011/08/02/…

— Ed Blankenship

2

@EdBlankenship, muchas gracias por ese enlace de blog. Esa es una excelente noticia para ver que se están abordando las tonterías de solo lectura para facilitar el uso de la próxima versión de TFS.

— Lee Grissom

77

Contrariamente a las confirmaciones en una rama como lo hace con Git, las estanterías no son fáciles de entender y administrar. No sabe en cada confirmación que se realizó la estantería y, a menudo, tiene problemas con la fusión (si desde entonces ha realizado modificaciones, a menudo se pierden). Las ramas Git son mucho más potentes y comprensibles que las estanterías. La estantería es para desarrolladores que nunca experimentaron otra cosa ...

— Philippe

2

Este flujo de trabajo de 'desproteger' un archivo recuerda a Visual SourceSafe, ya que esta era la forma común de trabajar; los archivos se recuperaron de SourceSafe y se almacenaron localmente como archivos de solo lectura. Retirar un archivo, o un montón de archivos, podría marcarse como exclusivo, lo que significa que otros podrían ver el conjunto de archivos en el que está trabajando otro desarrollador, para evitar la necesidad de fusionarse cuando se deshabilitó la ramificación (probablemente debido a que es un cerdo derecho en VSS).

— Brett Rigby

18

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 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.

— Sherlock
fuente

44

Puede obtener las mismas herramientas que TFS proporciona en cualquier aplicación de herramientas ágiles. Rally, lo que sea.

— PositiveGuy

2

Si bien estoy de acuerdo con el hecho de que TFS tiene un objetivo más amplio, lo reformularía a "INTENTA proporcionar un destino único", pero no es lo suficientemente bueno (al menos no es la mejor opción) en ninguna de las tareas que intenta resolver; así que es como un cuchillo suizo sin filo.

— slashCoder

@PositiveGuy no puedes obtenerlo sin trabajo y configuración. TFS te da todo con un clic. Por ejemplo, todo el ecosistema ahora está disponible como un servicio en la nube, sin necesidad de configuración. Si puedo obtener control de versiones, soporte de scrum, compilaciones automatizadas, laboratorio de pruebas y administración de planes de prueba, todo integrado de fábrica y con un LDAP corporativo (mentira AzureAD), por $ 10 / mes, ¿por qué en mi sano juicio iría? tratando de pegar piezas por mi cuenta?

— Craig Brunetti

1

@slashCoder ¿cómo podría esperarse que una suite completa sea la mejor en cada pieza? ¿El costo de su no mejor edificación realmente supera el costo de tener que administrar la integración de componentes por su cuenta? ... tal vez para algunos lugares lo hace, puedo ver eso. Pero es pura sobrecarga tener que ejecutar tales cosas. ¿Qué sucede si su GIT corporativo funciona bien, pero su instancia JIRA se cae y su actualización Jenkins no funciona? ¿Correcto? Es como hacer malabares con motosierras. En llamas. Semi-con los ojos vendados. :) :)

— Craig Brunetti

17

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

— bytedev
fuente

66

Microsoft proporciona una integración directa con repositorios Git y TFS ahora: blogs.msdn.com/b/bharry/archive/2012/08/13/…

— Ed Blankenship

1

@EdBlankenship, es posible que desee convertir su comentario en una respuesta. Parece ser una gran solución para el OP. Voy a votar por eso. :)

— Lee Grissom

1

Excepto si está en otra plataforma que Windows, ¡debería preferir git-tfs! git-tf está lejos de ser tan bueno como git-tfs ... Y la filosofía está orientada a TFS, mientras que git-tfs está más orientada a git (¡y eso es lo que queremos!)

— Philippe

15

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 .

— Pieter Gheysens
fuente

3

Quizás, pero cada parte de TFS es mala y difícil de administrar (de hecho, necesita un administrador real para TFS). Busque Git> TFS (VCS), Jenkins> TFS (CI), nunit o xunit> mstest, IceScrum o ...> TFS (Gestión de proyectos). ¡TFS es una buena idea al principio, hasta que lo uses!

— Philippe

1

por qué necesitas TFS, solo obtén una buena aplicación ágil. Y luego usa Git o Subversion y estarás en camino. TFS simplemente se interpone en tu camino al atascarte con problemas.

— PositiveGuy

Actualización: TFS 2013 (servidor) [y VS12-13) ahora admite git para el control de versiones. Para que puedas obtener lo mejor de ambos mundos

— DarcyThomas

2

Claro, es bueno tener un ALM completamente integrado. Pero no a expensas de la flexibilidad. OMI un ALM debe construirse con la mayor tecnología posible "mejor de la raza" ... o al menos, la flexibilidad para integrar la mejor de las razas, ya que es probable que cambien con el tiempo. Elegir TFS es básicamente poner una apuesta en el suelo, diciendo "Microsoft va a ganar en todos los aspectos de mi ALM", lo cual es una tontería. He usado Git w / Jira, por ejemplo, lo que me permitió actualizar / cerrar problemas en función de mi mensaje de confirmación. En mi experiencia (también con TFS), este es un flujo de trabajo muy superior.

— Scott Silvi el

1

Barra lateral: incluso con la integración de TFS / Git, básicamente está diciendo "permite agilizar VCS a Git, manteniendo nuestro seguimiento de problemas", fundamentalmente no es diferente de usar Git con cualquier otro software de seguimiento de problemas. Así que no estoy seguro de que el argumento ALM sea válido, dados los intentos de flexibilidad de Microsofts (que aplaudo).

— Scott Silvi el

14

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 !

— jessehouwing
fuente

También te interesará esta nueva función que te ofrece Microsoft: gittf.codeplex.com

— jessehouwing

1

usa git-tfs. Por el momento, ¡es mucho mejor que git-tf! github.com/git-tfs/git-tfs

— Philippe

3

Toda esta respuesta se está quedando obsoleta rápidamente. Microsoft ha agregado soporte de Git a Team Foundation Service y agregará soporte para Git a la próxima versión principal de Team Foundation Server.

— jessehouwing

1

@Philippe: He probado los dos. Un par de diferencias: 1) git-tf es multiplataforma, mientras que git-tfs solo se ejecuta en Windows. 2) git-tfs reescribe las descripciones de confirmación cuando "presiona" para incluir el número de conjunto de cambios, mientras que git-tf deja intactos los hashes de confirmación locales.

— Joey Adams

@JoeyAdams 1) +1, esa es la única buena razón para elegir git-tf 2) También podría hacerlo con git-tfs usando el 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;)

— Philippe

9

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 ...

— Arrozal
fuente

2

Buen punto aquí. Git agregará la .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.

— CodingWithSpike

55

Olvidé cuánto odiaba cómo VSS modificaría sus archivos 'para' usted.

— Paddy