GIT

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

Herramientas visuales

Para linux, windows y mac:
SmartGit → http://www.syntevo.com/smartgithg/

Para windows y mac:
SourceTree → http://www.sourcetreeapp.com/

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

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.

Configurar contra github

Podemos hacerlo de dos formas:

Añadir un directorio contra el que voy a realizar las sincronizaciones
(esto es el origin, no el remote)git remote add origin https://github.com/monteserin/cursogit.git 

Descargar el repositorio de github a local.
Cuando hagamos subidas, se harán automáticamente a ese repositoriogit clone https://github.com/monteserin/cursogit.git 

Hacer una subida

git add .

git commit -m "primera subida"

git push origin master

github

Invitar/compartir/share con gente para poder modificar mi repositorio

en la página del repositorio → settings → Options → Collaboratos -> le ponemos el nombre de usuario de github

Acceder a los diferentes commits de mi aplicación

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.

Configuración

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

Ver colores en el editor:

git config --global merge.tool kdiff3 #La mejor de las que he probado

git config remote.origin.url gitpablo@pablomonteserin.com:/var/www/pablo

Añadir cambios a la foto (add) y sacarla

Añadir los cambios hechos en todos lo ficheros:

git add .

Añadir los cambios a la foto cuando entre esos se encuentre el borrado de un fichero.

git add -A

Añadir los cambios hechos en un fichero concreto

git add fichero.txt

Sacar la foto de los cambios añadidos:

git commit -m "menu revisado"

.gitignore

.gitignore example

El fichero estará en la raíz del proyecto

# 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 commint y un push

Uso de kdiff3

1. Merge → Choose C Everywhere
2. Salvamos (ctrl + s )
3. Exit

Traer la info y la configuración de un repositorio (carpeta .git) para poder hacer mis propias subidas y bajadas

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

Si el repositorio es privado:

git clone https://myusername:mypassword@github.com/path_to/myRepo.git
	

Descartar cambios

Para desechar los cambios hechos en un fichero:

git checkout – [ruta al fichero]

Para descartar los cambios hechos en todos los ficheros:

git checkout --

Ramas

Son bifurcaciones en el desarrollo del proyecto.

Para ver las ramas que hay y en cuál estoy :

git status

Para coger los cambios hechos en la rama principal y traerlas a nuestra rama

1. Cambiamos a la rama de la que queremos coger los cambios

   git checkout [branch]

2. Actualizamos esa rama

   git pull origin master

3. Volvemos a la rama que queremos actualizar

   git checkout [branch]

4. Actualizamos la rama en la que estamos con una rama específica

   git merge [branch]

Para crear una rama:

git branch [branch]

Para borrar una rama:

git branch -d [branch]

Nota

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.

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).

HEAD

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.

Borrar un fichero

git rm 'b.txt' # Lo contrario de add, borra los ficheros del disco y pone el cambio en el stage (pendientes) para que se realice en el futuro.

Si obtuviese este error:
error: 'a.txt' has changes staged in the index
(use --cached to keep the file, or -f to force removal)
Deberé hacer un commit antes de tratar de borrar los ficheros.

git rm -f 'b.txt' # Igual que el anterior pero no pone el cambio en el stage, sino que lo materializa directamente.
git commit -m "Ficheros añadidos" # Almacena los cambios hecho en git bajo el título “ficheros añadidos”
git log # muestra el histórica de subidas

Errores frecuentes

error: bad index file sha1 signature
fatal: index file corrupt

rm -f .git/index
git reset

error: inflate: data stream error (invalid distance too far back) fatal: loose object 23ab2e2a09403ca240f21f22b32a810855aaf7ce (stored in .git/objects/23/ab2e2a09403ca240f21f22b32a810855aaf7ce) is corrupt
Tendrás que borrar .git y volver a configurarlo desde el principio

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Copiamos el contenido del siguiente fichero:

cat ~/.ssh/id_rsa.pub

Y lo copiamos en github.com → Settings → Deploy Keys → Add Deploy Key → Key

error: The following untracked working tree files would be overwritten by checkout:
...
Please move or remove them before you can switch branches. Aborting

	
git clean  -d  -fx ""
	

A lo bestia

Subir lo que hay en local, sobreescribiendo lo que hay en el servidor (no hace falta hacer un pull):

git push origin master -f

Descargar lo que hay en el servidor, sobreescribiendo lo que hay en local:

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

Subir un plugin a jquery

I

1. Nos creamos una cuenta en github.
2. Creamos un repositorio en github. Por ejemplo, proba.git.
3. Abrimos el repositorio → settings → Webhooks & Services → Webhook →
   Payload URL: http://plugins.jquery.com/postreceive-hook
   Content type: application/x-www-form-urlencoded → update
