El 14 de septiembre de 2017, publicamos una versión revisada de nuestra Política de privacidad. Tu uso continuado de video2brain.com significa que aceptas este documento revisado, por lo que te recomendamos que dediques unos minutos a leerlo y comprenderlo.

GitLab esencial

Repositorios: commits y branches

Prueba ahora LinkedIn Learning sin cargo y sin compromiso.

Prueba gratis Mostrar modalidades de suscripción
El flujo de trabajo en GitLab (o git) es algo diferente que en los sistemas de control de cambios lineales de otros softwares, como en las suites ofimáticas o en los programas de diseño gráfico. Veremos qué significan palabras como commit o branch, que tantas veces vamos a oír, y de qué manera podemos controlar las versiones.

Transcripción

Repositorios: commits y branches. Si vais a trabajar con Git y con GitLab, es muy importante que os familiaricéis un poco con su nomenclatura y con su funcionamiento interno. Git, que es en lo que está basado GitLab, tiene un funcionamiento que está basado en lo que se llama snapshots, es decir, son como imágenes que se toman de cada uno de los ficheros con los que estáis trabajando, solamente cuando se producen cambios. En una línea temporal, en la que vemos aquí versión 1, que sería la versión de base, versión 2, 3, 4, 5, vemos que solo algunos de los ficheros están rodeados por una línea fija. Algunos están rodeados por una línea de puntos. Los que están por una línea fija son en los que se han producido cambios y son los únicos que se almacenan. Del resto no se almacena nada, ya que, por ejemplo, en el fichero A, entre la versión 2 y la versión 3 no hay ningún cambio y no tenemos por qué almacenar nada más. Solo estamos almacenando la versión A1 y la A2, que son los dos únicos cambios que hay. O, por ejemplo, en el fichero B, no guardamos ningún cambio, más bien un snapshot, hasta la B1 o la B2, que es en la versión 4, en la versión 5. No es, aunque parezca similar, igual que en otros sistemas de control de versiones, ya que otros, como CVS, lo que hacen es guardar deltas, es decir, solo almacenan la diferencia que hay entre un fichero y otro durante sus cambios. Las ramas y la historia digamos que es un poco el aspecto general que puede tener un repositorio de Git. Aquí vemos una cosa muy sencilla, que vienen a ser tres cambios, tres commits, que se podrían llamar, 98ca9, que sería el primero, que corresponde a un snapshot, 34ac2, que corresponde a otro, f30ab, que corresponde a otro, y que a su vez corresponden a un par de ramas, a la versión 1.0 y a la master. Esto de las ramas digamos que es una manera de tener múltiples repositorios en un mismo repositorio. No es exactamente eso, pero al principio es un poco para hacerse a la idea. Digamos que es que de un mismo repositorio se pueden hacer versiones un poquito diferentes, quizá para un cliente, quizá para arreglar un error, etcétera, etcétera. Digamos que la manera de crear una nueva rama es más o menos sencilla. Nosotros partimos de un repositorio con tres cambios. El inicial sería este, este el segundo, este el tercero, y, cuando nosotros creamos un repositorio, solo existe una rama principal, que sería la rama master. Esta es en la que, cuando trabajamos con Git, siempre se comienza automáticamente, es la rama por defecto. Si nosotros queremos hacer una rama de pruebas, crearíamos, con el comando de Git, la rama llamada testing. Cuando nosotros creamos una rama nueva, se crea a imagen y semejanza, exactamente igual, que la rama que estamos duplicando. En este momento, testing sería exactamente igual que master, ya que lo acabamos de crear, y, de hecho, al ser exactamente iguales, testing apunta al mismo snapshot que al que está apuntando master, f30ab. Luego, Git tiene que saber en qué rama estamos trabajando, Para saber en qué rama trabajamos, se utiliza un puntero que se llama HEAD. HEAD es un puntero que nos marca cuál es la rama en la que estamos activos. Por defecto, el HEAD estará apuntando a master, pero si cambiamos de repositorio, este puntero apuntará a testing y, por lo tanto, Git siempre sabrá en qué rama estamos trabajando. Digamos que nosotros, en este momento, en testing, que queremos hacer unas pruebas, realizamos un cambio. Si realizamos un cambio, no estamos apuntando ya al mismo snapshot. Tenemos un snapshot diferente, y digamos que testing ha avanzado en el tiempo, master sigue apuntando al snapshot f30ab, mientras que testing, por decirlo de alguna manera, está en el futuro, está un poco más adelante, y está en el 87ab2. Entre los dos hay una pequeña diferencia, bueno, quizá un poco más grande, pero digamos que la diferencia es tangible porque es solamente la diferencia entre un snapshot y el otro, y como estamos trabajando en testing, el HEAD está apuntando a testing todavía. Ahora digamos que queremos seguir trabajando en master, mientras tenemos esta pequeña diferencia. Lo que haríamos sería una tarea que se llama checkout. Checkout es esa tarea en la que se cambia el HEAD de sitio. Ese sería su nombre. Si yo hago un checkout a master, cambia el puntero HEAD a este snapshot y digamos que nosotros hacemos ahora un cambio. Vamos a realizar un cambio en master que no es el mismo que hemos hecho en testing. Por lo tanto, de repente, lo que pasa es un poco como en estas películas de viajes en el tiempo, y es que se crea un presente alternativo. De repente nuestro repositorio se divide en dos y las ramas están completamente separadas. Esto hace que las dos, iba a decir, estén en el futuro, que no es exactamente eso, pero que de repente hayan empezado a divergir y vayan separándose cada vez más y diferenciándose un repositorio del otro. Por esto es por lo que se llaman ramas, porque tienen estos dibujos que van realizando que son como las ramas de un árbol. En la práctica, esto es de la siguiente manera. Tenemos un repositorio con tres cambios, C0, C1, C2, con un par de ramas, que son master y, en este caso, una, que debe de ser una incidencia, que se llama issue 53. Cuando en issue se realiza un cambio, avanza hacia el futuro, por decirlo de alguna manera, y estamos más adelantados que master. Normalmente, si hacemos una petición de estado del repositorio nos diría que estamos equis commits más adelantados al master. De repente, en master descubrimos un fallo. Resulta que hay algún tipo de bug o tenemos un problema de seguridad o lo que fuera, y entonces volvemos a crear una rama más, que es una rama aparte en la que vamos a trabajar sobre este fallo y vamos a intentar arreglarlo. Como veis, ya tenemos tres ramas. Cada una está en un punto. hotfix está un poco más hacia delante que master, issue está un poco más adelante que master pero ninguna de las tres tiene la misma información. Cuando conseguimos arreglar este problema, lo que hacemos es fusionar, se hace lo que es un merge, la rama C2 master con C4 hotfix. master y hotfix terminan apuntando al mismo snapshot y ya hemos, digamos, fusionado estas dos ramas. A partir de este momento, si verificamos que la solución es adecuada, la rama hotfix ya no nos hace falta para nada, porque es exactamente igual que master y ha cumplido su función y la borraríamos. Esto es un flujo de trabajo que hay que aprender. Hay que tener un poco de práctica con él, ya que es el día a día de la agregación de características a nuestro software. Se realiza en un proceso que se llama merge request que viene a ser como una petición de merge que se suele hacer desde un desarrollador hasta el administrador, y la aceptación de estos merges. Hay que estar un poco familiarizado con ello y aprender un poco a lidiar con los problemas de código que pueden aparecer.

GitLab esencial

Aprende a instalar y administrar GitLab, bien en tu propio servidor o en un servicio web gratuito o de pago, y cómo crear un perfil y generar tu primer proyecto en GitLab.

3:14 horas (47 Videos)
Actualmente no hay comentarios.
 
Fecha de publicación:27/10/2016

Este curso video2brain está disponible como descarga y para ser visualizado online. ¡Pero no hace falta que decidas entre las dos opciones! Al comprar el curso, disfrutarás de ambas posibilidades.

La descarga te permite ver las lecciones sin estar conectado/a a internet y supone una navegación fácil y ágil entre capítulo y capítulo. Si vas a trabajar en diferentes ordenadores o si no quieres descargarte el curso completo, entra en la web con tus datos de acceso y disfruta directamente de tus vídeos online. Te deseamos que disfrutes de este curso y te resulte de mucha utilidad.

Estamos a tu disposición si tienes cualquier tipo de duda o pregunta.