Debes comprometerte tan pronto como tengas 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 inmediatamente después de su creación, incluso si no tiene nada en ella.

A partir de ahí, siga cometiendo con la mayor frecuencia posible, pero aún así confirme solo "unidades" completadas (por ejemplo, clases, configuraciones, etc.); Si lo hace, le será más fácil la vida si algo va 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 fuente 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

... en alternativa, si no puedes viajar en el tiempo ...
(tal vez su automóvil no pueda alcanzar los 88 mph, o simplemente se haya roto el condensador de flujo)

Ahora

Los nuevos proyectos deben comprometerse en el lugar 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-commit ahora, antes de que sea demasiado tarde, ya que ya podría ser.

Su rama personal debe comprometerse con like crazy , al menos una vez al día , antes de irse a dormir. Puede que despiertes la mañana siguiente y descubras que no tienes ni idea de qué diablos estabas haciendo la noche anterior. El VCS debería cubrirlo contra eso, y tener la oportunidad de revertir a una sub-versión muy reciente de una sub-versión que se compila muy bien, se ejecuta sin problemas y / o las pruebas de aprobación podrían ser su mejor opción.

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

La primera confirmación puede ser un archivo README con tan solo una línea de resumen 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
• lista de tareas pendientes
• Términos de uso

La práctica de actualizar el README antes de hacer cambios en un proyecto también se conoce como Readme Driven Development y le permite analizar los cambios antes de invertir tiempo en hacer esos cambios.

Cualquier persona que quiera contribuir o usar este software comenzará con 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 hacerlo visible para todos , puede querer esperar, o puede que considerando configurar tu propio repositorio local de git y enviarlo al sistema centralizado cuando estés listo.

Mi regla de oro es registrar una vez que se haya completado el archivo de mi solución (u otra parte del script de compilación), incluso si contiene algunos archivos que están vacíos. Es una buena práctica para 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 las necesidades se comprometen pronto y con frecuencia.

Incluso si eres el único que está trabajando 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 está seguro si se mencionó.

Pero asegúrese de que lo que confirme se ejecute / compile. Así que no hay errores de sintaxis, etc.

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

Otro punto de vista relacionado con las pruebas de software (enfoque TDD) se estaría comprometiendo tan pronto como tenga nuevos casos de prueba en verde. Esto significaría que tienes 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ás trabajando solo, hazlo cada vez que tomes una bebida, o lo que sea.

Si estás trabajando en un equipo, probablemente debas asegurarte de que la cosa se compile, de modo que si alguien más se pone al día, no reciba una bolsa de errores. Pero aparte de eso, tanto como puedas.

Aproximadamente 2 ~ 3 horas en el proyecto.

Solo bromeando. 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 conservará sus datos en caso de un fallo catastrófico. Pero un repositorio remoto privado puede costarle dinero, por ejemplo. en github. Conservarás el historial de confirmación, pero en mi experiencia no necesitarás eso hasta que tu proyecto esté un poco avanzado.

También es probable que no desees demasiada rotación al principio, especialmente si estás moviendo archivos. Cometer cambios será una carga aunque solo sea pequeña. Incluso puedes decidir tirar la cosa. Pero si pierde cambios que no son triviales de replicar, perderá haber hecho una copia de respaldo, y los sistemas de control de versiones lo convierten en sistemas de respaldo extremadamente valiosos.

Actualmente, algunas personas usan DropBox o similar para almacenar su código. Puede ser un buen compromiso al comienzo de un proyecto, ya que no requiere ningún esfuerzo para configurarlo. Sin embargo, es un hábito brutal en el desarrollo de software serio, especialmente si varias personas están tocando el código al mismo tiempo.

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

Muchas personas ya respondieron "De inmediato" y estoy de acuerdo al 100%. También me gusta la sugerencia de Xion para comenzar con los patrones de ignorar de VCS (es decir, .gitignore o equivalente).

Supongo que está bastante de acuerdo en que no hay inconvenientes en los compromisos iniciales. Me gustaría añadir ventajas:

