¿Por qué debería usar el control de versiones? [cerrado]

Estaba leyendo un blog donde el escritor dijo esto

"El código no existe a menos que esté registrado en un sistema de control de versiones. Use el control de versiones para todo lo que haga. Cualquier control de versiones, SVN, Git, incluso CVS, domínelo y úselo".

Nunca he usado ningún tipo de control de versiones y no me parece tan bueno. Lo busqué en Google y lo miré antes, pero solo necesito ponerlo en términos infantiles, por favor.

Según tengo entendido ahora, cosas como SVN son para almacenar su código en línea para que un grupo de usuarios u otros desarrolladores tengan acceso al mismo código. Una vez que actualice algún código, puede enviar la nueva versión y el SVN conservará copias del código antiguo y de los nuevos que actualice.

¿Es esta la idea básica o me estoy equivocando completamente?

Si tengo razón, entonces podría no ser de mucha utilidad si yo:

• No tenga otras personas trabajando en el código.
• No planee dejar que otros tengan el código.

Alguna vez has:

• ¿Hizo un cambio en el código, se dio cuenta de que era un error y quería volver?
• ¿Perdió el código o tuvo una copia de seguridad que era demasiado antigua?
• ¿Tenía que mantener varias versiones de un producto?
• ¿Desea ver la diferencia entre dos (o más) versiones de su código?
• ¿Quería demostrar que un cambio en particular rompió o arregló un código?
• ¿Quieres revisar el historial de algún código?
• ¿Desea enviar un cambio al código de otra persona?
• ¿Desea compartir su código o dejar que otras personas trabajen en su código?
• ¿Quería ver cuánto trabajo se está haciendo y dónde, cuándo y por quién?
• ¿Quería experimentar con una nueva característica sin interferir con el código de trabajo?

En estos casos, y sin duda en otros, un sistema de control de versiones debería facilitarle la vida.

Para citar mal a un amigo: una herramienta civilizada para una era civilizada.

Incluso si trabaja solo, puede beneficiarse del control de fuente. Entre otros, por estos motivos:

• No pierdes nada. Nunca más comenté el código. Simplemente lo borro. No abarrota mi pantalla, y no se pierde. Puedo recuperarlo revisando una confirmación anterior.

• Puedes experimentar a voluntad. Si no resuelve el problema, revísela.

• Puede consultar versiones anteriores del código para saber cuándo y dónde se introdujeron los errores. git bisectes genial en ese sentido.

• Las características más "avanzadas" como la ramificación y la fusión le permiten tener múltiples líneas paralelas de desarrollo. Puede trabajar en dos funciones simultáneas sin interferencia y cambiar de un lado a otro sin mucha molestia.

• Puedes ver "lo que cambió". Esto puede sonar básico, pero eso es algo que me encuentro comprobando mucho. A menudo comienzo mi flujo de trabajo de un solo hombre con: ¿qué hice ayer?

Solo ve y pruébalo. Comience lentamente con las funciones básicas y aprenda a otros sobre la marcha. Pronto descubrirá que nunca querrá volver a "las edades oscuras" sin VCS.

Si desea un VCS local, puede configurar su propio servidor de subversión (lo que hice en el pasado), pero hoy recomendaría usarlo git. Mucho más simple Simplemente cda su directorio de código y ejecute:

git init

Bienvenido al club.

El control de versiones es una herramienta rara que yo diría que es absolutamente necesaria, incluso si solo la está utilizando como desarrollador en solitario. Algunas personas dicen que es una herramienta por la que vives y mueres, estoy de acuerdo con esa afirmación.

Probablemente use el control de versiones en este momento, incluso si no lo sabe. ¿Tiene alguna carpeta que diga "XXX Php Code (December)" o "XXX.php.bak.2"? Estas son formas de control de versiones ya. Un buen sistema de control de versiones se encargará de esto automáticamente. Podrá retroceder a cualquier punto en el tiempo (que tenga datos registrados) y podrá ver una copia exacta de esos datos.

Además, si adopta un sistema como Subversion y utiliza un repositorio remoto (como uno en un servidor que posee), tendrá un lugar para guardar todo su código. ¿Necesita una copia de su código en otro lugar? No hay problema, solo échale un vistazo. ¿El disco duro se cuelga en casa? No es un problema (al menos con su código fuente).

Incluso si no usa el control de versiones ahora, es probable que lo use en un momento posterior de su carrera y podría beneficiarse de sentirse más cómodo con los principios ahora.

