De TFS a Git

14

Soy un desarrollador de .NET y he usado TFS (servidor de base de equipo) como mi software de control de origen muchas veces. Las buenas características de TFS son:

  1. Buena integración con Visual Studio (por lo que hago casi todo visualmente; sin comandos de consola)
  2. Proceso de registro y salida fácil
  3. Fácil fusión y resolución de conflictos.
  4. Construcciones automatizadas fáciles
  5. Derivación

Ahora, quiero usar Git como la columna vertebral, el repositorio y el control de código fuente de mis proyectos de código abierto. Mis proyectos están en lenguaje C #, JavaScript o PHP con bases de datos MySQL o SQL Server como mecanismo de almacenamiento.

Simplemente utilicé la ayuda de github.com para este propósito y creé un perfil allí, y descargué una GUI para Git. Hasta esta parte fue muy fácil.

Pero casi estoy atascado en seguir adelante. Solo quiero hacer algunas operaciones simples (realmente simples), que incluyen:

  1. Crear un proyecto en Git y asignarlo a una carpeta en mi computadora portátil
  2. Retirar / registrar archivos y carpetas
  3. Resolviendo conflictos

Eso es todo lo que necesito hacer ahora. Pero parece que la GUI no es tan fácil de usar. Espero que la GUI tenga una Connect To...o algo así, y luego espero que se muestre una lista de proyectos, y cuando elijo uno, espero ver la lista de archivos y carpetas de ese proyecto, al igual que explorar su proyecto TFS en Visual Studio Entonces quiero poder hacer clic derecho en un archivo y seleccionar check-in...o check-outy cosas por el estilo.

¿Espero mucho? ¿Qué debo hacer para usar Git fácilmente como TFS? ¿Que me estoy perdiendo aqui?

Saeed Neamati
fuente
8
Cambié de SVN a git hace un año, y estoy muy feliz por eso. NO recomendaría SVN a nadie excepto a un enemigo rígido de la línea de comandos. Una vez que aprendas git, te encantará.
maaartinus
14
¿Por qué la gente de Windows está tan obsesionada con las interfaces gráficas?
tdammers
8
@tdammers ¿Porque la línea de comandos en Windows apesta? Lo sé, hay PowerShell, pero ¿lo usan?
maaartinus
3
@Saeed, para empezar, esperas que haya algo como ingresar y salir archivos en git. Ningún VCS utilizable ha tenido eso durante años.
Daniel Roseman
1
Lectura recomendada: ericsink.com/entries/vcbe_print_edition_free.html Explica los conceptos básicos del control de versiones y las diferencias entre centralizado y descentralizado (que aún podría usar un servidor central, mente.)
Inca

Respuestas:

19

Las ventajas que git ha tenido son arrojar muchas suposiciones antiguas sobre lo que debe hacer un VCS. Las desventajas de git provienen de no poder aprovechar la experiencia previa y no poder hacer las cosas de la manera que estás acostumbrado.

Si va a cambiar de algo más a git, intente iniciar tabula-rasa (aunque es imposible hacerlo realmente en la práctica). Evalúelo basándose en lo que hace y qué tan bien lo hace, no en cómo lo hace en comparación con cómo está acostumbrado a hacerlo. No es que esperes demasiado, es que tus expectativas son ortogonales a lo que proporciona git. Si está casado con la operación GUI, se sentirá decepcionado. Git tiene herramientas gui disponibles, pero no agregan mucho. Eso no es un fracaso para proporcionarlos, ya que no hay mucho que una interfaz gráfica de usuario pueda agregar. GitK ayuda, no en las operaciones diarias, sino en visualizar la estructura de la rama y examinar o buscar el historial.

Aquí hay una analogía tonta de lo que quiero decir con "ortogonal". Una de las cosas que puedes hacer con un periódico es envolver el pescado o usarlo para forrar una jaula. Pero esos no son esenciales para la función de un periódico, son características incidentales de la forma en que viene. Esperando que git "registre archivos", o "le permita seleccionar proyectos", o proporcione una "conexión a ... "es algo así como esperar poder envolver peces o alinear su jaula con el sitio web de un periódico .

kylben
fuente
Vaya, olvidé explicar la edición. Acabo de agregar el último párrafo después de levantarme para tomar más café y tener la analogía en mi cabeza.
kylben
3
Me encantó la metáfora al final. +1
Yam Marcovic
7

¿Has considerado mercurial? Al igual que git, es un DCVS y le permite hacer todas las cosas que uno puede hacer con un DCVS. Al igual que git, hay un proveedor de servicios bastante bueno basado en la nube (bitbucket). Pero, a diferencia de Git, la historia de Windows es bastante decente, no eres un ciudadano de segunda clase. Tienes buenas opciones de herramientas (TortiseHG) y una integración bastante decente de Visual Studio (VisualHG).

Sin embargo, nada será como TFS en Visual Studio: el mundo simplemente no está conectado de esa manera.

