De TFS a Git

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?

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 .

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

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.

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.

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.

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

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