By Jason Long - http://git-scm.com/downloads/logos, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=19329352

Iniciación a GIT

Introducción

Si en el desarrollo de tus proyectos empiezas a ver cosas como esta.

Es buen momento para poner en tu vida profesional un sistema de gestión de versiones.

Si también el equipo donde te encuentras trabajando se va ampliando y tenéis que trabajar en la misma aplicación varias personas. Recuerda, gestión de versiones.

La herramienta que te proponemos para el control de versiones es, git.

Instalación

Lo primero es instalar el software, la instalación es muy sencilla.

Vamos a hacer un ejemplo, pensando que estamos trabajando en un ordenador con Ubuntu .

$ apt-get install git

En la página oficial tienes puedes ver como se instala en diferentes sistema operativos.

https://git-scm.com/downloads

Configuración del Usuarios

Cuando ya está instalado tenemos que configurar unas variables globales, para poder empezar a trabajar. En este caso vamos a configurar:

  • $ git config –global user.name “Marcos”
  • $ git config –global user.email “marcos@domain.com”
  • $ git config –global color.ui auto

Estados del git

Antes de continuar tenemos que tener en cuenta que git puede estar en unos estados de preparación diferentes.

Nuestro repositorio, puede estar en estos estados distintos.

  1. Working directory
    1. Directorio del proyecto donde están todos los ficheros.
  2. Staging area (Index)
    1. Área de preparación. Los archivos están listos para ser guardados en el repositorio.
  3. Local repository (History)
    1. Almacena permanentemente los archivos tal y como están en el Staging area, pero en local.
    2. Para conocer el commit que estamos ahora se etiqueta como ‘head’
  4. Remote repository (origin)
    1. Almacenamiento permanente de los archivos del repositorio local en un repositorio distribuido servidor.
    2. Para saber el último commit en el servidor se etiqueta como ‘origin’

Iniciando un repositorio nuevo

Para crear un nuevo repositorio, lo que tenemos que hacer primero es crear el directorio donde queremos que esté el código.

    $mkdir web

Después accederemos dentro de la carpeta creada.

    $ cd web

Ahora que ya estamos donde queremos que esté nuestro código creamos el repositorio con el comando. Para este caso, si la carpeta está vacía, mejor.

    $ git init

Si realizamos un

    $ ls -la

Podremos observar que se a creado un fichero oculto llamado “.git” . Cuidado con borrar este directorio, porque es donde se almacena toda la información de repositorio

Para ver cómo está el estado de nuestro repositorio, podemos utilizar

$ git status

Trabajar en el repositorio local

git add

Ahora ya podemos empezar a trabajar en el repositorio. Nos situamos en el directorio que hemos creado. Para empezar a desarrollar nuestra web, vamos a empezar por algo sencillo.

    $ touch index.html

    $ git status

El documento que hemos creado está en el área: Working directory

Como hemos creado un fichero nuevo, le tenemos que decir a git que sea sabedor de que ese nuevo fichero lo tiene que preparar para el siguiente estado. Añadirà el archivo al Staging area

    $ git add index.html

$ git status

Si queremos añadir mucho ficheros, la mejor opción es.

    $ git add .

Podemos continuar trabajando e ir preparando todos los ficheros que queramos al Staging area .

git commit

Cuando ya tenemos un conjunto de cambios realizado, o ideal es hacer un commit. Este commit tendría que poder ser una desarrollo pequeño que nos interese a lo mejor volver en un momento determinado. Pensar que puede ser como un punto de retorno a nuestro código.

    $ git commit -m “Hemos creado el contenido del índice”

    $ git status

Al final lo que obtenemos son puntos que podemos volver a ellos en un momento concreto. Es una especie de historial de la evolución de nuestro desarrollo.

Este sería la imagen que nos quedaría después de realizar 4 commits.

En esta imagen aparece un nuevo concepto Rama (Branch) En el siguiente punto lo veremos.

En el 1º commit es el inicial.

En el 2º commit, tenemos el código del 1º commit más el del 2º commit.

En el 3º commit, tenemos el código del 1º commit más el del 2 y el del 3º.

En el 4º commit, es la suma de todos los anteriores.

Por eso la flecha apunta al círculo de dónde ha evolucionado el código.

git log

Para ver nuestro historial de commits podemos utilizar

    $git log

git branch

Imaginemos que necesitamos probar una librería nueva, pero no queremos que el código que ya tenemos, por probar una nueva funcionalidad se ensucie.

No queremos tener commits que no nos sirven, o que al final no estarán integrados en el código. Para eso tenemos la opción de crear ramas. Esto nos permiten aplicar diferentes versiones/estados al proyecto.

$ git branch develop

