Logo Pablo Monteserín

Pablo Monteserín

Introducción

Usos de GIT

Idealmente GIT se utiliza para hacer un seguimiento de código fuente. GIT puede utilizarse también para hacer un seguimiento de ficheros binarios (fotos, videos, etc), en estos casos, nos informará de cuál es la versión más reciente, pero no nos dirá cuáles son los cambios efectuados.

¿Qué es un repositorio de versiones?

Es un lugar donde ser almacenan diferentes versiones de un código. Para cada versión se le saca una foto a todo el código, se le pone unos metadatos*, y se guarda una referencia a la versión anterior.

*Metadatos:
- Nombre del autor.
- Email
- Fecha
- Commit anterior.
- Mensaje

Conceptos

Working directory: Carpeta de trabajo.

Git directory: Es la carpeta oculta .git dónde se guardan todas las fotos que se han ido haciendo de nuestro código.

Staging area: Contiene los cambios desde la última foto sacada.

Instalación de GIT

Instalación en windows:
Página oficial de GIT: http://git-scm.com/

Instalación en Linux:
sudo apt-get install git-core

Git hosting

git hosting

Github: Es el primero de los repositorios de Git que apareció y por ello el más popular con diferencia. Gratis para proyectos de Open Source, cualquier proyecto que se precie con código abierto está en Github.

Bitbucket: tiene la posibilidad de hacer repositorios privados gratuitos, aunque con la limitación de estar disponible solo para 5 usuarios.

Gitorious: repositorios gratuitos para proyectos Open Source.

Ejercicio

  1. El administrador crea un proyecto en github.
  2. Los demás usuarios ejecutan en una carpeta que deben crear en su ordenador: 
    El usuario inicializa el repositoriogit init

    origin suele ser el nombre que tiene en el ordenador del usuario el repositorio online

  3. Vincular nuestra cuenta al servidor

    4. git remote add origin url-del-repositorio

  4. Descargar a nuestro ordenador lo que hay online

    git pull origin master
    git fetch --all
git reset --hard origin/master

  5. Subida

    6. Vamos a subir la rama al origin

    Metemos la info en un sobregit add .
    Escribimos en el sobre la información de lo que hay dentrogit commit -m "rama stagging creada"
    Enviamos el sobregit push origin stagging

  6. Ramas

    El administrador crea la rama de stagging

    Crear rama de stagginggit branch stagging
    Ver las ramas creadasgit branch
    Vamos a la rama (necesario par apoder subirla)git checkout stagging
    Borrar una ramagit branch -d [branch]

    Al cambiar de rama se pierden todos los cambios no commiteados.Si estuve desarrollando en una rama, y realmente quería commitear otra, para no perder los cambios debería meterlos en el stash.

    7. Acceder a los diferentes commits de mi aplicación

    acceso commits 
    Subir lo que hay en local, sobreescribiendo lo que hay en el servidor (no hace falta hacer un pull):git push origin master -f

  7. Invitar usuarios

    El administrador debe autorizar al resto de usuarios a acceder a su repositorio. En la página del repositorio → settings → Options → Collaboratos -> le ponemos el nombre de usuario de github

  8. Alumno *: Sube el texto "Alumno *" a stagging machacando lo que hay.
  9. Alumno *: Añade el texto "Alumno *" a stagging lo que ya había.
  10. Alumno *: Cambia su número de alumno por la letra correspondiente.

  11. Unificar ramas

    Hacemos un pull request desde nuestra cuenta de github

Configuración Git

Creación de usuario:git config --global user.name gitpablo
git config --global user.name pablomonteserin@pablomonteserin.com
Ver configuración:git config –list
Cambiar editor por defecto:// El comando git commit -a no me funcionó con el sublime-text; dejar el vi 
git config --global core.editor sublime-text
Ver colores en el editor:git config --global color.ui true

.gitignore

El fichero estará en la raíz del proyecto

.gitignore# Compiled source #
###################
*.class
*.dll

# folders
###################
log # esto no me incluirá ni el fichero log ni la carpeta log

# OS generated files #
######################
.DS_Store
.DS_Store?
._*
.Spotlight-V100
.Trashes
Icon?
ehthumbs.db
Thumbs.db

.gitignore a nivel de usuario del equipo

Para saber dónde está el gitignore a nivel de usuario en mi equipo:

git config core.excludesfile

Me permite indicar dónde está el fichero que contiene los nombres de los ficheros que ignoraré a nivel de usuario. Dicho fichero debe existir previamente. 

git config --global core.excludesfile /home/monty

http://www.gitignore.io/

Introduciendo una plataforma de desarrollo, una tecnología, etc. me devuelve el código de un fichero .gitignore que ignorará los ficheros oportunos.

Hacer un merge entre ficheros que son diferentes

