Nunca estoy seguro de cuándo un proyecto está lo suficientemente lejos como para comprometerse primero con el control de origen. Tiendo a posponer el compromiso hasta que el proyecto esté 'completo en el marco', y a partir de ese momento confirmo principalmente las características. (No he realizado ningún proyecto personal lo suficientemente grande como para tener un marco central demasiado grande para esto). Tengo la sensación de que esta no es la mejor práctica, aunque no estoy seguro de qué podría salir mal.

Digamos, por ejemplo, que tengo un proyecto que consiste en un solo archivo de código. Tomará alrededor de 10 líneas de código repetitivo y 100 líneas para que el proyecto funcione con una funcionalidad extremadamente básica (1 o 2 características). ¿Debo primero registrarme?

1. El archivo vacio?
2. El código repetitivo?
3. Las primeras características?
4. En algún otro punto?

Además, ¿cuáles son las razones para registrarse en un punto específico?

Debe comprometerse tan pronto como tenga una "unidad" sensata completa.

¿Qué es una unidad? Depende de lo que estés haciendo; si está creando un proyecto de Visual Studio, por ejemplo, confirme la solución justo después de su creación, incluso si no tiene nada.

A partir de ahí, siga comprometiéndose tan a menudo como sea posible, pero aún así confirme solo "unidades" completadas (por ejemplo, clases, configuraciones, etc.); hacerlo le facilitará la vida si algo sale mal (puede revertir un pequeño conjunto de cambios) y reducirá la probabilidad de conflictos.

En lo que a mí respecta, su repositorio de control de origen es parte de la configuración básica del proyecto, por lo que me comprometo justo después de generar mi proyecto vacío.

Ayer

... alternativamente, si no puede viajar en el tiempo ...
(tal vez su automóvil no puede alcanzar 88 mph, o su condensador de flujo simplemente se rompió)

Ahora

Los nuevos proyectos deben comprometerse en el acto sangriento, es una locura no hacerlo, y los sistemas DVCS contemporáneos simplemente eliminaron todas las excusas posibles para evitar compromisos : git init . ; git add * ; git commit -m initial-commitahora, antes de que sea demasiado tarde, como ya podría ser.

Una pregunta más sensata y discutible podría haber sido: "¿Cuándo debería fusionar mis compromisos con un control de fuente compartido en un repositorio administrado por un equipo en un proyecto establecido ?" (tenga en cuenta los adjetivos, los adjetivos son importantes) Y tengo la sensación de que la mayoría de las otras respuestas en realidad están tratando de responder a eso.

Debe comprometerse con su rama personal como loca , al menos una vez al día , antes de acostarse. Puede que te despiertes la mañana siguiente y descubras que no tienes idea de qué demonios estabas haciendo la noche anterior. El VCS debería cubrirlo en contra de eso, y tener la oportunidad de revertir a una sub-versión-de-una-sub-versión muy reciente que se compila bien, se ejecuta sin problemas y / o pasa las pruebas podría ser su mejor opción.

Yo diría comprometerse lo antes posible. El objetivo principal del control de fuente es permitirle regresar en caso de que algo salga mal, y esto resuena con la práctica de "comprometerse temprano y con frecuencia".

Personalmente, mi primer commit generalmente contiene solo el archivo .gitignore (o equivalente) con algunos filtros que sé que serán necesarios, como * .py [co] para el código Python. La configuración básica del proyecto y / o el primer prototipo más simple es lo que generalmente sigue.

El primer commit puede ser un archivo README con tan solo un resumen de línea del proyecto, o suficiente información sobre el primer hito del proyecto. Los temas generales también pueden incluir:

• Introducción
• Descripción del Proyecto
• Estructura del proyecto
• Convenciones de codificación
• Instrucciones sobre cómo:
  • construir
  • prueba
  • desplegar
• Problemas conocidos y soluciones alternativas
• lista de quehaceres
• Términos de Uso

La práctica de actualizar el archivo README antes de realizar cambios en un proyecto también se conoce como desarrollo impulsado por el archivo Léame y le permite pensar en los cambios antes de invertir tiempo en realizarlos.

Cualquier persona que quiera contribuir o utilizar este software comenzará con el archivo README.

Si ha realizado un trabajo que no querría perder, debería estar en su sistema de control de fuente.

Esto ciertamente se aplica a sistemas distribuidos como Git. Si está utilizando un sistema centralizado, y la única forma de registrar algo es hacer que sea visible para todos , es posible que desee esperar, o puede considerar configurar su propio repositorio git local y enviarlo al servicio centralizado. sistema cuando estés listo.

Mi regla general es registrarme una vez que mi archivo de solución (u otra pieza de script de compilación) esté listo, incluso si contiene algunos archivos que están vacíos. Es una buena práctica cuando más de una persona está trabajando en el proyecto. Ese archivo tiende a tener los peores problemas de fusión inicialmente, ya que las personas están agregando cosas al proyecto, por lo que deben comprometerse temprano y con frecuencia.

