¿Cómo usan los desarrolladores de aplicaciones profesionales los sistemas de control de versiones, como GIT y Subversion?

9

Soy un desarrollador principiante y me he estado preguntando desde el principio, ¿cómo usan herramientas profesionales como GIT y Subversion (no tengo una muy buena comprensión de estas herramientas), para satisfacer las necesidades de su proyecto. Si lo usan, ¿cómo configuraría algo así?

Mis aplicaciones no son tan grandes y todavía no estoy trabajando en un equipo, ¿serían de gran ayuda para mí?

Hay preguntas en este sitio sobre cómo usar las herramientas, pero necesito ayuda para principiantes.

Wolfi
fuente
55
Git y Subversion vienen con instrucciones; son básicamente un repositorio que almacena código de desarrollo de forma estructurada. Los desarrolladores individuales se benefician de tener un registro completo de los cambios en el código y una sólida instalación de respaldo. Los equipos de proyecto se benefician de la capacidad de compartir el mismo repositorio de código fuente, manteniendo los cambios sincronizados entre las estaciones de trabajo.
Robert Harvey

Respuestas:

13

El control de código fuente es omnipresente, incluso podría decirse que no puede llamarse desarrollador profesional si no lo está utilizando. Incluso cuando se desarrolla solo, el control de fuente aún ofrece bastantes beneficios. Al final, proporciona tanto una historia como una extensa ruta de deshacer. También te libera para experimentar mucho más, seguro sabiendo que si no te gusta la nueva versión, siempre puedes volver a lo que tenías antes.

Dicho esto, los flujos de trabajo, incluso dentro de un sistema de control de fuente como Subversion o Git, varían enormemente de un equipo a otro. El mejor lugar para comenzar es probablemente elegir un sistema de control de fuente y familiarizarse con sus flujos de trabajo estándar (teniendo en cuenta que tendrá que cambiar los flujos de trabajo a lo largo de su vida profesional).

Para comenzar, recomendaría Git. Soy un fanático de Git, pero más específicamente, elegir Git gets le permite comenzar trabajando sin servidor y solo configurar un servidor cuando tenga sentido para usted. Subversion, por otro lado, requiere un servidor y configurar uno, aunque no es extremadamente difícil, es desalentador cuando no está familiarizado con ese tipo de cosas.

Aquí hay una buena descripción general de algunas buenas reglas generales para el control de fuente en general: http://scottonwriting.net/sowblog/archive/2008/11/13/163320.aspx

Cuando trabaje solo, no necesita una buena cantidad de flujo de trabajo. Comprometerse temprano, comprometerse a menudo. Si comienza a implementar versiones, etiquete sus lanzamientos. Cree ramas para experimentos o trabajos largos y divergentes (Git lo hace más barato y simple que Subversion).

Miguel
fuente
1
Buena respuesta, excepto un punto. Definitivamente no elegiría el servidor que necesita subversión, ya que es su mayor inconveniente, en parte porque en realidad lo he usado sin uno con bastante frecuencia; el repositorio puede vivir en el directorio local y la configuración es un solo comando. La principal diferencia entre Git y Subversion es que los sistemas distribuidos como Git son mucho más flexibles que los centralizados como Subversion.
Jan Hudec
5

Los sistemas de control de código fuente (SVN, Git, etc.) a un nivel muy simple le permiten mantener el historial de cambios de los archivos. Esto le permite ver cómo ha cambiado su código con el tiempo y deshacer los cambios que quizás no desee (por ejemplo, el cambio no funciona como se esperaba, puede revertir el código a un estado previamente conocido). Esto es algo que incluso el desarrollo por su cuenta será invaluable para usted una vez que comience a usarlo.

Tan pronto como trabaje con otras personas en un equipo, los beneficios aumentan aún más, ya que varias personas pueden cambiar el mismo archivo y si los cambios no entran en conflicto (por ejemplo, 2 personas cambian diferentes secciones del archivo), los cambios se fusionarán automáticamente. Si hay algún conflicto, podrá ver sus cambios junto a sus colegas y discutir con ellos cómo combinarlos.

También puede crear instantáneas de la base de código (generalmente llamada etiqueta) al lanzar una versión del código para que pueda depurar fácilmente los problemas a pesar de que la fuente principal se ha movido con nuevas características que aún no se han lanzado.

Aquí hay algunos recursos útiles:

Poner en marcha Subversion y Tortoise SVN con Visual Studio y .NET

Control de versiones con Subversion

Trevor Pilley
fuente
1
No dar +1, porque aprender Subversion como primer sistema es un poco contraproducente en estos días cuando todos están cambiando a sistemas distribuidos.
Jan Hudec
3

Tutoriales para principiantes

Hay excelentes tutoriales (video y texto) que pueden ayudarlo a comenzar desde un nivel muy básico. Git parece tener un gran enfoque para presentar el tema de una manera amable para principiantes que le dice el por qué primero y utiliza la repetición, la definición y los gráficos para ayudarlo a recordar los nombres y funciones de los comandos clave.

SVN