Cuando haces un pull y hay un conflicto de versiones, los ficheros que te descargas tienen anotaciones en su interior indicando lo que se debe corregir. Habrá que modificar estos ficheros para dejarlos correctos y luego hacer un comint y un push

Ramas en git eye

Pestaña Git Repositories → Branch → Local →

Cambiar de Rama:
Doble click sobre la rama a la que quiero cambiar.

Borrar Rama:
Botón derecho → Delete Branch

Para ver todas las ramas:
En la pestaña History, pulsar en "Show all branches and tag".

git reset

Lleva la rama activa a un estado previo

hard: al ir al estado previo se pierden todos los cambios no commiteados. También desaparecen del grafo todos los hijos del commit al que voy. Esto es así porque los commit almacenan el commit hijo, pero no el commit padre. Para visualizar los commit que faltan tendría que mover el punto de entrada al hijo deseado. Si pasase el recolector de basura perdería los commit que no estoy viendo, más o menos al cabo de dos semanas.

Para volver a un punto del grafo que ha desaparecido

Necesito una referencia al punto al que quiero ir. Para ello necesito un tag o un branch. Si tras hacer un git reflog decido que quiero ir a cierto punto (93948fd), podré ejecutar:

  1. git tag [nombre del tag] 93948fd
  2. git branch [nombre del branch] 93948fd (si lo que quiero es continuar trabajando a partir de este punto).

Es un puntero especial que apunta a la rama activa.

Sólo puede apuntar a ramas y estas deben ser locales. No puede apuntar a ramas remotas ni tags. De lo contrario tendré un detached head.

Si no indicamos nada, al ejercutar git reflog nos muestra todos los movimientos de HEAD.

Los reflog son inherentes a la máquina dónde estás trabajando.

Borrar una rama remota

Primero borro la etiqueta y luego la rama:

#Borro la etiqueta
git branch -d -r origin/devel

#Borro la rama
git push origin:devel

Trabajo con forks

El botón de fork de un proyecto me lo lleva a mi cuenta de github. Luego puedo hacer clone del proyecto para manipularlo en mi equipo.

git clone https://github.com/monteserin/destinyway.git

.. hago cambios en el repo que he clonado

En github me aparece el botón “Pull Request” que me permite solicitar el envío al repositorio principal.

Después de que el integrador integre los cambios las personas que lo han enviado no los verán en sus repositorios forkeados. Tendrán que volver a cojerlos.

Reglas del juego

Juego 1

Las reglas del juego son: “Cada persona hace sus cambios y hay una o varias personas que se dedican a integrar el código enviado. Si no da conflictos, estupendo, en caso contrario, habría que corregirlos”. Ventajas: Las personas que envían su código no tienen que tener grandes conocimientos de git. Simplemente hacen envíos. Desventajas: Las personas que integran asumen responsabilidades de todo el equipo y deben comprender en cierta medida el código de las personas que envían.

Juego 2

Todos los desarrolladores se comunican entre ellos para hacer los merges. Todos los integrantes del equipo pueden hacer el pull request.

  1. Cada desarrollador forkea el proyecto principal y se crea una rama propia dentro de su fork.
  2. Hace un push para subir sus cambios al repositorio remoto.
  3. Recupero los cambios de otro desarrollador. Para esto, tengo dos opciones:
    • Le pido la url del repo a la persona que tiene los cambios que quiero cojer
    • Se va al proyecto original github → network → Selecciono al otro usuario →
  4. Añador mi repo al mío: 
    
git remote add fernandorepo https://github.com/scoxove/prmanual.git
  5. Mergeo mis cambios con la rama del repo añadido para tener los cambios hechos por otro desarrollador.
  6. Hago un pull request al proyecto original del que comenzaron todos los forks.

Juego 3 - lugartenientes

Todos los desarrolladores se comunican entre ellos para hacer los merges. Sin embargo, no todos pueden hacer los pull request, sino que existen jerarquías para decidir quien las hace.

Así es como se gestiona el núcleo de linux.

Error típico cuando tenemos un repositorio de git dentro de un repositorio de git

No submodule mapping found in .gitmodules for path

Para solucionarlo editamos el fichero .gitmodules, en la raíz del proyecto.

Si estamos configurando git contra un repositorio ftp haremos algo parecido a esto:

[submodule "cosines"]
	path = cosines/monteserinGallery
	url = ./cosines/monteserinGallery

git-ftp

Curso de GIT

¿Quién Soy? | Blog
Facebook | YouTube | LinkedIn
Testimonios
icono de mandar un mailPreguntame lo que quieras!
Pablo Monteserín
contacta conmigoPablo Monteserín

El servicio de resolución de dudas técnicas es sólo para los usuarios premium. Si tienes cualquier otra duda, usa el formulario de contacto. ¡Gracias!