Wyatt Barnett
fuente
1
Estoy de acuerdo, hace unos años me mudé de VSS a Mercurial y fue una verdadera epifanía. De repente pude hacer cosas que nunca pensé que serían prácticas. Luego me mudé svny me perdí muchas cosas que eran muy fáciles hg. Ahora me estoy mudando gity tengo sentimientos encontrados. Me encanta recuperar muchas de esas instalaciones en las que me perdí svn, pero aún extraño la simplicidad en hgcomparación con la complejidad innecesaria de git. Incluso solo instalar TortoiseGit en Windows requiere que saltes los aros que simplemente no son necesarios con TortoiseHg .
Mark Booth
@ Mark Booth: Estoy de acuerdo en que git no es muy fácil de usar, pero ¿qué complejidad innecesaria ? Los problemas de instalación no cuentan, podrían atribuirse a TortoiseGit (que es un programa diferente) o a Windows.
maaartinus
Esto sería mejor en el chat, pero no veo la necesidad de un área de índice / caché / puesta en escena, en mi humilde opinión, el valor predeterminado debería ser confirmar todo con la opción de confirmaciones parciales si se solicita (mejor aún sería archivar los cambios que no hace no quiera de inmediato, vuelva a ejecutar sus pruebas unitarias, comprométase y luego desestípelo). También odio tener que crear explícitamente una nueva rama cuando quiero una. Con hg, una rama sin nombre se crea en silencio cada vez que se compromete con una no cabeza. En git, si te alejas de una cabeza sin ramificarte, ¡puedes perderla y luego recolectar basura!
Mark Booth
6

Cambié de SVN a git hace un año, y estoy muy feliz por eso. Sin embargo, no estoy confiando en ninguna GUI y en caso de que rechace rígidamente la línea de comando, puede ser un problema.

Parece que espera gittrabajar de la forma en que está acostumbrado, pero no es así. No es difícil, pero debes echar un vistazo a sus principios antes de continuar.

Crear un proyecto en Git y asignarlo a una carpeta en mi computadora portátil

Git se distribuye, lo que significa que siempre trabaja con su repositorio local, que puede asignarse a cualquier número de controles remotos, incluido cero. Cuando juego con el proyecto de otro uso dos controles remotos: su repositorio git o SVN y mi propio servidor.

Siempre empiezo creando un directorio vacío y luego git inito git clone SOME-REMOTE-REPOSITORY. Este enlace te puede ayudar.

Retirar / registrar archivos y carpetas

Te perdiste de escribir qué GUI estás usando. Ambos TortoiseGity git-guiseguramente pueden hacerlo.

Resolviendo conflictos

Para esto estoy usando git-guio mi editor de texto favorito.

Espero que la GUI tenga una conexión a ... o algo así

¿Conéctese a qué, cuando puede haber 0 a N controles remotos? Git no permanece conectado a un servidor remoto, crea la conexión solo temporalmente y solo para los pocos comandos que funcionan con el repositorio remoto. La mayor parte del trabajo se realiza localmente.

entonces espero que se muestre una lista de proyectos

Supongo que projectsquieres decir repositories.

Me temo que no hay tal cosa. Git en un servidor remoto funciona estrictamente con un solo repositorio. Listar todos los repositorios es equivalente a listar todos los directorios que contienen el subdirectorio .git. Estoy seguro de que hay algo como esto GitHub.

Elijo uno, espero ver la lista de archivos y carpetas de ese proyecto, al igual que explorar

Una vez más, me temo que no existe tal cosa, ya que gitfunciona localmente. Y de nuevo, no sería de mucha utilidad. Simplemente clone el repositorio y explore en su computadora. Si bien la clonación de repositorios enormes lleva algo de tiempo, todas las operaciones posteriores son mucho más rápidas y puede observar cualquier confirmación o rama.

Entonces quiero poder hacer clic derecho en un archivo y seleccionar check-in ... o check-out y cosas así.

De nuevo, gittrabaja localmente. Por lo tanto, no tiene sentido registrarse o retirarse a un repositorio remoto. Trabajar de esta manera es una pérdida de tiempo incluso en una LAN rápida. Obtenga el repositorio en su computadora, trabaje con él y git pushlos cambios en el control remoto. Piénselo como publicar sus cambios y también hacer copias de seguridad. Debes comprometerte localmente muy a menudo .

Antes de comenzar su trabajo, git fetcho git pulllos cambios desde el control remoto en caso de que alguien más haya estado trabajando con él.

¿Espero mucho?

Si y no. Esperas algo diferente de lo que ofrece. Puede obtener algo mucho mejor, gites potente, flexible, seguro, rápido como el infierno y puede hacer todo lo que necesita, pero no puede imitar exactamente lo que hace un VCS centralizado.

maaartinus
fuente
5

He hecho el recorrido desde la fuente visual seguro a tfs a svn a git.

