¿Cuál es el enfoque canónico para usar un VCS desde la infancia de un proyecto?

Antecedentes

He usado VCS (principalmente git) en el pasado para administrar muchos proyectos existentes y funciona muy bien. Por lo general, con un proyecto existente, verificaría cada cambio que realizo en el código que optimiza o cambia la funcionalidad general (ya sabes lo que quiero decir, en pasos adecuados, no todas las líneas que cambio).

Problema

Una cosa en la que no he tenido tanta práctica es crear nuevos proyectos. Estoy en el proceso de comenzar un nuevo proyecto propio que probablemente crecerá bastante, pero descubro que hay mucho que hacer y mucho cambio en los primeros días / horas / semanas / hasta el período hasta que el producto realmente funcione en su forma más básica.

¿Hay algún punto en mí para verificar cada paso del proceso como lo haría con un proyecto existente? No estoy rompiendo el proyecto con los cambios que hago, ya que aún no funciona. Por el momento, simplemente he estado usando VCS como respaldo al final de cada día, cuando dejo la computadora.

Mis primeras confirmaciones fueron cosas como "Estructura básica de directorios en su lugar" y "Tablas de bases de datos creadas". ¿Cómo debo usar un VCS al comenzar un nuevo proyecto?

— Anónimo
fuente

Su título se puede volver a convertir en una pregunta Y su respuesta: "¿Cuál es el enfoque canónico para usar un VCS? Desde la infancia de un proyecto" o, de hecho, "¿Cuál es el enfoque canónico para usar un derecho VCS? Desde la infancia de un proyecto"

— AakashM

El título ha sido editado desde que comencé la pregunta. Si bien puedo ver lo que estás diciendo, esa no es realmente la pregunta ni la respuesta a la pregunta que estaba haciendo, o al menos no en esa interpretación.

— Anónimo

@ Anónimo: reescribí su título porque tenía la forma de una pregunta que no se considera constructiva. Espero que no te importe, hice esto en un intento de evitar que se cierre temprano. Lo siento si eso te confundió.

— haylem

@haylem - ¡No hay problema, estoy completamente de acuerdo contigo! Le agradezco que intente mantener abierta mi pregunta, para lo cual ahora tenemos una respuesta definitiva. :)

— Anónimo

Un tutorial rápido (¡muy!) Sobre Git -> try.github.com/levels/1/challenges/1

— MathAttack el

Respuestas:

Comience simple

git init

Registro temprano, registro frecuente

Simplemente haga lo que normalmente hace con cualquier proyecto: "registrarse" para cada conjunto de cambios relacionados con una tarea particular o grupo de acciones. Si usa un rastreador de problemas, entonces confirme los cambios que se relacionan con una tarea cada vez que está en un estado estable (vea esta pregunta SO sobre con qué frecuencia se debe confirmar ). Es posible que no esté en un estado de finalización, solo estable, en el que el software no se está ejecutando o el sitio no se puede procesar. Como Jeff Atwood dice en su publicación:

Si el código no se registra en el control de origen, no existe. [...]

No estoy proponiendo que los desarrolladores revisen el código roto, pero también sostengo que hay una gran diferencia entre el código roto y el código incompleto.

Comprometerse a menudo, perfeccionar más tarde, publicar una vez

Si el producto no está ni siquiera cerca de un estado viable, simplemente siga revisando los cambios como mejor le parezca, utilizando el buen juicio y el sentido común para agruparlos. No es necesario que confirmes el cambio de línea de cada archivo uno por uno, pero comprometer todo como un gran fragmento hará que sea más difícil deshacerlo si es necesario.

Al final, su VCS está aquí para ayudarlo . ¡Así que ayuda a tu VCS a ayudarte!

No lo pienses demasiado

Tus primeras confirmaciones estuvieron bien. No lo pienses demasiado. Lo más importante es que se hayan registrado. Si observa todos los proyectos de código abierto existentes en línea que comenzaron desde cero y no desde una base de código existente, tienen como primera revisión algo similar a:

creó la estructura del directorio (yay!)

Hazlo un hábito

Al final de cada día, intente generar un registro de lo que ha hecho en función de sus registros de confirmación. Si los resultados que obtiene git shortlogy git logNO parecen satisfactorios y útiles , sin embargo, ha realizado un esfuerzo significativo en el proyecto durante el día y ha verificado esos cambios, entonces probablemente no lo hizo bien .

git shortlogdebería leerse como una descripción general de lo que has hecho.
git logDebe leer como la historia y la historia de su proyecto.

— haylem
fuente

Estas son buenas pautas, y enfatizaría "No lo pienses demasiado" (por supuesto, eso también se aplica a las siguientes pautas ... :) - salir y simplemente hacerlo es la mejor manera de aprender, y la gente pronto se da cuenta una buena idea de qué estilo de uso funciona mejor para ellos y su proyecto.

— snogglethorpe

Lo que estás haciendo es el enfoque correcto.

Está utilizando el control de fuente desde el primer día: esto garantizará que tenga todo lo que necesita en el control de fuente y no haya ningún punto en el que pueda decir:

Debería estar usando el control de código fuente, pero va a tomar mucho tiempo registrar todo esto por primera vez.

Este es un obstáculo importante para las personas que llegan tarde al control de la fuente, ya que piensan que es "demasiado difícil" de usar. Al comenzar temprano y realizar cambios a menudo, ha reducido ese obstáculo a un pequeño paso y cualquier otra persona que se una a usted en el proyecto podrá ponerse a trabajar de inmediato.

— ChrisF
fuente