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

123

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.
JasonDavis
fuente
44
que quiere decir que estaba leyendo "el horror de codificación" ...
Jason
53
Es un fenómeno extraño que muchos desarrolladores (generalmente al principio de sus carreras) mantengan esta opinión, y es solo cuando los obligas a usar el control de fuente que los beneficios comienzan a desmoronarse en sus cabezas.
Spender
44
Manos arriba que no comparte la vergüenza de Martinho. :)
Spender
44
Alguien le muestra a @TimEckel una bisección, donde el control de versiones te señala mágicamente un cambio de tres líneas desde hace tres meses y dice "el error se introdujo aquí". Mente = soplado.
Jonathan Hartley
55
@TimEckel, todavía está utilizando un control de versiones, otro tipo con menos funciones.
Abhinav Gauniyal

Respuestas:

261

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.

si618
fuente
20
Este chico lo ha clavado. Incluso cuando trabajo solo en proyectos, prefiero tener algún control de versión en ejecución. La demostración totalmente funcional de Perforce para 2 usuarios es excelente para eso.
Almo
3
suena útil ... hasta que tenga que aprenderlo y dominarlo. je
potasmic
77
Buenos puntos. Sin embargo, tenga en cuenta que el control de versiones no es una copia de seguridad. Una copia de seguridad se almacena en un sistema / medio separado y mantiene copias de seguridad antiguas durante un tiempo (en caso de que su repositorio se arruine de alguna manera).
sleske
1
No podría estar más de acuerdo con Sleske. Es por eso que junto con nuestra copia de seguridad de máquina virtual estándar y la verificación del repositorio nocturno, mantengo un repositorio espejo que se sincroniza cada hora y también está respaldado y verificado :) Utilizamos Subversion y hemos encontrado que svnedge es un buen producto.
si618
77
Hola Tim, ¿cómo rastreas tu historial de cambios? ¿Cómo vincula su historial de cambios a un rastreador de problemas o notas de lanzamiento? ¿Cómo gestionas la fusión de diferentes ramas de tu código? ¿Cómo encuentra los cambios que realizó en sus últimas 100 versiones? Tal vez si codifica solo, o si nunca se preocupa por qué cambió el código, tal vez solo tener una copia de seguridad sea suficiente, pero apuesto a que una vez que haya usado un VCS decente, comprenderá por qué tanta gente los usa.
si618
56

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.

R. Martinho Fernandes
fuente
eso suena bien, por lo que puede ser local y no tiene que estar en la web para que nadie lo vea. Yo uso PHP Designer, me encanta y que tiene la integración de Tortoise SVN, no está seguro de si eso es una buena idea
JasonDavis
1
para comenzar, simplemente use cualquier cosa; luego, después de un tiempo, cuando sepa un poco, lea las alternativas y pruebe una de ellas, luego otra y así sucesivamente
1800 INFORMACIÓN
55
+1 para la viñeta sobre el código de nunca comentario
Ed Schembor
2
@jasondavis en respuesta a sus preguntas específicas (aunque probablemente ya lo sepa), puede usar cualquier VCS distribuido (git, mercurial, etc.) localmente, sin un servidor. También podría usar un VCS centralizado (CVS, SVN, etc.) localmente, pero sería mucho más molesto configurarlo y no proporcionaría muchos beneficios. Independientemente del VCS que use, puede tenerlo en un servidor y aún no tenerlo en público (útil para transferir entre computadoras y proporcionar otra copia de seguridad): busque "repositorio privado". No puedes usar TortoiseSVN con git, pero hay un Tortoise-Git por ahí.
naught101
18

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.

Robert Venables
fuente
16
... o "Copia de Copia de Copia de MyWork"
gastador
1
@spender: Exactamente, eso es lo que recuerdo de los días oscuros antes de comenzar a usar el control de versiones :-)
Robert Venables
Suena muy útil y mi proyecto actual es algo grande, al menos 150-200 archivos, ¿cómo funciona esto? Escucho "versión" que significa como la versión 1 y la versión 2, si el número aumenta, ¿qué pasa si modifico 1? archivo y no el resto, ¿tendré 200 copias de código no modificado o solo copias de archivo que se modifican?
JasonDavis
1
Solo se almacena el delta de sus cambios, por lo que si cambia una línea en un archivo, eso es todo lo que se almacenará en esa versión. Un archivo en control de versiones se puede considerar como la suma de todos sus cambios
gastado el
1
He viajado a través del tiempo para corregir el comentario sobre mí: el control de versiones no necesariamente almacena solo el delta, sino que representa la versión como un delta.
henrebotha
14

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.

Ed Schembor
fuente
O simplemente extraigo la última versión de mis copias de seguridad que se crean cada vez que guardo un archivo.
Tim Eckel
@TimEckel y otras personas simplemente revierten sus cambios :)
Abhinav Gauniyal
13

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

Robert Harvey
fuente
10

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.

gbc
fuente
7

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.

Vincent Ramdhanie
fuente
El control de versiones me parece lento, ineficiente y obstaculiza el desarrollo. Es mucho más fácil configurar una copia de seguridad automatizada en la nube de todos los archivos que guarda automáticamente las últimas 100 actualizaciones. Nada para obtener, presionar o sincronizar. Solo codigo.
Tim Eckel
5

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 ...


fuente
3

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.

Peter
fuente
3

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).

Mads Hansen
fuente
3

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 ..."


fuente
2

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.

Vinko Vrsalovic
fuente
1

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).

NawaMan
fuente
1

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.

James Black
fuente
1

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.
Jonathanb
fuente
1

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.

Otto Allmendinger
fuente
1

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.

deau
fuente
Pero, ¿y si rompes algo entre commits? Entonces estás perdido. Cuando usa el control de versiones automatizado, nunca tiene este problema que existe al usar servicios de control de versiones inútiles como GitHub y similares.
Tim Eckel
1
@TimEckel, ¿qué quieres decir con 'romper algo b / w commits'? Si escribo algo después de mi última confirmación y confirmo nuevos cambios con código que no funciona, entonces revierto mis cambios a la última confirmación. Tan sencillo como eso.
Abhinav Gauniyal
@TimEckel decir que GitHub es inútil es como decir que Linux es inútil: millones estarían en desacuerdo contigo, pero lo dices de todos modos porque obviamente eres más inteligente que esos millones, ¿verdad?
Charleh
1
@Charleh solo porque millones lo usen, no significa que sea bueno. Millones todavía usan AOL y tienen álbumes de Britney Spears. Uso GitHub todos los días y lo odio cada vez que lo uso. No veo la necesidad, se interpone y ralentiza las cosas.
Tim Eckel
0

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.

digiarnie
fuente
0

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.

Artelius
fuente
-2

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.

JPDura
fuente