Oh wow, sí.
Uso tanto SVN como Git y no te puedo decir cuántas veces me han salvado el culo. Más Git que SVN, pero no iniciemos flamewars aquí. Esto es en proyectos en los que trabajo solo, así como en proyectos en los que trabajo con otras personas. No hay excusa para no hacerlo, realmente.
Como humano, básicamente tengo derecho para hacer estupideces todo el tiempo. Al usar el control de versiones, puedo continuar alegremente haciendo cosas increíbles y cometiendo a intervalos en los que tenga sentido. Cuando hago algo increíblemente estúpido, simplemente puedo revertir mis cambios al último punto en el que me comprometí. Incluso con Git, puedo deshacer fragmentos específicos de cambios en un archivo en lugar de todo el archivo.
Mi versión de control (ab?) usando flujo de trabajo, como desarrollador de Rails (y sí, sé que usas C #, se aplica el mismo flujo. Solo subpongo los comandos git para tus comandos tfs ), como sigue esto para un nuevo proyecto:
- Toma una nueva característica de Pivotal Tracker y descubre qué diablos se supone que debe hacer. También conocido como traducción de cliente a inglés.
- Cree un directorio nuevo para el proyecto y luego inmediatamente :
-
git init
-
git add .
-
git commit -m "Initial setup for [project]"
-
git remote add origin [email protected]:radar/project.git
-
git push origin master
Ahora tengo un repositorio de Git listo para que me comprometa, con una rama master . Esta rama master siempre debe permanecer "pura". Las pruebas siempre deben ser 100% pasadas, sin excusas, o las de alguien que va a ser despedido, muy gravemente herido, he mencionado, no hay excusas en esta rama. Si la función es lo suficientemente compleja (me demora más de una hora o dos o si el cambio va a ser más que un compromiso único y razonable), crearé mi propia rama usando git checkout -b [feature-name] , de lo contrario, trabajaré en el maestro .
En esta rama, puedo hacer lo que me dé la gana. master todavía va a ser "puro" y puedo destrozar el lugar y luego git checkout . para recuperarlo todo. Es en esta rama en la que desarrollo la nueva función, haciendo compromisos incrementales y sensibles en el camino. ¿Ha creado una página en la que un usuario puede completar un formulario y luego algo para manejar ese formulario? Eso es un compromiso. ¿Agregó una nueva función a una clase y la probó? Nuevo commit. Es posible que me incline a empujar esta rama en alguna parte para que otras personas puedan trabajar conmigo en ella, en cuyo caso me gustaría git push origin [feature-name] y luego podrían clonar el repositorio y git checkout origin/[feature-name] -b [feature-name] para obtener mis cambios y podríamos trabajar juntos en ello .
Cuando termine con la función, ejecuto las pruebas en la rama [nombre-característica]. Luego, puedo volver a la rama master , asegurarme de que todo sigue siendo "puro" ejecutando las pruebas, y luego git merge [feature-name] para combinar la rama en el maestro. Luego ejecuto las pruebas otra vez para asegurarme de que aún sea "puro" (recuerde, no hay excusas) y, finalmente, presiono mis cambios en la rama master en GitHub.
Enjuague, repita.
Sin el control de versiones, estaría completamente perdido. Haría estupideces y luego pasaría bastante tiempo manualmente deshaciéndolo y sin estar seguro de si lo tengo todo o no. El control de versiones es una gran herramienta para prevenir la estupidez (como lo es la prueba, pero ese es un tema tangencial) y lo aliento muy, muy fuertemente.
No hay excusas.