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

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.

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

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

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.

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.