Al crear esta nueva rama, nosotros directamente apuntamos a ella, esto nos lo indica el HEAD. El head es un puntero, referencia a la rama actual.

Todo lo que modifiquemos estando dentro de esta rama se queda aquí. No se mezclará lo que tenemos en la rama master. Hasta que nosotros lo realizamos o lo desechemos.

Un apunte.El nombre de las ramas, master y develop, no es por casualidad. Tenemos que identificar cada rama para su función. En la rama master tiene que contener el código de producción. Lo que esté en esa rama tiene que ir directamente a producción. Por lo tanto en la rama develop es donde realizaremos los desarrollos. Para luego unir a master si es correcto lo que hemos realizado.

git branch -d nombre

Para eliminar una rama solo tenemos que hacer

    $ git branch -d develop

git checkout branch

Cuando queremos volver a una rama ya creada lo que tenemos que hacer es.

    $ git checkout develop

git merge branch

Con este comando lo que podemos hacer es fusionar ramas. Ahora que la librería que queríamos probar en la rama develop, nos ha funcionado a la maravilla. Es el momento de unificar las ramas creadas. Para que el código de desarrollo pase a producción.

Tenemos la rama master y develop. Lo que queremos en fusionar la rama develop en la rama master.

Primero estamos en develop porque hemos terminado de probar la nueva librería.

Tenemos que apuntar a master, porque es la rama de producción la queremos integrar con el código de desarrollo, rama  develop.

    $ git checkout master

    $ git merge develop

.gitignore

Es un documento donde especificamos los archivos o directorios que no deseamos añadir a git.

Por ejemplo las carpetas de configuración de nuestro IDE. Es muy importante no subir configuraciones del IDE o de datos en producción al repositorio. Nunca poner un fichero con la contraseña de la base de datos en producción.

Trabajar en el repositorio remoto

Ahora que sabemos trabajar en nuestro repositorio en local, tenemos que aprender a utilizar el repositorio en remoto.

GitHub

La empresa https://github.com/ nos ofrece repositorios públicos gratuitos.

Darse de alta en esta plataforma es muy sencillo. No hace falta que lo expliquemos.

Tenemos que tener en cuenta que Git no es lo mismos de GitHub.

  • Git es la tecnología para trabajar con repositorios
  • GitHub es una plataforma para alojar proyectos

Dato curioso, nació en 2008 y en 2018 fué adquirida por Microsoft en 2018 por 7.500 millones de $.

git remote

Podemos listar los repositorios remotos añadidos a nuestro repositorio local.

$ git remote

git remote add nombre url

Para añadir un repositorio tenemos que hacer lo siguiente. Este paso es para vincular un repositorio local que no tiene repositorio remoto. Antes de realizar este comando tenemos que crear un repositorio en nuestro github.

$ git remote add origin https://github.com/user/repo.git

Cuando añadimos un repositorio remoto , también existen ramas en ese repositorio, pero tienen la peculiaridad que se llaman igual que las ramas locales pero con el prefijo origin

  • master -> origin/master
  • develop -> origin/develop

git clone

Si no tenemos ningún repositorio local pero queremos empezar a trabajar en un repositorio remoto. La mejor opción en copiar el repositorio remoto para tenerlo en local.

$ git clone https://github.com/marcware/skeleton-kata-docker-php.git

git pull

Descarga los cambios del repositorio remoto al local. Si estamos en la rama develop, descargamos el origin/develop del servidor.

$ git pull

git push

Si hemos descargado el repositorio remoto al local. También podemos subir los cambio del repositorio local al repositorio remoto. Subimos los ficheros al repositorio desde la rama que estemos en esos momentos.

$ git push

Apunte final

Con esta guía tenemos una pequeña chuleta para recordar los comandos y acciones básicas que se realizan.

Para continuar trabajando con git, es interesante conocer git-flow. Al igual que algún tipo de de servicio de integración continua como https://jenkins.io/

Bibliografía

https://git-scm.com/book/es/v1/Empezando

http://marklodato.github.io/visual-git-guide/index-es.html


Sollutia

En Sollutia somos especialistas en el diseño de páginas web, alojamiento, comercio electrónico, Tours Virtuales 360º y todo tipo de soluciones en internet. En Sollutia som especialistes en el disseny de pàgines web, allotjament, comerç electrònic, Tours Virtuals 360º i tot tipus de solucions en internet.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Utilizamos cookies propias y de terceros para mejorar nuestros servicios y mostrarle publicidad relacionada con sus preferencias mediante el análisis de sus hábitos de navegación. Si continúa navegando, consideramos que acepta su uso. Puede cambiar la configuración u obtener más información.

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar