Git Cookbook. Cambiar en nuestro repositorio local la rama del repositorio remoto que seguimos

Git

Para la elaboración de este artículo se ha utilizado la versión de git 2.7.4

Esta situación nos la encontramos cuando trabajamos con multiples repositorios remotos en nuestro repositorio local y en un momento determinado queremos dejar de seguir a la rama del repositorio remoto por defecto origin por otra rama de otro repositorio remoto diferente.

Para verlo con más claridad vamos a verlo con una secuencia de comandos.

Estado local de nuestro repositorio

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Listado de los repositorios remotos

$ git remote -v
gitlab  ssh://... (fetch)
gitlab  ssh://... (push)
origin  ssh://... (fetch)
origin  ssh://... (push)

Cambiar el repositorio remoto por defecto al que seguimos

La opción -u es la misma que –set-upstream-to.

$ git branch -u gitlab/master
Branch master set up to track remote branch master from gitlab.

$ git status
On branch master
Your branch is up-to-date with 'gitlab/master'.
nothing to commit, working directory clean

A partir de este momento cada vez que hagamos cualquier operación con git donde interviene el repositorio, si no le indicamos nada, el repositorio por defecto donde se hace las operaciones es gitlab

Por ejemplo, cambiamos un fichero y hacemos un git push. Por defecto se va al repositorio remoto gitlab. Si no cambiamos el repositorio remoto por defecto al que seguimos, para enviar los cambios a origin tendriamos que hacer un git push origin master.

Vamos a seguir con la secuencia de comandos.

$ echo "Readme.md" > README.md
$ git add .
$ git commit -m "fichero readme"

# diferencia entre repositorio local y el remoto origin
#
$ git diff origin/master --name-only
README.md

# diferencia entre repositorio local y el remoto gitlab
#
$ git diff gitlab/master --name-only
README.md

# realizamos un push sin indicar el repositorio remoto. Los cambios van por defecto al repositorio *gitlab*
#
$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 299 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To ssh://...
   2c0999b..61dbe03  master -> master

# diferencia entre repositorio local y el remoto gitlab. En este caso no hay ninguna diferencia
#  
$ git diff gitlab/master --name-only

# diferencia entre repositorio local y el remoto origin. En este caso sigue existiendo el fichero modificado
#
$ git diff origin/master --name-only
README.md

# Subir los cambios al *origin* sin modificar el repositorio remoto que seguimos
#
$ git push origin master
Password authentication
Password:
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 299 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1)
remote: Updating references: 100% (1/1)
To ssh://...
   2c0999b..61dbe03  master -> master

# Ya no existe diferencia entre repositorio local y el remoto origin.
#
$ git diff origin/master --name-only

Git Cookbook, ¿Qué es el estado o modo DETACHED HEAD?

Git

Es cuando la referencia HEAD se encuentra apuntando a un commit anterior en el tiempo en vez de una rama.

Normalmente la referencia HEAD se encuentra apuntando a la rama actual que suele ser la rama master. Y la referencia a la rama master se encuentra apuntando al SHA-1 del último commit.

Cuando nos encontramos en detached head la referencia HEAD se encuentra apuntando al SHA-1 del commit donde nos hemos desplazado.

Sigue leyendo

Git Cookbook, clonar o descargar las ramas de un repositorio remoto

Git

Cuando hacemos un clone de un repositorio remoto lo que estamos haciendo es descargar la rama principal master. Si queremos además recuperar también sus ramas, debemos hacerlo por cada una de ellas.

Vamos a utilizar un proyecto cualquiera de github como ejemplo.

Sigue leyendo

Git Cookbook, diferencias entre el directorio de trabajo la staging area y el repositorio local

Git

Como sabemos cada vez que hacemos una modificación de un fichero y lo damos por bueno, lo siguiente que hacemos es presentarlo a la staging area. Finalmente cuando terminamos con todas las modificaciones lo subiremos al repositorio local realizando un commit.

Vamos a ver el uso del comando git diff para ver los cambios de 1 fichero en cada una de estas fases.

git diff, muestra los cambios realizados en nuestro directorio de trabajo y que todavía no han sido presentados en la staging area.

git diff –cached, muestra los cambios presentados en la staging area y que todavía no hemos realizado el commit en nuestro repositorio local.

git diff HEAD, muestra los cambios realizados en nuestro directorio de trabajo con respecto al repositorio local.

Ejemplo

En el siguiente ejemplo vamos a ver el comportamiento y la salida de cada uno de estos comandos.

Sigue leyendo

Git Cookbook, diferencias entre ficheros del repositorio local y remoto

Git

Una vez hemos hecho cambios en nuestro working directory, los pasamos a la staging area y finalmente hacemos el commit en nuestro repositorio local. Como paso final mandaremos los cambios locales de nuestro repositorio local al repositorio remoto.

En este punto a veces nos interesa saber los cambios que hemos realizado de alguno de nuestros ficheros o de todos ellos con respecto a la versión que tenemos en el repositorio remoto. El comando que hace esto es el siguiente.