Incluso si usted es el único que trabaja en el proyecto y solo tiene un archivo, me resulta más fácil seguir el mismo flujo de trabajo y guardar el pensamiento para el problema en cuestión.

No estoy seguro si fue mencionado.

¡Pero asegúrate de que lo que confirmes se ejecute / compile! Entonces no hay errores de sintaxis, etc.

Nada más frustrante que pagar el código que está roto.

Otro punto de vista más relacionado con las pruebas de software (enfoque TDD) se comprometería tan pronto como tenga nuevos casos de prueba en verde. Esto significaría que tiene una nueva "unidad" de código completada.

Justo antes de hacer algo tonto.

Para aquellos de nosotros sin poderes mágicos, eso significa poco y con frecuencia.

Si está trabajando solo, hágalo cada vez que tome una bebida, o lo que sea.

Si está trabajando en un equipo, probablemente deba asegurarse de que la cosa se compila, de modo que si alguien más obtiene lo último, no recibirá una bolsa de errores. Pero aparte de eso, tanto como puedas.

Aproximadamente 2 ~ 3 horas en el proyecto.

Solo bromeaba. No hay una buena respuesta que se ajuste a todas las situaciones. En primer lugar, si tiene un sistema de control de versiones distribuido (como git o Mercurial), comprometerse con su repositorio local no va a preservar sus datos en caso de falla catastrófica. Pero un repositorio remoto privado puede costarle dinero, por ejemplo, en github. Conservará el historial de confirmación, pero en mi experiencia no lo necesitará hasta que su proyecto esté un poco avanzado.

Además, probablemente no desee demasiada rotación al principio, especialmente si está moviendo archivos. Cometer cambios será una carga si solo es pequeña. Incluso puede decidir tirar la cosa a la basura. Pero si pierde cambios que no son triviales de replicar, perderá haber realizado una copia de seguridad, y los sistemas de control de versiones hacen que los sistemas de copia de seguridad sean extremadamente valiosos.

Algunas personas hoy en día usan DropBox o similar para almacenar su código. Puede ser un buen compromiso al comienzo de un proyecto, ya que requiere cero esfuerzo para configurarlo. Sin embargo, es un hábito bárbaro en el desarrollo de software serio, especialmente si varias personas tocan el código al mismo tiempo.

Por lo tanto, tiendo a configurar el control de versiones cada vez que tengo algo valioso, es decir, que no es trivial replicar. El valor es subjetivo (y depende de las capacidades de uno), por lo que tendrá que hacer su propio juicio. En ese momento almaceno un segundo repositorio en un disco externo, o en github si es un proyecto público o mi cuenta de pago lo mantendrá.

Muchas personas ya han respondido "de inmediato", y estoy 100% de acuerdo. También me gusta la sugerencia de Xion de comenzar con los patrones de ignorar del VCS (es decir, .gitignoreo equivalente).

Supongo que está bastante de acuerdo en que no hay inconvenientes para las primeras confirmaciones. Me gustaría agregar ventajas:

• Es menos probable que cometas cosas que elegiste descartar pero que aún persisten. Cuando comienzo un nuevo desarrollo, codificaré y descifraré cosas rápidamente, y cuando me comprometí más tarde, cuando ya hay un montón de archivos, accidentalmente comprometí cosas solo para eliminarlas en la próxima confirmación. Esto, a diferencia de los pequeños, o incluso vacíos, commits, es un verdadero ruido en la historia.
• Si usted es un tipo sistemático y tiene los primeros pasos típicos en sus proyectos, tenerlos como puntos de compromiso puede ser instructivo para usted o para otros, e incluso podría brindarle la oportunidad de ramificarse en cierto punto y crear un trozo de proyecto reutilizable. He trabajado en proyectos basados ​​en Maven donde esto fue útil (porque al configurar un proyecto Maven, algunos pequeños primeros pasos ya pueden definir una base bastante sustancial, y aunque esos pasos no son mucho para hacer , pueden requerir suficiente pensamiento para garantizar reutilización).

Puede depender de qué VCS está utilizando.

Con Git, confirmo un directorio vacío (o con un archivo README casi vacío). El punto es que puedo regresar y restablecer mi rama a ese estado vacío si quiero comenzar de nuevo por completo mientras todavía estoy al principio del proceso de desarrollo (antes de avanzar). Luego, confirmaría mis archivos "generados" (por ejemplo, solución de estudio visual). Luego, cuando realmente estoy codificando, comenzaré a comprometer cada unidad como lo harías normalmente.

Con SVN, está avanzando hacia arriba con cada confirmación para que realmente no tenga el lujo de comenzar de nuevo como lo hace con Git. En este caso, puede que no sea beneficioso comprometerse temprano si cree que va a realizar una renovación importante al principio del proceso. Sin embargo, eso dependerá de la persona que codifique.

