![Instalación de RHEL 6.10 con capturas de pantalla](/f/a6fe4d1330e84486c5c89fb6d7ad8199.png?width=100&height=100)
¡Demos la bienvenida a Manish Sinha al equipo de redacción! Manish es una persona muy inteligente, con experiencia trabajando en todo, desde Zeitgeist hasta Elementary.
¡Hola, Dios mío! Ubuntu! lectores, esta es mi primera publicación. Sobre todo escribiré sobre temas técnicos como editoriales.
Mi objetivo es explicar temas técnicos difíciles de una manera sencilla que sería útil para los aspirantes. contribuyentes que han encontrado que contribuir es demasiado difícil debido a la empinada curva de aprendizaje asociada con ciertas herramientas.
La colaboración es probablemente la tarea más difícil y que requiere más tiempo cuando se trabaja en equipo. Cuando escuchó por primera vez la frase "control de versiones", es posible que haya comenzado a pensar en el código y los programadores. El tema de la colaboración no es solo con los programadores, sino también con otras áreas y profesiones, es decir, con el diseño, la documentación, etc. El control de versiones como herramienta ha sido inmensamente famoso dentro de los círculos de programación, pero su uso no se limita solo al código fuente.
Cuando trabajas en equipo en lo mismo (como un diseño similar o un conjunto de archivos de documentación), el mayor problema podría ser asegurarse de que cada persona tenga el último trabajo. Cuando todos los colaboradores trabajan juntos, realizan cambios en cada parte, y luego los cambios deben compartirse.
Una solución es enviarse los cambios por correo electrónico solo para abrir su buzón y perderse entre las fotos de lolcat o reddit. Las posibilidades de omitir algunos de ellos también son altas, ya que podría terminar recibiendo demasiados correos electrónicos. Si usted y otro chico cambian el mismo archivo, entonces eliminar sus cambios e incorporarlos al suyo puede ser una pesadilla.
Otra solución es enviar todos los cambios a una persona, quien se encargará de fusionar varios archivos y mantenerlos actualizados. Se trata de una persona dedicada a este trabajo. ¡Que perdida de tiempo!
Otro problema que puede enfrentar es que en algún momento descubra que la situación actual de su diseño o documentación no es tan buena y la que tenía hace 4 días se veía mejor. ¿Qué vas a hacer?
Mire los archivos que alguien le envió hace 4 días. Busque esos archivos en su buzón, una todas las partes y es posible que aún no esté seguro de tener el conjunto de archivos correcto.
¿Qué tal si alguien te pregunta: "Cuánto trabajo hicieron ustedes en el último mes"? Puede haber momentos en los que quieras presumir de cuánto trabajo hicieron como equipo, o si estás trabajando como contratista o empleado, es útil tener un registro de trabajo.
Los principales problemas destacados anteriormente son:
Aquí es donde entran en escena los sistemas de control de versiones (VCS). Estoy evitando el término "sistema de control de fuente", ya que suena como si estuviera destinado solo para el código fuente. VCS resuelve de manera brillante los dos problemas mencionados anteriormente.
En pocas palabras, la mayor parte del VCS consta de dos partes. Un servidor central que es utilizado por todos los miembros del equipo como un área común donde ponen su trabajo y también de allí recogen el trabajo de otras personas. Es un intento de sincronizarse con los demás.
La segunda parte, la herramienta cliente del sistema de control de versiones, le ayuda a enviar su trabajo al servidor y extraer el trabajo de otros del servidor.
Si es una persona que acaba de unirse al equipo, es posible que desee recuperar todos los archivos. En este caso, creará un clon del conjunto de archivos.
Proporcionas la URL del servidor a tu cliente VCS y éste buscará todos los archivos por ti. Entonces puedes empezar a trabajar en esos archivos.
Después de trabajar un poco en los archivos (corregir errores, agregar nuevas funciones, etc.), decide que este trabajo es suficiente por ahora y desea compartir estos cambios con otras personas.
El cliente VCS rastrea todos los archivos. Puede pedirle que muestre qué archivos ha cambiado y qué ha cambiado en esos archivos.
Después de comprobar que los cambios están bien, debe confirmarlos. Un compromiso no es más que un punto de guardado o un hito. Puede tener muchos puntos de guardado en una base de código.
Incluso puede encontrar los cambios que realizó entre la 3ª y 4ª confirmación o la 23ª y 25ª confirmación. Esto se debe a que su VCS conoce la situación actual de los archivos y también sabe qué contenido estaba presente cuando realizó la 23ª confirmación y qué contenido estaba presente cuando realizó la 26ª confirmación.
En la captura de pantalla a continuación, mostramos los cambios realizados entre las confirmaciones n. ° 1714 y 1716:
Después de realizar la confirmación, su VCS le dirá que no hay cambios pendientes.
Esto sucede porque ha confirmado todos los cambios pendientes. En este caso, debe enviar sus cambios al servidor. Esto se hace enviando sus cambios a la URL remota desde donde hizo una copia de los archivos.
Después de presionar, es posible que le interese saber si alguien más impulsó su trabajo mientras realizaba los cambios y los confirmaba. Esto se hace pidiendo a su cliente VCS que extraiga los cambios del servidor remoto.
Puede intentar tirar nuevamente después de un tiempo si llega a saber que alguien más en el equipo también ha impulsado sus cambios. Por lo general, es una buena práctica realizar los cambios antes de comenzar a trabajar en los archivos. Es posible que esto no sea necesario en todos los escenarios, pero siempre tendrá los últimos cambios, lo que generalmente es mejor.
En la captura de pantalla a continuación, trato de extraer los cambios y se me notificó que no hay más cambios.
Esto fue solo una introducción a lo que realmente es un sistema de control de versiones.
El que usé en las instantáneas es bazar (también conocido como. bzr) que se usa en Launchpad y en algunos otros lugares (por ejemplo, GNU Savannah).
Los otros en la categoría de VCS son Subversion, Git, Mercurial, etc.
Hay dos tipos de control de versiones: centralizado y distribuido. Bazaar es un ejemplo de sistema de control de versiones distribuido: DVCS. Git y mercurial también caen en esta categoría, mientras que Subversion (svn) es un VCS centralizado.
Este artículo fue dirigido a personas que siempre temieron usar cualquier tipo de sistema de control de versiones, por lo que si comienza a ser quisquilloso, ¡habrá muchos errores! Los artículos futuros serán muy precisos y utilizarán términos reales.
En partes futuras debe esperar:
.. y muchos más.
¡Gracias!
Todo Ubuntu, Diariamente. Desde el 2009.