He usado sistemas de control de versiones "tradicionales" para mantener los repositorios de código fuente en proyectos anteriores. Estoy comenzando un nuevo proyecto con un equipo distribuido y puedo ver las ventajas de usar un sistema distribuido. Dado que entiendo SourceSafe, CVS y Subversion; ¿Qué sugerencias tienes para un novato Git?¿Qué debería saber sobre Git antes de comenzar a usarlo?
El Git - SVN Crash Course es una buena lectura para ponerse en marcha.
Antes de confirmar los archivos, tienen que agregarse al área de ensayo de Git — cada vez. Para hacerlo más fácil, hay una opción -a para agregar todos los archivos rastreados, como en git commit -a.
Además, cuando lo hace git diff, solo muestra la diferencia entre su copia de trabajo y lo que hay en el área de ensayo. Si ha agregado archivos modificados a su área de ensayo, git diff no puede informar nada, aunque es posible que tenga cambios no confirmados. Use git status para ver con seguridad.
¿Tienen el tutorial
luego jugar un rato con él. Haga un pequeño proyecto de juguete para familiarizarse con él antes de comenzar a trabajar con su base de código principal.
Utilizo mucho gitk para revisar los parches y rastrear cómo cambia el código de commit a commit.
Probé git en mi compañía. Utilizamos CVS y queríamos pasar a una mejor herramienta de VC. Hemos elegido git como la mejor herramienta para el control de versiones de archivos (Linus en GIT). Su rendimiento es el mejor y es una gran herramienta para un desarrollador que entiende el control de versiones en profundidad pero es una pesadilla para los desarrolladores habituales que usan control de versiones en segundo plano y no quieren aprender a usar para obtener más de pocas horas (y necesitan aprender mucho)
Además, su integración con los IDE existentes está lejos de ser completa. Toda la usabilidad es un gran problema para un desarrollador regular.
Después de un piloto con 4 desarrolladores cambiamos a Subversion como la herramienta más simple aunque no tan superior.
También hay solución comercial para Subversion MultiSite (que no probamos todavía, pero trataremos en breve) - WANDisco
En mi propia experiencia en el traslado de Subversion a Git, lo más importante no es lo que necesita para aprender, pero lo que necesita para desaprender. El control de versión distribuida es muy diferente del control de versión centralizada. CVC es un subconjunto de DVC, por lo que puede hacer CVC en una herramienta DVC, pero será más complicado que con una herramienta CVC.
Intenta desaprender el CVC y entra en la mentalidad de DVC. Si acaba haciendo CVC en una herramienta de DVC, simplemente se sentirá frustrado por la complejidad añadida y no se dará cuenta de qué le está comprando esa complejidad adicional en términos de flexibilidad.
Todas las herramientas DVC tienen gran y un soporte muy potente para la bifurcación y fusión. Úselo. Toda la historia está disponible a su alcance. Úselo. (Por ejemplo: nunca comente un código, simplemente bórrelo. Siempre puede recuperarlo, incluso en un avión sin conexión a Internet.)
Un aspecto muy importante de Git: todas las otras herramientas tienen un flujo de trabajo más o menos definido. Git no. Git es un kit de construcción de flujo de trabajo DVCS. Esto hace que a veces sea difícil saber qué hacer: tiene que diseñar e implementar su propio flujo de trabajo (sugerencia: use muchos scripts de shell). Utilizo Git por más de un año y aún no he descifrado por completo mi flujo de trabajo.
... a menos que usted ordene "git diff foo/bar.file" –