usar - svn windows

¿Por qué debería usar el control de versión? (19)

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. Usa el control de versiones para todo lo que haces. Cualquier control de versiones, SVN, Git, incluso CVS, domínalo y úsalo".

Nunca he utilizado ningún tipo de control de versión y no me parece tan genial. Lo busqué en Google y lo miré antes, pero solo lo necesito poner en términos de niños, por favor.

Tal como lo entiendo 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 guardará copias del código anterior, así como de los nuevos que actualice.

¿Es esta la idea básica de esto o lo estoy entendiendo completamente mal?

Si estoy en lo cierto, entonces no sería de mucha utilidad si yo:

No hay otras personas trabajando en el código.
No piense en dejar que otros tengan el código.

Algo que nadie más parece haber mencionado explícitamente es el etiquetado o etiquetado de lanzamientos. Si tiene un cliente que usa 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 construir la versión 1.1?

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

El control de fuente es una parte central del desarrollo de software moderno. Si no lo está usando (incluso para proyectos personales, cuanto más experiencia tenga, mejor) está haciendo algo mal.

Por lo general, una de las primeras preguntas que hago al ser entrevistado para un trabajo es "¿Qué usas para el control de la fuente?" Hasta ahora, solo un lugar ha dicho "Nada" pero estaban planeando arreglar eso "Muy pronto ahora ..."

Alguna vez has:

¿Cambió el código, se dio cuenta de que era un error y quería volver?
¿Olvidaste el código o tenías una copia de seguridad que era demasiado antigua?
¿Tenía que mantener múltiples versiones de un producto?
¿Quería ver la diferencia entre dos (o más) versiones de tu código?
¿Quería demostrar que un cambio en particular rompió o arregló una pieza de código?
¿Quería revisar la historia de algún código?
¿Quería enviar un cambio al código de otra persona?
¿Quería 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 otros, un sistema de control de versiones debería hacer su vida más fácil.

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

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

Su cliente le pide que implemente una modificación ambiciosa del sitio web. Te tomará un par de semanas e involucrará ediciones en muchas páginas. Te pones a trabajar
Usted está al 50% de esta tarea cuando el cliente llama y le dice que abandone lo que está haciendo para hacer un cambio urgente pero menor al sitio. No ha terminado con la tarea más grande, por lo que no está lista para comenzar, y el cliente no puede esperar el cambio más pequeño. Pero también quiere que el cambio menor se fusione en su 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 pueda implementarse rápidamente. Trabajas furiosamente y lo haces. El cliente vuelve a llamar con nuevas solicitudes de refinamiento. Usted hace esto también y lo despliega. Todo está bien.
Ahora debe fusionarlo en el trabajo en progreso para el cambio principal. ¿Qué cambiaste por el trabajo urgente? Estabas trabajando demasiado rápido para guardar notas. Y no puede simplemente diferir 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 trabajas 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 termina.
Puede comparar conjuntos completos de archivos con otras ramas o revisiones pasadas para ver qué es diferente.
Puede realizar un seguimiento del trabajo a lo largo del tiempo (lo cual es excelente para informes y facturación por cierto).
Puede recuperar cualquier revisión de cualquier archivo según la fecha o el hito que haya definido.

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

Autor original: Bill Karwin

Depende del tamaño del proyecto y de la frecuencia con que cambies de opinión sobre partes del mismo. Para proyectos pequeños en los que simplemente se hace algo de forma lineal, el control de versiones probablemente no sea de mucha ayuda (aunque si accidentalmente elimina o corrompe un archivo sin control de versión, estará llorando).

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, necesita control de versión . Un buen sistema de control de versiones le permite deshacer un cambio que realizó hace un tiempo sin deshacer las cosas que hizo después de realizar ese cambio. Le permite ver cuándo se realizaron 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 de confianza" seguro hasta que haya terminado la prueba) y luego fusionarlas de nuevo.

El control de versiones es casi imposible de vivir sin que después de comenzar a usarlo. Es indispensable si más de un desarrollador trabaja 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 retroceder a las versiones anteriores. Te libera para experimentar con el conocimiento de que si algo se rompe, puedes deshacer tus cambios.

El control de versiones es ideal para verificar versiones anteriores, incluso si está trabajando solo. Por ejemplo, si accidentalmente borras un código o un archivo, puedes recuperarlo; o puede comparar versiones anteriores para ver por qué se ha deslizado un nuevo error. También es bueno si usted es una persona que trabaja en múltiples ubicaciones.

Mi favorito personal es git.

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

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

Además, si adoptas un sistema como la subversión y usas un repositorio remoto (como el que tienes en un servidor), tendrás un lugar donde guardar todo tu código. ¿Necesita una copia de su código en otro lugar? No hay problema, solo échale un vistazo. ¿Accidente de disco duro en casa? No es un problema (al menos con su código fuente).

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

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

Usted puede ser el único desarrollador pero aún se beneficiará de:

un historial de todos tus cambios
capacidad de ir y venir en esa historia
capacidad de experimentar con la fuente y al mismo tiempo tener una versión de trabajo (ramificación)
una copia de seguridad (especialmente si utiliza una máquina diferente como servidor de control de origen, y aún más si esa máquina se respalda periódicamente)