Ver todas las diferencias entre el repositorio local y el repositorio remoto

$ git diff origin/master

Ver todas la diferencia de un fichero entre el repositorio local y el repositorio remoto

$ git diff origin/master:PATH_TO_FILE_REMOTE PATH_TO_FILE_LOCAL
$ git diff origin/master README.md
$ git diff origin/master:README.md README.md

Git Cookbook, configurando la instalación de Git con git config

Git

Una vez hemos instalado Git su configuración es bastante sencilla al estar basada en la modificación de un fichero de variables. Dependiendo del tipo de configuración que necesitemos, la modificación de este fichero se hace en un sitio diferente.

Estas variables definen el comportamiento que tendrá Git cuando ejecute sus comandos. Por ejemplo, alguna de ellas sirve para indicar el editor que debe utilizar para añadir el mensaje cuando hacemos un commit o creamos un tag, otras indican el usuario a utilizar cuando hacemos un commit, etc.

Todas esta variables se pueden crear, modificar y borrar. En este pequeño artículo vamos a ver como hacerlo y cuales son los ficheros afectados en estas operaciones.

Recordemos que al tener diferentes niveles de configuración, si tenemos una propiedad igual a nivel de un repositorio local, tendrá más preferencia sobre el valor de la misma variable a nivel de global o del sistema.

Configuración a nivel del sistema

Afecta a la configuración de Git de todo el sistema. En este caso a cualquier repositorio y usuario del sistema. El fichero modificado en este caso es

En sistemas Unix

/etc/gitconfig

En windows

%INSTALACION_GIT%/etc/gitconfig

Ejemplo listado de las variables

$ git config --list --system
core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
diff.astextplain.textconv=astextplain
rebase.autosquash=true
user.name=user name system
user.email=system@domain

Obtener el valor de una de las variables

$ git config --system --get user.name
user name system

Modificación de una de las variables

$ git config --system user.name myuser
$ git config --system --get user.name
myuser

Creación y borrado de una nueva variable

$ git config --system --add key.one value1
$ git config --system --get key.one
value1
$ git config --system --unset key.one
$ git config --system --get key.one
.

Configuración a nivel de usuario llamado también configuración a nivel global

Afecta a la configuración de Git de un usuario. En este caso solo a sus repositorios. El fichero modificado en este caso es

$USER_HOME/.gitconfig

Listado de las variables

$ git config --list --global
user.name=user name global
user.email=global@domain
core.autocrlf=true

Obtener el valor de una de las variables

$ git config --global --get user.name
user name global

Modificación de una de las variables

$ git config --global user.name myuser_global
$ git config --global --get user.name
myuser_global

Creación y borrado de una nueva variable

$ git config --global --add key.one value1
$ git config --global --get key.one
value1
$ git config --global --unset key.one
$ git config --global --get key.one
.

Segunda configuración a nivel de usuario

Tiene preferencia la configuración a nivel de usuario vista anteriormente sobre esta configuración. El fichero afectado en este caso si existe es

$XDG_CONFIG_HOME/git/config

Y el caso de que el anterior fichero no exista, el fichero sería:

$USER_HOME/.config/git/config 

Recordemos que XDG_CONFIG_HOME es una variable que estaría apuntando a un directorio de configuración según la especificación XDG Base Directory Specification

Aunque se recomienda no utilizar este fichero de configuración.

Configuración a nivel de repositorio o configuración local

Solo afecta a la configuración del repositorio donde lo modificamos. El fichero afectado en este caso es

$DIR_CURRENT_REPOSITORY/.git/config

Creamos un nuevo repositorio

$ cd /temporal
$ mkdir my_repo
$ cd my_repo
$ git init
Initialized empty Git repository in /TEMPORAL/my_repo/.git/

$ git add .
$ git commit -m "version inicial"
On branch master

Initial commit

nothing to commit

Listado de las variables

$ git config --list --local
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly

Creación, obtención, modificación y borrado de una nueva variable

$ git config --local --add key.one value1
$ git config --local --get key.one
value1
$ git config --local key.one value2
$ git config --local --unset key.one
$ git config --local --get key.one
.

Configuración del usuario y email asociado a este repositorio

$ git config --local user.name myuser_local
$ git config --local user.email myuser_local@localdomain
$ git config --local --get user.name
myuser_local
$ git config --local --get user.email
myuser_local@localdomain

Git Cookbook, deshacer un cambio pendiente de commit

Git

Estamos ante el caso de un recurso que hemos modificado, lo hemos presentado en el area de commit, y ahora queremos deshacer los cambios.

En el ejemplo hemos modificado el recurso pom.xml, lo hemos presentado en el área de commit, y finalmente tenemos que deshacer los cambios para dejarlo en la versión inicial.

Modificamos el recurso pom.xml y lo subimos al área de commit

$ git add pom.xml

Eliminamos los cambios del área de commit

$ git reset HEAD pom.xml

Volvemos a la versión inicial

$ git checkout pom.xml