Incluso trabajando solo, ¿ha sucedido esto alguna vez? Ejecutas tu aplicación, y algo no funciona y dices "eso funcionó ayer, y juro que no toqué esa clase / método". Si está ingresando el código regularmente, una versión rápida de diferencias mostrará exactamente lo que ha cambiado en el último día.

Aquí hay un escenario que puede ilustrar la utilidad del control de código fuente incluso si trabaja solo.

Su cliente le pide que implemente una modificación ambiciosa del sitio web. Le llevará un par de semanas e implicará ediciones en muchas páginas. Te pones a trabajar.

Ha terminado el 50% con esta tarea cuando el cliente llama y le dice que abandone lo que está haciendo para hacer un cambio urgente pero más pequeño en el sitio. No ha terminado con la tarea más grande, por lo que no está lista para comenzar a funcionar, y el cliente no puede esperar el cambio más pequeño. Pero también quiere que el cambio menor se fusione con tu trabajo para un cambio mayor.

Tal vez está trabajando en la tarea grande en una carpeta separada que contiene una copia del sitio web. Ahora tiene que descubrir cómo hacer el cambio menor de una manera que se pueda implementar rápidamente. Trabajas furiosamente y lo haces. El cliente vuelve a llamar con más solicitudes de refinamiento. Usted también hace esto y lo implementa. Todo está bien.

Ahora tiene que fusionarlo con el trabajo en progreso para el cambio principal. ¿Qué cambiaste por el trabajo urgente? Estabas trabajando demasiado rápido para tomar notas. Y no puede simplemente diferenciar los dos directorios fácilmente ahora que ambos tienen cambios relativos a la línea base desde la que comenzó.

El escenario anterior muestra que el control de fuente puede ser una gran herramienta, incluso si trabaja solo.

• Puede usar ramas para trabajar en tareas a más largo plazo y luego fusionar la rama nuevamente en la línea principal cuando haya terminado.
• Puede comparar conjuntos completos de archivos con otras ramas o con revisiones anteriores para ver qué es diferente.
• Puede realizar un seguimiento del trabajo a lo largo del tiempo (lo cual es excelente para informar y facturar por cierto).
• Puede recuperar cualquier revisión de cualquier archivo según la fecha o un hito que haya definido.

Para trabajo en solitario, se recomienda Subversion o Git. Cualquiera es libre de preferir uno u otro, pero cualquiera es claramente mejor que no usar ningún control de versión. Los buenos libros son " Control de versiones pragmáticas usando Subversion, 2ª edición " de Mike Mason o " Control de versiones pragmáticas usando Git " de Travis Swicegood.

Autor original: Bill Karwin

Incluso como desarrollador único, el control de fuente ofrece un gran beneficio. Le permite almacenar el historial de su código y volver a las versiones anteriores de su software en cualquier momento. Esto le permite una flexibilidad intrépida para experimentar porque siempre puede restaurar a otra versión de su código fuente que estaba funcionando.

Es como tener un botón gigante de "deshacer" hasta la primera línea de código.

Es casi imposible vivir sin el control de versiones después de comenzar a usarlo. Es indispensable si más de un desarrollador está trabajando en la misma base de código ... pero también es bastante útil para un solo desarrollador.

Realiza un seguimiento de los cambios en su código y le permite volver a las versiones anteriores. Le libera experimentar con el conocimiento de que si algo se rompe, puede deshacer sus cambios.

Obtiene seguridad (en el sentido de tener una copia de seguridad de su código) y el control de versiones de su código (suponiendo que tenga el hábito de cometer sus cambios con frecuencia). Ambas son cosas muy buenas, incluso si nadie más termina trabajando en el código contigo ...

El control de versiones es excelente para verificar versiones anteriores, incluso si está trabajando solo. Por ejemplo, si borra accidentalmente el código o un archivo, puede recuperarlo; o puede comparar versiones anteriores para ver por qué se ha introducido un nuevo error. También es bueno si es una persona que trabaja en varias ubicaciones.

Mi favorito personal es git.

Existen varias razones para usar el control de versiones, incluso si usted es la única persona que alguna vez tocará el código.

