Si un desarrollador siempre usa el control de versiones [duplicado]

41

He escuchado declaraciones en el sentido de: "Bueno, solo estoy trabajando en este proyecto, así que no necesito ponerlo bajo el control de código fuente", así como "No hay necesidad de trabajar con una versión controlada en este proyecto, es tan pequeño ".

En mi opinión, no importa qué tan pequeño sea el proyecto, siempre que esté agregando valor al cliente (y ellos también lo estén pagando), nosotros, los desarrolladores, deberíamos controlarlo la versión; especialmente desde su política de empresa.

¿Estoy loco o mi punto de vista tiene sentido?

Pregunta: ¿El trabajo de desarrollo siempre debe estar controlado por versión?

    
pregunta user77232 17.12.2010 - 03:05

11 respuestas

88

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.

    
respondido por el Ryan Bigg 17.12.2010 - 03:24
10

Sí, un desarrollador siempre debe usar el control de versiones, de algún tipo. Quién sabe qué tan grande puede llegar a ser un proyecto, o cuántas personas pueden estar usándolo, o qué error acaba de presentar. VC debe ir de la mano con el almacenamiento externo del proyecto también.

    
respondido por el sasfrog 17.12.2010 - 03:10
6

Es una decisión absolutamente personal.

En cuanto a mí, puse en la versión de control cualquier cosa . Literalmente - cualquier cosa. No importa, es una lista de compra en una tienda o una fuente de proyectos.

    
respondido por el zerkms 17.12.2010 - 03:08
4

Absolutamente. Si nada más (y eso es GRANDE si), te libera para jugar con tu código sin preocuparte por perder tu implementación operativa.

    
respondido por el Babak Naffas 17.12.2010 - 03:08
3

¿Cuánto trabajo de desarrollo puede permitirse perder? ¿Qué pasa cuando necesitas retroceder un cambio? Tarde o temprano lo necesitarás.

    
respondido por el Mike Chess 17.12.2010 - 03:09
2

No hay absolutamente ninguna razón para no hacer esto cada vez que escribes un código. Si tiene instalado git, incluso puede hacer esto localmente para cosas que considera desechables. Básicamente, si vas a editar el archivo más de una vez, debería ir en el control de versiones. Que simple.

¿Por qué no harías esto? Parece que la carga cognitiva de tratar de averiguar si hacerlo o no es más que el costo de hacerlo siempre. En serio, ¿qué esfuerzo intentaría ahorrar alguien aquí?

La mente se aturde.

    
respondido por el user545578 17.12.2010 - 03:58
1

Sí, debe usar todo el control de fuente de tiempo ....

Incluso si el proyecto es pequeño, hay un gran beneficio de usarlo. Además, la sobrecarga es prácticamente nula si el equipo sabe cómo usar el sistema de control de versiones.

También es importante tener algo de rastreabilidad en un proyecto pequeño, puede trabajar en los mismos archivos sin pisar los otros dedos del pie, actuar como copia de seguridad, etc ... etc ... así que, ¿por qué no usarlo?

    
respondido por el RageZ 17.12.2010 - 03:09
1

Sí, tienes razón. El control de versiones le permite retroceder a un punto anterior si se atasca, y también le permite mantener copias de seguridad de su código (especialmente importante para entornos corporativos). Si cree que, por algún motivo, crear un repositorio para este pequeño proyecto es una sobrecarga, entonces considere usar un VCS distribuido como git o mercurial para crear un repositorio localmente.

    
respondido por el kelloti 17.12.2010 - 03:09
1

Deberías, y también debes usar una herramienta de control de código fuente donde es muy barato hacerlo.

Tenía el mal hábito de no usar el control de código fuente de forma inmediata cuando usaba Subversion, pero con herramientas como Git & Mercurial, es muy barato empezar

    
respondido por el aussiegeek 17.12.2010 - 03:13
1

En mi humilde opinión diría que es una buena práctica. Puedo ser un salvavidas en aquellos casos en los que ha estado probando diferentes soluciones y quiero hacer una copia de seguridad de una versión sana de su código.

Lo uso incluso para pequeños proyectos personales. Me he encontrado garabateando en mi código tantas veces maldiciendo sobre Ctrl-Z sin extenderme lo suficiente en el tiempo.

    
respondido por el Stompp 17.12.2010 - 09:53
1

Cualquiera que te diga que es un idiota.

Cualquier compañía que emplee un desarrollador (o administrador) que diga que no está en algún lugar donde quiera trabajar, a menos que piense que puede comenzar a cambiar cosas como esas.

Honestamente, escuchas historias de guerra, pero en serio ya no pensaba en lugares como ese.

    
respondido por el ozz 01.02.2011 - 17:08

Lea otras preguntas en las etiquetas