Ahora, si tiene un grupo en desarrollo en la misma versión de código, el control es aún más necesario

las personas pueden editar el mismo archivo al mismo tiempo (dependiendo del sistema en particular, pero las más sensatas le permiten hacer esto)
puedes decir quién hizo qué al código cuando

Cuando hay más personas involucradas, es más relevante qué herramienta de control de versiones elija, dependiendo del estilo de desarrollo.

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

Copia de seguridad : ¿y si tu disco rígido falla? ¿Tienes una copia en algún lado?
Historial de revisiones : ¿conserva copias de código en diferentes carpetas? El control de versiones te permite rastrear tus cambios a lo largo del tiempo y modificar fácilmente diferentes revisiones, combinar, deshacer cambios, etc. usando herramientas.
Sucursales : la capacidad de probar algunos cambios, aún seguir lo que está haciendo, y luego decidir si desea conservarlo e integrarse en el proyecto principal o simplemente descartarlo.

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

Incluso como un solo control de fuente desarrollador ofrece un gran beneficio. Le permite almacenar el historial de su código y volver a versiones anteriores de su software en cualquier momento. Esto le permite una intrépida flexibilidad 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" desde la primera línea de código.

Incluso si aún no ha estado en una situación en la que necesitara una versión anterior de su programa, tener un control de fuente le da 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 de trabajo podría restaurarse fácilmente.

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

No pierdes nada. Nunca más comenté el código. Simplemente lo borro. No satura mi pantalla, y no se pierde. Puedo recuperarlo revisando un compromiso anterior.
Puedes experimentar a voluntad. Si no resuelve el problema, inviértalo.
Puede consultar las versiones anteriores del código para averiguar cuándo y dónde se introdujeron los errores. git bisect es genial en ese sentido.
Las funciones más "avanzadas" como la bifurcación y la fusión le permiten tener múltiples líneas paralelas de desarrollo. Puede trabajar en dos funciones simultáneas sin interferencias y cambiar de un lado a otro sin mucha molestia.
Puedes ver "qué ha cambiado". Esto puede sonar básico, pero eso es algo que me estoy revisando mucho. Muy a menudo comienzo mi flujo de trabajo de un solo hombre con: ¿qué hice ayer?

Solo adelante y pruébalo. Comience lentamente con las funciones básicas y aprenda otras a medida que avanza. Pronto descubrirá que no querrá regresar a "las edades oscuras" de ningún VCS.

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

git init

Bienvenido al club.

Incluso trabajando solo, ¿ha sucedido esto alguna vez? Usted ejecuta su aplicación, y algo no funciona y usted dice "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 diferencia mostrará exactamente lo que ha cambiado en el último día.

Obtienes seguridad (en el sentido de tener una copia de seguridad de tu código) y versiones de tu código (suponiendo que adquieras el hábito de cometer tus cambios a menudo). Ambas son cosas muy buenas, incluso si nadie más termina trabajando en el código contigo ...

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

Algunos beneficios:

Gigante botón Deshacer, para que pueda devolver esos días felices de la semana pasada cuando el código se ejecutó
Código de desecho. ¿No estoy seguro si esta es la mejor manera de hacer algo? Haz una rama y experimenta. Nadie más que tú debe saberlo si está usando un DVCS como mercurial.
Desarrollo sincronizado. Desarrollo en 4 computadoras diferentes. Empujo y tira entre ellos para mantener la corriente, así que no importa en cuál estoy, tengo las versiones más nuevas.

Probablemente desee algo así como la subversión, incluso si está trabajando solo para que tenga un historial de todos sus cambios. Es posible que desee ver qué aspecto tenía una pieza de código en alguna ocasión para recordar por qué hizo un cambio.

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

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

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

Empiezas a recibir informes de errores que afectan algún código que creías que no tocabas.

Al usar SVN, por ejemplo, puede volver a una versión anterior y verificar si existe la nueva falla. 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ó, y luego reducirá la búsqueda.

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

Recientemente, también empecé a interesarme por 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 rápidamente para que pueda interactuar con este repositorio.

Una vez que guarde su código en un archivo, puede enviarlo al repositorio de su proyecto. A medida que desarrolla su código y compromete sus cambios, el repositorio desarrolla una serie de revisiones . Puede acceder a cualquiera de estos revisando una revisión. Si trabajas solo, es poco probable que vayas a hacer muchas cosas a menos que pierdas tus archivos de código o quieras trabajar en una máquina diferente. En estos casos, generalmente verificará la última revisión de todos los archivos.

Por mi parte, ya no guardo archivos o carpetas con el nombre ''project_old'' cuando decido refacturar algo. Cualquier cambio que realice se almacenará gradualmente y siempre podré retroceder hacia un proyecto que funcionó como un todo. Raramente uso el FTP para implementar ahora porque simplemente pago 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, la terminal ya está allí.

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

Es una charla de google donde Linus Torvalds hace un argumento para usar un sistema de control de versiones sobre otro. Al hacerlo, explica cómo funcionan usando conceptos y luego compara diferentes formas de implementarlos.

También se trata de hacer una copia de seguridad de un archivo antiguo por lo que se llama "Subversión". De modo que puede administrar versiones múltiples de su trabajo en las que puede regresar (revertir) y administrar las diferentes implementaciones (bifurcación).