• Copia de seguridad : ¿y si su disco duro falla? ¿Tienes una copia en alguna parte?
• Historial de revisiones : ¿actualmente guarda copias de código en diferentes carpetas? El control de versiones le brinda la capacidad de rastrear sus cambios a lo largo del tiempo y diferenciar fácilmente diferentes revisiones, fusionar, revertir cambios, etc. utilizando herramientas.
• Ramas : la capacidad de probar algunos cambios, seguir el seguimiento de lo que está haciendo y luego decidir si desea conservarlo y fusionarse con el proyecto principal o simplemente tirarlo.

Si mantiene su código bajo control de versión, entonces es realmente fácil ver qué archivos ha cambiado (o se ha olvidado de agregar a la línea de base).

Algo que nadie más parece haber mencionado explícitamente es el etiquetado o etiquetado de lanzamientos. Si tiene un cliente que utiliza la versión 1 de su software y está ocupado trabajando en la versión 2, ¿qué hace cuando el cliente informa un error y necesita compilar la versión 1.1?

Un sistema de control de fuente le permitirá etiquetar cada versión que realice para que pueda volver a ella más tarde, hacer la corrección (y fusionar esa corrección en el nuevo código de la versión 2) y hacer una nueva versión sin preocuparse de que pueda entregar accidentalmente algo que no está listo

El control de código fuente es una parte central del desarrollo moderno de software. Si no lo está utilizando (incluso para proyectos personales ya que mientras más experiencia tenga, mejor) está haciendo algo mal.

Por lo general, una de las primeras preguntas que hago cuando me entrevistan para un trabajo es "¿Qué utilizas para controlar la fuente?" Hasta ahora solo un lugar ha dicho "Nada", pero estaban planeando arreglar ese "Muy pronto ahora ..."

El hecho de que otros desarrolladores participen o no es totalmente ortogonal a la necesidad de un sistema de control de versiones.

Puede ser el único desarrollador, pero aún se beneficiará de:

• un recorrido histórico de todos tus cambios
• capacidad de retroceder y avanzar en esa historia
• capacidad de experimentar con la fuente y al mismo tiempo tener una versión funcional (ramificación)
• una copia de respaldo (especialmente si usa una máquina diferente como servidor de control de origen, y aún más si esa máquina se respalda regularmente)

Ahora, si tiene un grupo que se desarrolla en el mismo control de versión de base de código, aún es más necesario, por lo que

• las personas pueden editar el mismo archivo al mismo tiempo (dependiendo del sistema en particular, pero la mayoría de los sanos le permiten hacer esto)
• puedes decir quién hizo qué al código cuando

Cuando hay más personas involucradas, es más relevante la herramienta de control de versiones que elija, según el estilo de desarrollo.

También se trata de hacer una copia de seguridad del archivo antiguo que se llama "Subversion". Por lo tanto, puede administrar varias versiones de su trabajo en las que puede regresar (revertir) y administrar la implementación diferente (ramificación).

Puede encontrar que tenía una versión funcional de su programa.

Decide agregar algunas características nuevas durante un período de tiempo y lo libera.

Empiezas a recibir informes de errores que afectan a un código que creías que no tocaste.

Al utilizar SVN, por ejemplo, puede volver a una versión anterior y verificar si existe el nuevo error. Una vez que encuentre una versión que introdujo el error, será más fácil solucionarlo, ya que puede comparar la versión que funcionó con lo que no funcionó y ver qué cambió, entonces reducirá la búsqueda.

El control de código fuente tiene muchos usos, incluso si usted es el único desarrollador.

Parece que estás buscando algo un poco más liviano. Echa un vistazo a Mercurial ( impresionante libro de referencia ). Lo uso para todo, desde el código fuente hasta la correspondencia personal.

Algunos beneficios:

• Botón Deshacer gigante, para que pueda devolver los días felices de la semana pasada cuando el código realmente se ejecutó
• Código desechable. ¿No está seguro de si esta es la mejor manera de hacer algo? Haz una rama y experimenta. Nadie más que usted tiene que saberlo si está usando un DVCS como mercurial.
• Desarrollo sincronizado. Desarrollo en 4 computadoras diferentes. Empujo y jalo entre ellos para mantener la corriente, así que no importa en cuál esté, tengo las versiones más nuevas.

Incluso si aún no ha estado en una situación en la que necesitaba una versión anterior de su programa, tener un control de fuente le brinda mayor confianza para realizar cambios importantes.

Me encontré haciendo una refactorización más agresiva después de usar el control de código fuente porque siempre supe que una versión funcional podría restaurarse fácilmente.

También recientemente comencé a interesarme en el control de versiones. En los sistemas de control de versiones, tiene el concepto de un repositorio para su código. Una gran cantidad de nuevos comandos de shell se aprenden muy rápidamente para que pueda interactuar con este repositorio.

Una vez que guarde su código en un archivo, puede confirmarlo en el repositorio de su proyecto. A medida que desarrolla su código y confirma sus cambios, el repositorio desarrolla una serie de revisiones . Puede acceder a cualquiera de estos visitando una revisión. Si trabaja solo, es poco probable que haga mucho el proceso de verificación a menos que pierda sus archivos de código o desee trabajar en una máquina diferente. En estos casos, generalmente verificará la última revisión de todos los archivos.

Por mi parte, ya no mantengo archivos o carpetas llamados 'project_old' cuando decido refactorizar algo. Cualquier cambio que realice se almacena de forma incremental y siempre podré retroceder a un proyecto que funcionó en su conjunto. Raramente uso FTP para implementar ahora porque acabo de pagar mi código a través de ssh. Solo se descargan los archivos que he cambiado y si necesito volver a cargar en el servidor, el terminal ya está allí.

Encontré que esta charla en GIT es realmente instructiva; http://www.youtube.com/watch?v=4XpnKHJAok8

Es una charla en Google donde Linus Torvalds discute el uso de un sistema de control de versiones sobre otro. Al hacerlo, explica cómo funcionan usando conceptos y luego compara diferentes formas de implementarlos.

Probablemente querrá algo como subversión, incluso si está trabajando solo para tener un historial de todos sus cambios. Es posible que desee ver cómo se veía una pieza de código alguna vez para recordar por qué realizó un cambio.

Tener control de fuente también es útil cuando se registra con frecuencia. Si se registra con frecuencia, siempre estará en condiciones de retroceder con frecuencia. Muchas veces podrías comenzar a seguir un camino para resolver un problema y luego darte cuenta de que era el camino equivocado. Muchas veces podrías seguir ladrando por el camino equivocado y terminar creando una solución terrible, solo porque no querías perder todo tu trabajo. Al registrarse con frecuencia, el último punto de "felicidad" no está muy lejos, por lo que incluso si toma el camino equivocado, siempre puede retroceder e intentar nuevamente y encontrar una solución más elegante y simple. Lo que siempre es bueno para que pueda comprender y mantener lo que escribió en el futuro.

Depende del tamaño del proyecto y de la frecuencia con la que cambie de opinión sobre partes del mismo. Para proyectos pequeños en los que solo está haciendo algo de forma lineal, el control de versiones probablemente no será de mucha ayuda (aunque si accidentalmente elimina o corrompe un archivo sin control de versión, llorará).

Pero hace un par de semanas conocí a un amigo que estaba escribiendo un enorme proyecto de pasatiempos por su cuenta. Tenía diez o veinte copias de su código, con sufijos como "X1", "X2", "prueba", "más rápido", etc.

Si ha realizado más de dos copias de su código, se necesita el control de versiones . Un buen sistema de control de versiones le permite deshacer un cambio que realizó hace un tiempo sin deshacer lo que hizo después de realizar ese cambio. Te permite ver cuándo se hicieron ciertos cambios. Le permite dividir su código en dos "rutas" (por ejemplo, una para probar una nueva idea, la otra para mantener su código "probado y confiable" seguro hasta que haya terminado la prueba) y luego combinarlos nuevamente.

Es 2019. Me encuentro con objeciones, en esta fecha relativamente tardía, para usar Git; objeciones veo algunas planteando aquí. Esta discusión ha aclarado en gran medida el imperativo de usar el control de fuente en lugar de simplemente hacer copias de seguridad con nombre. Un punto clave es el uso del control de código fuente incluso cuando tenemos proyectos de desarrollador único. Nadie es perfecto. Cometes errores Si eres excepcionalmente bueno e inteligente, vas a desarrollar aplicaciones más complejas; pero aún cometerás algunos errores y esto lo maneja. Caray oh Pete! Nunca uso Linux, pero creo que todos respetamos la gran inteligencia técnica de Linus Torvalds. Reconoció la importancia del control de la fuente e hizo contribuciones clave al inicio de Git. Ese es un punto de resumen por todas las razones dadas aquí. Torvalds lo entiende: el control de la fuente es muy importante: usar control de fuente. Gracias a todos los que han comentado sobre este tema de larga duración.