GIT

Comandos básicos

Configurar datos basicos

$ git config --global user.name "Mi nombre"
$ git config --global user.email "mi@correo.com"

Listar configuración de git en el repositorio local

$ git config -l

Generar llave pública ssh

$ ssh-keygen -t rsa -C "your_email@example.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/jperez/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /Users/jperez/.ssh/id_rsa.
Your public key has been saved in /Users/jperez/.ssh/id_rsa.pub.
The key fingerprint is:
43:c5:5b:5f:b1:f1:50:43:ad:20...

Habilitanto conexión SSH sobre HTTPS (puerto 443)

Si puede acceder a SSH en git@ssh.github.com a través del puerto 443, puede anular su configuración de SSH para forzar cualquier conexión a GitHub a ejecutar a través de ese servidor y puerto. Esto es muy útil cuando el firewall de la red bloquea el puerto 22 que es el que utiliza por defecto ssh.

Para establecer esto en su ssh config, edite el archivo en ~ / .ssh / config y agregue esta sección:

Host bitbucket.org
  Hostname  altssh.bitbucket.org
  Port  443

Host github.com
  Hostname ssh.github.com
  Port 443

Crear un nuevo repositorio remoto

$ echo "# wsdecmail" >> README.md 
$ git init
$ git add README.md
$ git commit -m "first commit"
$ git remote add origin git@github.com:organizacion/nombrerepositorio.git
$ git push -u origin master

Crear una copia de un repositorio local

$ git clone /path/to/repository

Crear una copia de un repositorio remoto

git clone username@host:/path/to/repository

Comprobando el estado de tus archivos

$ git status

Preparando archivos (add)

Para empezar el seguimiento de un nuevo archivo se usa el comando git add

$ git add README.md

$ git add <filename>
$ git add *

Si vuelves a ejecutar el comando git status, verás que README.md está ahora bajo seguimiento y preparado:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   README
#

Confirmando tus cambios

$ git commit -m "Mensaje del commit"

Ahora el archivo esta comiteado a HEAD, pero todavía no en tu repositorio remoto.

Eliminando archivos

Para eliminar un archivo de Git, debes eliminarlo de tus archivos bajo seguimiento (más concretamente, debes eliminarlo de tu área de preparación), y después confirmar.

Hay dos formas de eliminar archivos de git.

Opción 1. Eliminar manualmente los archivos físicos del directorio de trabajo y luego ejecutar los siguientes comandos:

$ git add -u README.md
$ git commit -m "Se elimina archivo README"

Opción 2. Utilizar el comando git rm. El comando git rm elimina el archivo de los archivos bajo seguimiento y también elimina el archivo físico del directorio de trabajo, para que no se vea entre los archivos sin seguimiento.

$ git rm README.md
$ git status
# On branch master
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    grit.gemspec
#
$ git commit -m "Se elimina archivo README"

Ver el log de confirmaciones

$ git log

Comparar archivos

$ git diff dir/archivo/a/comparar

Push a cambios de repositorio local a master

$ git status
$ git add README.md
$ git status
$ git commit -m "Archivo README"
$ git status
$ git pull
$ git push origin master
$ git status

Agregar un tag

$ git tag v1.0
$ git push origin master --tags

Eliminar un tag

$ git tag -d v1.0
$ git push origin :refs/tags/v1.0

Crear una rama y cambiarse a esta

$ git checkout -b nombre_de_la_rama

Crea una rama sin cambiarse a esta

$ git banch nombre_rama

Listar todas las ramas

$ git branch

Borrar una rama homologada

$ git branch -d nombre_rama

Eliminar ramas remotas

$ git push origin --delete serverfix
To https://github.com/schacon/simplegit
 - [deleted]         serverfix

Hacer merge a una rama

$ git checkout develop
$ git merge myfeature

Busca un Bug

$ git bisect

Actualizar todo lo que está en un repositorio remoto sin hacer merge

$ git fetch

Rebase

$ git rebase
$ git pull --rebase origin master

Detalle de quien modifico cada línea de un archivo

$ git blame dir/archivo

Eliminar el último commit de mi repositorio local manteniendo las modificaciones

$ git reset HEAD~1

Eliminar el último commit remoto manteniendo las modificaciones

$ git reset HEAD~1
$ git push origin {branch_name} -f

Eliminar el último commit de mi repositorio local perdiento las modificaciones

$ git reset --hard HEAD~1

Eliminar el último commit remoto perdiento las modificaciones

$ git reset --hard HEAD~1
$ git push origin {branch_name} -f

Revertir un commit

$ git revert effd90bb1328bf103dae3e67e0707bd6d87727b3

Editar el mensaje de un commit que se encuentra en el repositorio local

$ git commit --amend

Agregar una URL remota

Listar las url remotas existentes:

$ git remote -v

Agregar url remota:

$ git remote add origin https://username@stash/scm/PROJECT/repo.git

Cambiar una URL remota

Listar las url remotas existentes:

$ git remote -v

Configurar la nueva url remota:

$ git remote set-url origin git@github.com:foo/repositorio.git

Crear una nuevo repositorio

$ git init
$ git status
$ git add .
$ git status
$ git commit -m "First commit"
$ git status
$ git remote -v
$ git remote add origin https://username@stash/scm/PROJECT/repo.git
$ git remote -v
$ git push origin master
$ git status

Usar por ejemplo en caso de cambiar el nombre de un repositorio.

Stash

Permite cambiar de rama cuando uno tiene cambios pendientes de confirmar. git stash crea una copia de la rama y la deja en algún lugar.

$ git stash

Para volver a la rama y recuperar los cambios no confirmados se utiliza git stash apply:

$ git stash apply