• Es menos probable que cometas cosas que elegiste descartar, pero eso sigue persistiendo. Cuando empiezo un nuevo desarrollo, codifico y discrimino las cosas rápidamente, y cuando las confirmo más tarde, cuando ya hay un montón de archivos, accidentalmente cometí cosas solo para eliminarlas en la próxima confirmación. Esto, a diferencia de los compromisos pequeños, o incluso vacíos, es un verdadero ruido en la historia.
• Si eres un tipo sistemático y tienes primeros pasos típicos en tus proyectos, tenerlos como puntos de compromiso puede ser instructivo para ti o para otros, e incluso puede proporcionar una oportunidad para derivarse en un cierto punto y crear un reutilizable. talón del proyecto. He trabajado en proyectos basados en Maven donde esto fue útil (porque al configurar un proyecto Maven, algunos primeros pasos pequeños ya pueden definir una base bastante sustancial, y aunque esos pasos no son mucho para hacer , pueden requerir suficiente pensamiento para justificar la reutilización).

Puede depender de qué VCS estés usando.

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 aún estoy en una etapa temprana del proceso de desarrollo (antes de realizar la subida). Luego cometería mis archivos "generados" (por ejemplo, la solución de estudio visual). Luego, cuando esté codificando, comenzaré a cometer cada unidad como lo harías normalmente.

Con SVN, estás presionando en sentido ascendente con cada compromiso, por lo que realmente no tienes el lujo de volver a empezar como lo haces 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 empiezo un nuevo proyecto, generalmente comienzo comprometiéndolo antes de agregar ningún código. Una regla general que siempre he seguido es: si su PC falla y borra 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 cauto. Como muchos otros carteles han dicho, comprometerse temprano y comprometerse a menudo. No estás perdiendo nada haciéndolo.

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

Actualmente estoy usando Tortoise / SVN en el trabajo.

Confirme el proyecto vacío de inmediato. Sigue cometiendo varias veces por hora que pasas trabajando en el proyecto. Cometer incluso si el código no se compila. Marqué dichos compromisos con "WIP" en el masaje de confirmación para realizar un seguimiento de ellos.

También tengo una secuencia de comandos que automáticamente confirma todos mis proyectos cada 10 minutos en un repositorio de respaldo, en caso de que se me olvide realizar la confirmación manualmente. Llamémoslo mi búfer de deshacer respaldado por la nube.

Incorporar (también conocido como empujar ) el proyecto a un equipo de apoyo cuando necesite que su equipo vea su código. Probablemente antes de que su código esté listo para que lo vea su equipo, si usted es como yo.

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

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

Mientras se trabaja en la creación de la estructura (desde cero), se llevarán a cabo muchos cambios para cada módulo hasta que el módulo se complete o finalice. Así que siempre tengo 2 ubicaciones, una se llama DYNAMIC y la otra es STATIC. Cuando se están llevando a cabo los cambios y el marco aún no está finalizado, se ha confirmado en la ubicación de DYANMIC y una vez que se completa y finaliza, lo muevo a la ubicación ESTÁTICA. Así que tengo un control de fuente completo.

Gracias

Con cualquier aplicación, vas a pasar algo de tiempo diseñando los componentes. Debería conocer, de forma general o completa, sus espacios de nombre, proyectos, referencias externas, bibliotecas de terceros, etc.

Si está en un equipo, sugeriría su líder, o la persona elegida, para crear el proyecto base, establecer las dependencias y verificar el esqueleto (base sobre la que se construirá su proyecto).

También desea asegurarse de tener sus tareas, liberación, troncal, etc. ramas 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 se encuentra en su propia rama de tareas, realice los controles nocturnos para preservar su trabajo.

Por lo general, me registro cuando agrego algo nuevo, pero trato de separar cosas en confirmaciones discretas.

Eso significa que si agrego una nueva dependencia, hago los cambios hasta que se compilan, o son lo suficientemente grandes como para perder el tiempo para volver a hacerlos, desde cero. Si tengo una tarea más grande, trato de ejecutar 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 complica demasiado, quiero volver al código como está ahora", o cuando alguien me pide que lo suelte lo que estoy haciendo y soluciono un problema urgente).

Si usas un sistema de control de fuente centralizado, no puedes comprometer arbitrariamente puntos de respaldo, porque un compromiso que no compila / trabaja afecta a todos en tu equipo.

Por lo general, cuando comienzo a agregar el código de repetición (por ejemplo, agrego 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 los nombres de los pasos en el tutorial para confirmar los mensajes. De esta manera, puedo hacer revisiones diferentes y ver lo que hizo un paso tutorial, en cualquier punto posterior.

  

Digamos, por ejemplo, que tengo un proyecto que consiste en un solo archivo de código. Tomará aproximadamente 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 funciones).

Dependería de lo difícil que sea agregar las cosas:

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

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