Diferencia entre revisiones de «Git»
(→Branches) |
(→Administración de branches) |
||
| Línea 302: | Línea 302: | ||
== Administración de branches == | == Administración de branches == | ||
| + | |||
| + | Para ver la lista de branches | ||
| + | |||
| + | <pre> | ||
| + | git branch | ||
| + | </pre> | ||
| + | |||
| + | 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 == | ||
Revisión de 17:05 27 ene 2013
Contenido
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