SVN pretendía ser CVS hecho mejor. CVS (Sistema de versión concurrente) trabajó en cosas de un archivo a la vez, SVN generalmente trabajó en cosas de un directorio o árbol de directorios a la vez. SVN (y CVS u otros sistemas) pueden ser importantes si lo está usando en el trabajo, pero mi opinión es que mejoramos significativamente nuestra comprensión de lo que se necesita para hacer el control de la fuente cada pocos años, por lo que preferiría un modelo tardío computadora, debe preferir una herramienta de control de fuente de último modelo. Cambiar los sistemas es una gran inversión, y el historial de código puede perderse, aunque para muchos sistemas hay convertidores que le permiten migrar su código, así como el historial y otros artefactos creados por el sistema que se está retirando.

El control de fuente profesional cumple con las necesidades profesionales

Su pregunta "¿Cómo utilizan los profesionales herramientas como GIT y Subversion para satisfacer las necesidades de sus proyectos?" se relaciona estrechamente con la pregunta "¿Cómo trabajan juntos los equipos sin interponerse entre ellos mientras siguen trabajando lo más rápido posible?"

El código cambia con frecuencia con algunos desarrolladores que crean código que otros desarrolladores usarán, y con una variedad de partes interesadas que necesitan diferentes niveles de estabilidad frente a innovación. Los sistemas de control de origen ayudan al almacenar el código para que lo use el equipo, manteniendo cada cambio en contexto con versiones que cambian con el tiempo y, a menudo, también con ramas que son copias controladas del código que sirven para aislar grupos de cambios de otros grupos de cambios.

Volver a unir las cosas, fusionar el trabajo de muchos miembros del equipo es una tarea que en SVN y sistemas anteriores era centralizada y difícil. Para los equipos que usan Git, la fusión se vuelve más simple y más accesible a la influencia de todo el equipo en lugar de algunos expertos. En SVN, la ramificación podría ser un asunto personal, pero la fusión a menudo tuvo impactos dolorosos en el equipo y el movimiento del código de regreso a la línea principal podría ser doloroso desde la perspectiva de obtener permiso, evitar roturas y el nivel de esfuerzo necesario para la tarea. .

Desde un repositorio de control de fuente establecido, los profesionales pueden satisfacer otras necesidades como diagnosticar problemas a su causa raíz. Si hubo versiones del código que solían funcionar y problemas recientemente encontrados que ocurren en la versión actual, es posible avanzar y retroceder en el historial para señalar cuándo ocurrió el problema. En SVN, esta capacidad es inmadura, pero en Git la búsqueda de la última versión de trabajo / primera falla está respaldada por un comando llamado git bisect. El problema será causado por uno de los cambios de origen entre las dos versiones, que es potencialmente un diagnóstico mucho más fácil que una búsqueda de toda la base de código.

Perdón por divagar, espero que esto te ayude a utilizar el control de código fuente.

DesarrolladorDon
fuente
0

Mi equipo utiliza un sistema de control de versiones de equipo propio. (Lamentablemente, Git todavía no parece funcionar en los archivos fuente "nativos" de IBM i) Pero personalmente, una vez que extraje la fuente de ese sistema, uso Git durante mi desarrollo, hasta que el proyecto esté terminado y lo regrese al equipo VCS.

Como dicen en la votación ... comprometerse temprano, comprometerse a menudo. A medida que trabajo en nuevas funciones, me comprometo. Me comprometo entre las compilaciones, y en cada intento de corregir los errores del compilador, cada vez que hago cambios durante las pruebas y la depuración. Esto permite que sea más sencillo probar varias variaciones de un tema y, si es necesario, retroceder fácilmente, especialmente cuando un cambio se coordina en varios archivos.

Git ha mejorado la forma en que abordo el desarrollo.

WarrenT
fuente
'Git parece no funcionar todavía en los archivos fuente "nativos" de IBM i)' - Git debería funcionar en cualquier archivo. ¿Cuál es el problema aquí?
Marnen Laibow-Koser
@ MarnenLaibow-Koser La mayoría de los desarrolladores de IBM i están trabajando con archivos fuente con lo que podríamos llamar el sistema de archivos nativo (heredado) QSYS, donde los archivos fuente tienen un formato incorporado de longitud fija. Cada línea comienza con un número de secuencia de 6 dígitos, una fecha de cambio de 6 dígitos, luego la línea de texto del código fuente. La secuencia y la fecha de cambio pueden cambiar aunque el código fuente de una línea no haya cambiado. Las soluciones pueden haber sido desarrolladas más recientemente. IBM y otros ahora están apoyando git en IBM i. Y no debería ser un problema con la fuente en los archivos de flujo "normales" en otros sistemas de archivos IFS en IBM i.
WarrenT
Oh Dios, recuerdo vagamente eso de hacer el desarrollo AS / 400 hace 20 años. Pero no hay razón, creo, para que Git no funcione con esos archivos. Es posible que deba escribir un controlador de combinación que descuenta los números de línea, pero eso debería ser fácil de hacer. (Me pregunto si eso fue lo que hizo IBM ...)
Marnen Laibow-Koser
Pero, si quita los números de línea y la fecha de cambio de línea, entonces los ha perdido cuando revisa algo de Git. No es fácil convencer a algunas personas de que ya no necesitan esas fechas, después de confiar en ellas durante unas 3 décadas. Sí, sé que la culpa de Git ofrece lo mismo, pero las personas son reacias a renunciar a algo de lo que han dependido durante tanto tiempo, incluso si no es necesariamente un argumento lógico.
WarrenT
En realidad, podría hacer un filtro de limpieza / mancha de Git para restaurar la fecha de culpa de Git. :)
Marnen Laibow-Koser