Traer los cambios de la rama original a la rama fork

$ git remote add upstream https://github.com/frontendchile/javascript.git
$ git config -l
$ git fetch upstream
$ git pull upstream master
$ git log

Gitflow - Modelo de ramificación

Ramas principales

El repositorio central tiene 2 ramas principales:

master
develop

La rama master

En la rama origin/master el código fuente de HEAD SIEMPRE está listo para producción.

origin/develop

En la rama origin/develop el código fuente de HEAD siempre refleja un estado con los últimos cambios de entrega para el desarrollo de la próxima versión.

Cuando el código fuente que está en develop llega a un punto estable (totalmente probado y funcional), todos los cambios se incluyen en master con un nuevo número de versión. Esto cambia cuando ocupamos las ramas de apoyo.

Ramas de apoyo

Ramas de características (features)
Ramas de lanzamiento (Realease)
Ramas de revisiones (hotfixes)

Ramas Características (features)

Se utiliza para desarrollar nuevas caracteristicas o funcionalidades para una nueva versión. *Una rama de caracteristica existe siempre y cuando la función está en desarrollo, finalmente se fusiona de nuevo en develop

Creación de una rama de caracteristicas

Crear una rama x a partir develop y se cambia a esta.

$ git checkout -b myfeature develop

Incorporación de una nueva característica en develop

$ git checkout develop 
Switched to branch 'develop' 
$ git merge --no-ff myfeature 
Updating ea1b82a..05e9557 (Summary of changes) 
$ git branch -d myfeature 
Deleted branch myfeature (was 05e9557). 
$ git push origin develop

Ramas de lanzamiento (release)

Se ramifican a partir de develop. Se deben combinar de nuevo en develop y master. La nomenclatura para estas branchs es release

La rama release apoya la preparación de una nueva versión para producción. Es la rama que se pasa al ambiente de QA y permite corregir las incidencias menores.

Creación de una rama de lanzamiento

$ git checkout -b release-1.2 develop 
Switched to a new branch "release-1.2" 
$ git commit -a -m "release 1.2" 
1 files changed, 1 insertions(+), 1 deletions(-)

Esta nueva rama va a existir durante un tiempo, hasta que se libere la nueva release. Durante ese tiempo la corrección de errores DEBE aplicarse en esta rama en vez de en develop.

Terminar un lanzamiento

Cuando la rama de lanzamiento está lista para llevarse a producción (liberarse) es necesario realizar una serie de acciones. En primer lugar, la nueva rama se fusiona con master (ya que por definición cada commit en master es una nueva versión). A continuación, se deben tagear/documentar los nuevos cambios para tener referenciado el histórico de esta versión. Por último, los cambios realizados en la rama de lanzamiento deben ser incluidos de nuevo en develop, con el fin de que futuras versiones también contengan estas correcciones de errores.

Los dos primeros pasos de Git son:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

Se hace un merge a la rama master y se crea una etiqueta con la versión del release.

Para mantener los cambios en la rama de release (lanzamiento), se hace un merge con la rama develop:

$ git checkout develop 
Switched to branch 'develop' 
$ git merge --no-ff release-1.2 
Merge made by recursive. 
(Summary of changes)

Al realzar el merge puede dar algún conflicto, de ser así debemos corregir el conflicto y hacer commit.

Finalmente, eliminar la rama release ya que no la vamos a necesitar más.

$ git branch -d release-1.2 
Deleted branch release-1.2 (was ff452fe).

Ramas de revisiones (hotfixes)

Se ramifican a partir de master y se deben combinar de nuevo en develop y master. La nomenclatura debe ser hotfix.

Si un bug es crítico debe ser resuelto inmediatamente. La esencia de este me método de trabajo es que los miembros del equipo (rama develop) pueden seguir trabajando mientras que otra persona soluciona el bug.

Creación de una rama hotfix

$ git checkout -b hotfix-1.2.1 master 
Switched to a new branch "hotfix-1.2.1" 
$ git commit -a -m "hotfix to 1.2.1" 
1 files changed, 1 insertions(+), 1 deletions(-)

Hecho el Fix, se confirma la corrección con uno o más commits.

$ git commit -m "Fixed severe production problem" 
[hotfix-1.2.1 abbe5d6] Fixed severe production problem 
5 files changed, 32 insertions(+), 17 deletions(-)

Terminar una rama de hotfix

Cuando se termine la corrección de errores, las soluciones deben ser incluidas de nuevo en la rama master, pero tambien deben incluirse en la rama develop con el fin de salvaguardar todos los cambios. Este paso es similar la liberación de una rama despues de una release.

Nos cambiamos a la rama master, hacemos un merge con la rama hotfix y creamos un tag con la nueva versión:

$ git checkout master 
Switched to branch 'master' 
$ git merge --no-ff hotfix-1.2.1 
Merge made by recursive. 
(Summary of changes) 
$ git tag -a 1.2.1

Después pasamos el fix a develop:

$ git checkout develop 
Switched to branch 'develop' 
$ git merge --no-ff hotfix-1.2.1 
Merge made by recursive. 
(Summary of changes)

La única excepción de la regla es que, cuando existe una rama release, los cambios en las revisiones se fusionaran en esa rama de lanzamiento en lugar de develop.

Finalmente eliminamos la rama hotfix:

$ git branch -d hotfix-1.2.1 
Deleted branch hotfix-1.2.1 (was abbe5d6).

Resumen

Tener este modelo puede ser realmente útil en nuestros proyectos. Es fácil construir un modelo mental que permite a los miembros del equipo entender los procesos de ramificación y liberación.

Fuente:

aduartem/apuntes_git.md

Select an option

No results found