sábado, 12 de abril de 2014

Controlador de versiones GitHub



Es casi inconcebible hoy en día trabajar desarrollando software y no utilizar un sistema de control de versiones, pero primero debemos definir cómo funciona.
Lo habitual es que cada programador realice los cambios necesarios en el código fuente para la tarea que se le ha encomendado. Una vez que dichos cambios están listos, los envía al servidor (o a los otros participantes), de modo que el resto pueda recibirlos en cualquier momento, y así trabajar sobre dichos cambios cuando tengan que realizar cualquier otra tarea. Se puede dar el caso de que varios programadores trabajen sobre el mismo fichero o ficheros, en cuyo caso el sistema lo detectará, y actuará para evitar posibles conflictos. Se pueden dar dos casos:
  • Los programadores han trabajado en porciones de código diferentes: En principio, no se han pisado las líneas en las que han trabajado, así que es probable que sea suficiente efectuar ambos cambios sobre el fichero, sin más. Casi todos los sistemas de control de versiones detectan esta situación y realiza la unión de los cambios de forma automática, notificándolo al usuario para que tenga constancia.
  • Los programadores han trabajado en líneas de código comunes, modificando, eliminando o añadiendo líneas en la misma porción de código: En estos casos, el sistema suele señalar que hay un conflicto entre ambos cambios, y habitualmente genera un fichero intermedio convenientemente marcado para que se puedan revisar ambos cambios de forma simultánea, y así quedarse con uno, con el otro, o con una combinación de los dos, realizando la unión a mano y eliminando lo que sobra.
Algunas de sus ventajas son:
  • Puedes volver a cualquier punto del desarrollo para ver qué aspecto tenía un determinado fichero de código, o volver a una versión donde todo funcionaba antes de haber metido la pata.
  • Puedes trabajar en distintas características de forma simultánea, guardando los cambios en cada una de ellas, y uniéndolos al desarrollo principal si ya han sido lo suficientemente probadas. O sencillamente puedes crear una nueva versión para probar un experimento, o corregir un bug que se acaba de detectar en producción, sin comprometer lo que ya llevas realizado. Estas distintas ramas de trabajo hacen que veamos el repositorio de código como un árbol, donde cada una de las ramas representan experimentos que se van creando, y que luego vuelven a unirse al tronco principal del árbol (la versión que pretende llevarse a producción).
  • Puedes echar un vistazo para ver quién realizó un determinado cambio, y cuándo lo hizo.
Entre los más conocidos se encuentran:
  • GitHub, el cual permite alojar proyectos de software libre de forma gratuita, y proyectos privados mediante una cuenta de pago. El coste depende del número de repositorios y de colaboradores, y va desde 7 dólares al mes hasta los 200 dólares al mes.
  • SourceForge
  • Launchpad


octocatGit es uno de los sistemas gratuitos de control de versiones más populares entre los desarrolladores. Y parte culpa de su popularidad la tiene GitHub, un excelente servicio de alojamiento de repositorios de software con este sistema, que lejos de quedarse en esta funcionalidad, ofrece hoy en día un conjunto de características muy útiles para el trabajo en equipo.
Además de servir para alojar código, posee un visor de código mediante el cual se pueden hacer consultas de algún fichero, con sintaxis correspondiente al lenguaje en que esté escrito. Gracias a esto se pueden hacer consultas o copias de partes del código sin necesidad de bajar el repositorio completamente. También se puede navegar por todas las versiones del mismo y ver el contenido previo a los cambios.
Algunas de sus características (que son de gran ayuda para el trabajo en quipo) son:
  • Un wiki (sitio web cuyas páginas pueden ser editadas por múltiples voluntarios a través del navegador web) que opera para el mantenimiento de las versiones de los proyectos
  • Un sistema de seguimiento de problemas que permite al equipo abrir un problema del software o enviar sugerencias para dicho problema.
  • ·Una herramienta de revisión de código, donde se pueden añadir notas en cualquier punto de un fichero.
  • Un visor de ramas para comparar los progresos hechos en el repositorio.

Bibliografía

Genbetadev. (29 de Marzo de 2009). Genbetadev. Recuperado el 12 de Abril de 2014, de http://www.genbetadev.com/sistemas-de-control-de-versiones/kit-basico-de-herramientas-para-desarrollar-en-equipo-i-control-de-versiones

Genbetadev. (25 de Mayo de 2011). Genbetadev. Recuperado el 12 de Abril de 2014, de http://www.genbetadev.com/sistemas-de-control-de-versiones/conociendo-github-el-servicio-donde-alojar-tus-repositorios-git-como-el-nuestro

Github. (s.f.). Github. Recuperado el 12 de Abril de 2014, de https://github.com/

No hay comentarios:

Publicar un comentario