Diferencia entre revisiones de «Git»

De Ardemans Wiki
Saltar a: navegación, buscar
(Servidor de Git)
(Rebasing)
Línea 318: Línea 318:
  
 
== Rebasing ==
 
== Rebasing ==
 +
 +
= Submódulos =
 +
 +
< aqui falta mucha documentación >
 +
 +
== Mover un submódulo ==
 +
En la versión 2 de git parece que hay comandos para mover un submodulo, pero para versiones inferiores la operativa es bastante tediosa. Gracias a dios hay gente que se curra scripts que lo hacen de forma rápida:
 +
 +
https://github.com/iam-TJ/git-submodule-move
  
 
=Servidor de Git=
 
=Servidor de Git=

Revisión de 14:33 24 abr 2015

Introducción

Trabajo básico con el sistema distribuido de gestión de versiones Git. Algunos apuntes básicos para no olvidar.

Lo más importante es no olvidar que Git no trabaja con diferencias, sinó con snapshots de repositorios.

Los ficheros tienen tres estados posibles:

  • commited
  • modified
  • staged

Referencias

  • Pagina web con el libro Pro Git aqui

Comandos básicos

Generar un nuevo repositorio

Para hacer que un directorio esté gestionado por git usamos el comando

git init

Con eso, hacemos que el directorio actual sea controlad por git. Después podemos añadir los ficheros que hay dentro de ese directorio a git para que sean gestionados

git add *
git add <fichero>
git add <directorio>

Si especificamos un directorio se añadie todo su contenido de forma recursiva Una vez añadido los ficheros hay que validarlos haciendo commit

git commit -m "Subida inicial"

Clonar un repositorio

Para clonar un repositorio ya existente:

git clone git://github.com/schacon/grit.git
git clone file:///<path del original>
git clone https://server/path.git

Guardando cambios

Hay cuatro estados en el ciclo de vida de un fichero dentro de un repositorio git.

  • untracked (no está controlado por git)
  • unmodified (no ha sido modificado con respecto a lo que hay en git)
  • modified (se ha modificado)
  • staged (pendiente de ser subido a git)

Ver el estado

Para ver el estado de los ficheros de un repositorio, desde el raiz podemos user al comando

git status

pasar a stagin

Cuando se modifica un fichero controlado por git de forma automática aparece como modificada, antes de ser subido a git hay que pasarlo a staging y se hace con el comando

git add <fichero>

Un fichero modificado pero que no esta en stagin no se hará efectivo con commit

Ver modificaciones

Si queremos ver no solo que ficheros han sido modificados sino también que es lo que se ha modificado, podemos usar:

git diff <fichero>
git diff 

Si solo queremos ver solo los ficheros que ya están en stagin y ver sus diferencias con lo que tenemos en en git podemos usar el parámetro

git diff <fichero> --staged

Hacer commit

Para aceptar los cambios que hemos hecho solo tenemos que ejecutar

git commit

Nos aparecerá el editor que hayamos especificado por defecto para añadir comentarios, y si no queremos que aparezca el editor podemos ponerlo directamente con el parámetro -m

git commit -m "comentario"

Si queremos saltarnos el paso de hacer stagin a los ficheros que hemos modificado, podemos hacerlo de forma automática durante el commmit, simplemente añadiendo el parámetro -a: hará el add de forma automática a todos los ficheros que estén en estado modified

Borrar ficheros

Si borramos un fichero sin más con rm nos aparecer en la zona de ficheros modificados sin hacer staging.Si lo hacemos con git aparecerá en el area de ficheros en staging

git rm <fichero>

Así que la proxima vez que hagamos commit ya no estará ese fichero en esa revisión y además no seguirá estando controlado por git (untracked) Si solo se quiere borrar el fichero de git pero conservarlo en el directorio de trabajo se puede usar la opción --cached

git rm --cached <fichero>

Se puede borrar directorios y especificar patrones, pero los caracteres especiales de los patrones hay que escaparlos:

git rm log/\*.log

Mover ficheros

Para mover un fichero:

git mv <fichero>

Que es equivalente a hacer:

mv <fichero> <fichero.new>
git rm <fichero>
git add <fichero.new>

Viendo el historial

Para ver los cambios realizados se usa el comando

git log

Por defecto muestra la información de los cambios. Tiene muchas opciones, las mas comunes son:

  • -p muestra los cambios de cada commit
  • -2 muestra los dos últimos cambios
  • --stat muestra los últimos cambios de la revisión con los ficheros modificados y algunas estadisticas

También se puede dar formato a la salida de log:

git log --pretty=format:"%h %s" --graph

Limitando la salida de Log

A parte de poner -<n> (como el 2) que limita el numero de salidas de log, tambien se pueden usar: --since y --until

git log --since=2.weeks


Deshaciendo cambios

Se puede deshacer un commit si se ha olvidad añadir algo en el último que hicimos. Estos se hace con

git commit --amend

deshaciendo cambios del staging

Si se ha añadido un fichero a stagin de forma erronea se puede sacar de ahí:

git reset HEAD <fichero>

revirtiendo cambios a un fichero modificado

Si quieres volver a poner un ficher como estaba antes de modificarlo, se pude usar:

git checkout -- <fichero>

Trabajando con repositorios remotos

Como ya hemos visto, se pude clonar un repositorio remoto con

git clone <url>

Una vez estemos en el repositorio podemos ver el original con el comando

git remote

Si pones el parámetro -v además te muestra la URL del origen Un working copy puede tener mas de un repositorio, además le podemos dar nombre a cada uno

git remote add <nombre> url