Cuando comienzo un nuevo proyecto, generalmente empiezo por confirmarlo antes de que se agregue ningún código. Una regla general que siempre he seguido es: si su PC se bloqueó y borró todos sus datos, ¿qué código preferiría no tener que escribir desde la memoria? Hace diez años, antes de TDD y una mejor práctica de programación, era bastante optimista sobre lo que podía recordar. Ahora, tiendo a ser más cauteloso. Como muchos otros carteles han dicho comprometerse temprano y comprometerse a menudo. No estás perdiendo nada al hacerlo.

Estoy trabajando solo la mayor parte del tiempo, así que debo confesar que me estoy aflojando, pero generalmente me comprometo antes de irme a casa. De esa manera, si no llego mañana, mis colegas pueden retomar donde lo dejé.

Actualmente estoy usando Tortoise / SVN en el trabajo.

Compromete el proyecto vacío de inmediato. Siga comprometiéndose varias veces por hora que pasa trabajando en el proyecto. Comprometerse incluso si el código no se compila. Marco tales confirmaciones con "WIP" en el masaje de confirmación para realizar un seguimiento de ellas.

También tengo un script que confirma automáticamente todos mis proyectos cada 10 minutos en un repositorio de respaldo, en caso de que me olvide de confirmar manualmente. Llamémoslo mi búfer de deshacer respaldado en la nube.

Registre (también conocido como push ) el proyecto en un repositorio de equipo cuando necesite que su equipo vea su código. Probablemente antes de que tu equipo esté listo para que tu código lo vea, si eres como yo.

Si quieres ser amable con tu equipo, aplasta tus compromisos antes de llevarlos al repositorio del equipo.

He revisado todos los artículos y creo que ya obtuvimos muchas buenas soluciones, pero me gustaría compartir mi metodología con ustedes.

Mientras se trabaja en la creación del marco (desde cero), se realizarán muchos cambios para cada módulo hasta que el módulo se complete o finalice. Así que siempre tengo 2 ubicaciones, una se llama DINÁMICA y la otra es ESTÁTICA. Cuando los cambios continúan y el marco aún no está finalizado, se confirma en la ubicación DINÁMICA y una vez que se completa y finaliza, lo muevo a la ubicación ESTÁTICA. Entonces tengo un control de fuente completo.

Gracias

Con cualquier aplicación, pasará algún tiempo diseñando los componentes. Debe conocer, en detalle o en detalle, sus espacios de nombres, proyectos, referencias externas, bibliotecas de terceros, etc.

Si está en un equipo, le sugeriría a su líder, o al que sea elegido, que cree el proyecto base, establezca las dependencias y verifique ese esqueleto (base en la que se construirá su proyecto).

También debe asegurarse de tener sus ramas de tarea, liberación, troncal, etc. especificadas antes de registrarse para que su proceso sea sólido.

Si está trabajando en una nueva "tarea" para un proyecto que ya está en marcha y está en su propia rama de tareas, realice sus controles nocturnos para preservar su trabajo.

Por lo general, me registro cada vez que agrego algo nuevo, pero trato de separar las cosas en confirmaciones discretas.

Eso significa que, si agrego una nueva dependencia, realizo los cambios hasta que se compilan o son lo suficientemente grandes como para que se pierda tiempo desde cero. Si tengo una tarea más grande, intento comprometerme varias veces, cuando tiene sentido (una vez por función, cada vez que la compilo y ejecuto con éxito, etc.).

También me comprometo cuando quiero un punto de respaldo (es decir, "si lo que intento ahora no funciona o se vuelve demasiado complicado, quiero volver al código como está ahora", o cuando alguien me pide que deje lo que soy haciendo y solucionar un problema urgente).

Si usa un sistema de control de fuente centralizado, no puede comprometerse arbitrariamente para puntos de respaldo, porque un compromiso que no compila / funciona afecta a todos en su equipo.

Por lo general, cuando comienzo a agregar código repetitivo (por ejemplo, agregar una nueva aplicación web en un sitio web de django), confirmo cada operación que hago.

Si sigo un tutorial para generar / escribir código, uso nombres de pasos en el tutorial para enviar mensajes. De esta manera, puedo diferenciar las revisiones y ver qué hizo un paso tutorial, en cualquier momento posterior.

Digamos, por ejemplo, que tengo un proyecto que consiste en un solo archivo de código. Tomará alrededor de 10 líneas de código repetitivo y 100 líneas para que el proyecto funcione con una funcionalidad extremadamente básica (1 o 2 características).

Dependería de lo difícil que sea agregar el material:

• si fuera trivial agregar el código de placa de caldera, lo agregaría y me comprometería justo antes de comenzar con el otro código (de esta manera, si cometo un error o introduzco un error extraño más tarde, simplemente puedo volver al código de placa de caldera y comenzar de nuevo).

• Si el código no fuera trivial, me comprometería cada vez que agrego algo nuevo (en cualquier lugar entre cada dos líneas de código cambiadas, a un centenar más o menos).