Pasar de vss a tfs fue una experiencia agradable. Pasar de tfs a svn fue una experiencia agradable. Pasar de svn a git ha sido una especie de batalla interna.

A menudo me encuentro bastante conservador y trato de aferrarme a lo que funciona. Una buena interfaz gráfica es preferible para mí en lugar de la línea de comando y me encontré buscando una interfaz gráfica que me permitiera jugar con los niños geniales con los que trabajo. Todos usaron git con la línea de comando exclusivamente.

El momento eureka para mí llegó una vez que me di por vencido en la búsqueda de una GUI de bala de plata y comencé a probar git bash (todavía estoy aprendiendo).

Tengo algunas guis instaladas y complementan git desde la línea de comandos. Extensiones de git, proveedor de control de fuente de git para visual studio y git de tortuga. Pero digo que te familiarices con git bash. Los comandos pueden ser un poco crípticos, pero una vez que los aprendes son mucho más rápidos que la interfaz gráfica de usuario.

Ramificar con git es simplemente INCREÍBLE en comparación con los demás. Crea ramas y cambia entre ramas casi al instante. Puede hacer cosas que no se molestaría en hacer con svn porque svn básicamente copia su copia de trabajo (al menos de la manera en que lo hice).

Creo que Git tiene una curva de aprendizaje más pronunciada que svn. Pero una vez que "lo entiendes" con git, no quieres volver.

Git todo el camino.

tomasat
fuente
5

Estás acostumbrado a tener un servidor que almacena tus archivos y es el propietario omnipotente de ellos. Para editar un archivo debe solicitar permiso al servidor.

Git no es así. Piense en git de esta manera: tiene su repositorio local. Git le permite confirmar los cambios, confirmaciones inversa, fácil y rápida de ramificación, etc. Cuando se desea una copia de su historial de control de código fuente, se empuja sus cambios a otro repositorio, que "sólo pasa a ser" un servidor, como GitHub.com.

Flujo de trabajo:

  1. Clonar (Descargar) / Crear repositorio
  2. Haz algunos cambios. Continuar con el desarrollo sin preocuparse por los demás.
  3. Empuje a otro repositorio (podría ser un servidor como GitHub).
  4. Cuando ingresa a un repositorio, el propietario de ese otro repositorio recibe una notificación de la inserción pendiente y debe decidir si acepta esas confirmaciones, las rechaza o solo toma un subconjunto de ellas.
  5. El ciclo continua.

Eso es todo.

Ñame Marcovic
fuente
1

¿Qué quieres decir con "el" git gui? Hay miles de millones de ellos, incluido un complemento para la integración de Visual Studio, si no recuerdo mal. Si una GUI no funciona para usted, intente un poco más hasta encontrar una que sí lo haga. Yo personalmente uso diferentes GUI para diferentes tareas (y la CLI para otros).

Sin embargo, git es más un marco de control de versiones que un sistema fijo. Todavía tendrá que aprender algunos conceptos básicos para aprovecharlo al máximo.

Karl Bielefeldt
fuente
-2

¿Espero mucho?

si

¿Qué debo hacer para usar Git fácilmente como TFS?

Nada. Git está centrado en CLI y no tiene una buena interfaz (sé sobre TortoiseGit, que no es la respuesta, en comparación con otros Tortoise *). Puedes intentar usar SmartGit (cuidado con Java)

Tejón perezoso
fuente
1
-1: El registro de archivos de entrada / salida y la resolución de conflictos no 'espera mucho' del control de origen.
Steven Evers
2
+1 Verificarlos directamente desde un servidor remoto simplemente no tiene sentido. Es solo para reducir la velocidad, incluso a través de LAN. Hacer tales cosas es algo para lo que FTP es, no VCS.
maaartinus
1
La "entrada / salida" de archivos no es una operación fundamental para un VCS. Es una característica de implementación común a la mayoría de los VCS, y tiene efectos secundarios sutiles pero desafortunados.
kylben
2
@kylben: el registro de entrada / salida es una forma de ver el control de versiones; editar y fusionar es otra forma. Algunos VCS utilizan el enfoque anterior, que le brinda bloqueos exclusivos y la capacidad de revisar archivos individuales; otros toman el último, y con ellos, usted descarga todo el repositorio, realiza los cambios locales y luego los devuelve al control remoto; VCS se encarga de gestionar los cambios conflictivos, solicitando su opinión en caso de duda. Ninguno de los dos enfoques es mejor, pero por lo general no puede doblar un VCS en el que no está hecho.
tdammers
1
Al 'registrar entrada / salida', en realidad estaba hablando de la forma en que los VCS basados ​​en bloqueo implementan las cosas, no cómo puedes descargar los archivos fuente para editarlos (que es algo que todos los VCS deben poder hacer). El hecho de que muchos VCS se refieran al mero proceso de descargar un archivo como 'pago' es un IMO poco apropiado: no se verifica nada y el repositorio no recuerda quién tiene el archivo.
tdammers