y al ver de nuevo la lista de remotos con -v veremos la lista de repositorios remotos a la que tenemos acceso.

Si queremos añadir nuestors cambios al repositorio remoto tendremos que usar el push

git push <repositorio> <branch>

Si queremos recibir datos del origen usaremos pull

git pull <repositorio> <branch>

Si queremos renombrar uno de nuestros repositoros locales usaremos

git remote rename <nombre> <nuevo.nombre>

Si queremos eliminar uno de los repositorios

git remote rm <nombre>

Los Tags

Normalmente cuando se llega a un estado concreto de desarrollo se marca ese momento con una etiqueta que lo define. Normalmente son versiones, por ejemplo. "v.1.0"

Para ver una lista de tags de nuestro repositorio se usa:

git tag

también se puede buscar por patrones

git tag -l "v.1.*"

Para crear una etiqueta en un punto concreto

git tag -a v.1.0 -m "descripción de la version"

Después, se puede ver la información de esa etiqueta en concreto con:

git show v.1.0

También hay forma de crear una etiqueta firmada con encriptación PGP con el parámetro -s

Otra forma de etiquetas son las de bajo peso (lightweight tag), que se crean sin ningun parámetro,simplemente poniendo

git tag <nombre>

Se puede etiquetar después de haber hecho una subida. Si listamos los commit que se han realizado con:

git log --pretty=oneline

Veremos la lista de commits, con sus comentarios, y podremos poner un tag a clauqiera de ellos

git tag -a v1.2 -m 'version 1.2' 9fceb02

Los tags no se suben al repositorio de origen cuando hacemos push, para eso tenemos que hacer el push especificando el tag, o bien podemos poner la opción --tags

git push origin <tag>
git push origin --tags

Branches

Para crear un nuevo branch desde el commit actual solo hay que ejecutar el comando

git branch <nombre>

Para cambiar entre branches en el que estamos trabajando ejecutamos

git checkout <nombre>

Esto lo que hace es cambiar el puntero HEAD al branch en el que estamos trabjando. Por defecto, el primer branch que existe se llama master

También podemos crear un branch nuevo y cambiar directamente a él haciendo

git checkout -b <nombre>

una vez hemos trabajado con un branch, podemos reintegrarlo al branch principal, master, cambiandonos a él y haciendo un merge

git checkout master
git merge <branch temrinado>

Si no ha habido ninguna devergencia entre medias, ningún otro cambio en el branch master y los cambios solo se han realizado en el branch nuevo creado, se simplifica el merge haciendo un "fast forward". Solo mueve el puntero hacia alante hasta donde está el puntero del nuevo branch.

Una vez que está el puntero master y el puntero del nuevo branch en el mismo sitio se puede borrar el branch nuevo.

git branch -d <branch>

En el caso de que si haya divergencia entre los dos branches, Git calcula el punto comun donde hubo esa divergencia, y a partir de ellos crea un nuevo "commit" especial, con el puntero apuntando como referencia a los dos anteriores que tenían los dos branches. Se explica mejor en el libro pro git, en el apartado de basic mergin.

En este caso, cuando hace el merge, aparece el texto "merge made by recursive" y una vez que se ha hecho el merge se puede borrar el branch con el que estabamos trabajando, con el mismo comando que antes.

Conflictos básicos

Es cuando en dos branches que vienen de un mismo punto se han modificado ficheros en el mismo punto. Git no es capaz de solucionar el conflicto de forma clara, y te ofrece el solucionarlo antes de hacer el merge.

Para ver los ficheros que están en conflicto se usa el comando

git status

y dirá los ficheros que necesitan que se solucione el merge. El fichero en el branch sobre el que se ha hecho el merge tendrá un mensaje en la zona de conflicto, donde se indica con los simbolos <<<<<<<, ======= y >>>>>>> lo que está en conflicto. Una vez solucionado el conflicto se hace un git add del fichero.

Otra forma de resolverlo es utilizar el comando

git mergetool

donde hará preguntas de como resolver el conflicto. Además se puede elegir el programa con el que editar los conflictos.

Una vez terminado el conflicto se hace un git commit y se pueden añadir comentarios sobre como se ha solucionado el conflicto, por ejemplo.


Administración de branches

Para ver la lista de branches

git branch

Devuelve una lista de branches y además indica en cual estamos actualmente.

Si añadimos el parámetro -v además nos dará información sobre cada uno de ellos.

Si queremos ver los branches que están (o no) merged también podemos usar los parámetros --merged y --no-merged

Branches remotos

Rebasing

Submódulos

< aqui falta mucha documentación >

Mover un submódulo

En la versión 2 de git parece que hay comandos para mover un submodulo, pero para versiones inferiores la operativa es bastante tediosa. Gracias a dios hay gente que se curra scripts que lo hacen de forma rápida:

https://github.com/iam-TJ/git-submodule-move

Servidor de Git

Se puede montar un servidor de Git con diferentes protocolos.

  • local
  • http
  • ssh
  • propio de git

Practicamente el que mas se usa es a través de ssh, y para mis pruebas inciales creo que va a ser lo más sencillo, así que me voy a centrar en ello:

Git-shell

Si se necesita crear un usuario que tenga acceso a repositorios de Git por ssh pero no queremos que pueda realizar consultas al resto de ficheros del sistema o ejecutar nada que no sea comandos de git, tenemos el git-shell. Podemos crear el usuario con la Shell /usr/bin/git-shell y de esta forma nos aseguramos que no podría ejecutar nada que no nos interese.

Otra alternativa podría ser crear un chroot jail para un servicio de SSH separado solo para Git, y así añadimos seguridad a nuestro sistema.