4. Subimos nuestros ficheros a dicho repositorio.
5. Creamos y subimos en la raíz de nuestro repositorio local el fichero proba.jquery.json

   		
   {
   	"name": "monteserinGallery",
   	"title": "jQuery Monteserin Gallery",
   	"description": "Simple Carrusel Gallery.",
   	"keywords": [
   	"gallery",
   	"image",
   	"carrusell"
   	],
   	"version": "1.0.0",
   	"author": {
   		"name": "Pablo Monteserin",
   		"url": "https://pablomonteserin.com/"
   		},
   		"maintainers": [
   		{
   			"name": "Pablo Monteserin",
   			"email": "pablomonteserin@pablomonteserin.com",
   			"url": "https://pablomonteserin.com"
   		}
   		],
   		"licenses": [
   		{
   			"type": "MIT",
   			"url": "https://github.com/jquery/jquery/blob/master/MIT-LICENSE.txt"
   		}
   		],
   		"bugs": "https://github.com/monteserin/monteserinGallery/issues",
   		"homepage": "https://www.pablomonteserin.com/monteserin-gallery",
   		"docs": "https://github.com/monteserin/monteserinGallery",
   		"demo": "https://www.pablomonteserin.com/cosines/monteserinGallery/index.html",
   		"download": "https://github.com/monteserin/monteserinGallery",
   		"dependencies": {
   			"jquery": ">=1.5"
   		}
   	}
   		
   	

   Podemos validar el JSON aquí:
   http://plugins.jquery.com/docs/publish/

6. Ejecutamos el siguiente código desde consola

		
git add .
git commit -m "subida cambios”


git tag 1.0.0 #esta versión debe coincidir con la del manifest
git push origin --tags
		
	

Podemos consultar las etiquetas echas usando: git tag

Si hubiesemos tenido algún problema podemos consultar el log de jQuery.

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

Instalación de git-ftp

Documentación:
https://github.com/resmo/git-ftp/blob/develop/man/git-ftp.1.md

1. Instalamos resmo / git-ftp

   git clone https://github.com/resmo/git-ftp.git &&
   cd git-ftp &&
   git checkout master &&
   sudo make install

2. cd my_git_tracked_project

Configuración

git config git-ftp.user pablo 		#usuario ftp
git config git-ftp.password pablo 	#password ftp
git config git-ftp.url ftp.pablomonteserin.com/public_html
# para la primera subida. -v para verbose mode
git ftp init -s -v ftp.pablomonteserin.com/public_html

Posibles errores:
Si al hacer la primera subida obtuviese este error: git-ftp: line 408: /bin/curl: Bad file number fatal: Could not upload files., exiting... Se trata de un error de git-ftp. No es capaz de subir grandes cantidades de archivos en una sola operación.Puedo arreglarlo sacando de la carpeta que quiero subir unos cuantos miles de ficheros para ir haciendo la subida por partes. Esta es la mejor solución. También puedo crear el fichero .git-ftp-ignore, y poner en él algunas carpetas que serán ignoradas en la subida. Tener en cuenta que el fichero .git-ftp-ignore ignorará esas carpetas para siempre, aunque las hallamos eliminado del fichero Para ejecutar la línea de la primera subida, el fichero de configuración de git, el fichero .git-ftp.log no debe estar en el server.

Subida al ftp

sudo git add -A
sudo git commit -m "ultimo cambio"
git ftp push -v

Nota:
Puede ser útil exportar una variable de entorno para poder ejecutar cómodamente estos tres comandos: /home/monty/.bashrc → Añado la línea: export PATH="/media/monty/Datos/tutos/theory/apuntes":$PATH

Aviso Legal

Los derechos de propiedad intelectual sobre el presente documento son titularidad de D. Pablo Monteserín Fernández Administrador, propietario y responsable de pablomonteserin.com. El ejercicio exclusivo de los derechos de reproducción, distribución, comunicación pública y transformación pertenecen a la citada persona.

Queda totalmente prohibida la reproducción total o parcial de las presentes diapositivas fuera del ámbito privado (impresora doméstica, uso individual, sin ánimo de lucro).

La ley que ampara los derechos de autor establece que: “La introducción de una obra en una base de datos o en una página web accesible a través de Internet constituye un acto de comunicación pública y precisa la autorización expresa del autor”.

El contenido de esta obra está protegido por la Ley, que establece penas de prisión y/o multa, además de las correspondientes indemnizaciones por daños y perjuicios, para quienes reprodujesen, plagiaren, distribuyeren o comunicaren públicamente, en todo o en parte, o su transformación, interpretación o ejecución fijada en cualquier tipo de soporte o comunicada a través de cualquier medio.

El usuario que acceda a este documento no puede copiar, modificar, distribuir, transmitir, reproducir, publicar, ceder, vender los elementos anteriormente mencionados o un extracto de los mismos o crear nuevos productos o servicios derivados de la información que contiene.

Cualquier reproducción, transmisión, adaptación, traducción, modificación, comunicación al público, o cualquier otra explotación de todo o parte del contenido de este documento, efectuada de cualquier forma o por cualquier medio, electrónico, mecánico u otro, están estrictamente prohibidos salvo autorización previa por escrito de Pablo Monteserín.

El autor de la presente obra podría autorizar a que se reproduzcan sus contenidos en otro sitio web u otro soporte (libro, revista, e-book, etc.) siempre y cuando se produzcan dos condiciones:

1. Se solicite previamente por escrito mediante email al correo pablomonteserin@pablomonteserin.com.
2. En caso de aceptación, no se modifiquen los textos y se cite la fuente con absoluta claridad.

Una parte de las imágenes utilizadas en este documento no son propiedad de Pablo Monteserín, por lo que, si alguna de estas imágenes estuviera sujeta a derechos de autor, o a algún otro tipo de derecho que impida su publicación en este documento, una vez que el autor, Pablo Monteserín, tenga conocimiento del hecho, procederá a la retirada inmediata de la imagen protegida por los derechos pertinentes.