Derek Molloy - Raspberry Pi® a fondo para desarrolladores

config HEAD index logs packed-refs

El directorio oculto .git contiene toda la información acerca del repositorio, como mensajes de commit, archivos de log y los objetos de datos. Por ejemplo, la ubicación del repositorio remoto se encuentra en el archivo config.

pi@erpi ~/test/.git $ more config | grep url

url = https://github.com/derekmolloy/test.git

La sección "Otras lecturas", al final del capítulo, incluye una referencia a un magnífico libro sobre Git que está disponible en la red de forma gratuita. En él se describe con detalle la estructura del directorio .git. Por fortuna, ahora no debemos introducir ningún cambio en el directorio .git, puesto que tenemos comandos Git que lo harán por nosotros.

NOTA Esta guía paso a paso utiliza el propio repositorio "test" del autor. No obstante, no le resultará difícil al lector crear su propio repositorio en GitHub. Después de configurar una cuenta gratuita en GitHub, diríjase a "Create New" (crear nuevo) y, luego, "New repository" (nuevo repositorio). Dé un nombre y una descripción al repositorio y hágalo disponible públicamente, seleccione la opción para inicializarlo con un README y, luego, seleccione "Create Repository" (crear repositorio). A partir de aquí podrá seguir estas instrucciones con el repositorio de su propia cuenta, y, en consecuencia, podrá comunicarse desde su RPi con su propio repositorio en GitHub.

Cómo obtener información de estado (git status)

Ahora que contamos con nuestro repositorio, el paso siguiente es añadir un nuevo archivo de texto al directorio de trabajo, donde estará en estado untracked (sin seguimiento). Cuando ejecutamos el comando git status, observamos un mensaje que indica que hay untracked files, es decir, archivos sin seguimiento:

pi@erpi ~/test $ echo "Just some text" > newfile.txt

pi@erpi ~/test $ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Untracked files:

(use "git add ..." to include in what will be committed)

newfile.txt

nothing to commit, untracked files present (use "git add" to track)

El paso siguiente consiste en añadir cualquier archivo sin seguimiento (untracked) al área de preparación (staging area). No obstante, si no desea añadir un conjunto de archivos, también puede crear uno llamado gitignore para obviarlos. Por ejemplo, esto resultaría útil si en un proyecto C/C++ decidimos que no queremos archivos objeto, .o, intermedios. He aquí un ejemplo de cómo crear un archivo .gitignore destinado a ignorar archivos objeto, .o, de C/C++:

pi@erpi ~/test $ echo "*.o" > .gitignore

pi@erpi ~/test $ more .gitignore

*.o

pi@erpi ~/test $ touch testobject.o

pi@erpi ~/test $ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Untracked files:

(use "git add ..." to include in what will be committed)

.gitignore

newfile.txt

nothing to commit, untracked files present (use "git add" to track)

En este caso, hay dos archivos sin seguimiento, pero no existe mención al archivo testobject.o, lo que indica que se está ignorando tal como queríamos. Observe que el archivo .gitignore forma parte también del repositorio y que se conservará en cualquier clonación del mismo, junto con su histórico de cambios, etc.

Cómo añadir archivos al área de preparación (git add)

Los archivos del directorio de trabajo se pueden añadir ahora al área de preparación con el comando git add . (comando que incluye todos los archivos en el directorio de trabajo, con la excepción de los archivos ignorados). En este ejemplo, dos archivos se agregan desde el directorio de trabajo al área de preparación. Luego, podemos mostrar el estado del repositorio del siguiente modo:

pi@erpi ~/test $ git add .

pi@erpi ~/test $ git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

(use "git reset HEAD ..." to unstage)

new file: .gitignore

new file: newfile.txt

Para eliminar (remove) un archivo del área de preparación, usamos git rm somefile.ext.

Cómo hacer commit en el repositorio local (git commit)

Después de añadir archivos al área de preparación, podemos hacer commit y convertir en definitivos los cambios desde aquella en el repositorio Git. Primero, podríamos querer añadir nuestro nombre y dirección de correo electrónico para indicar quién realiza el commit con los cambios.

pi@erpi ~/test $ git config --global user.name "Derek Molloy"

pi@erpi ~/test $ git config --global user.email derek@my.email.com

Estos valores se configuran a partir de los de nuestra cuenta de usuario Linux, de manera que persisten en el siguiente inicio de sesión. Para verlos, podemos escribir more ~/.gitconfig.

El commit permanente de los cambios de los archivos en el repositorio Git local se hace con el comando git commit:

pi@erpi ~/test $ git commit -m "Testing the repository"

[master 3eea9a2] Testing the repository

2 files changed, 2 insertions(+)

create mode 100644 .gitignore

create mode 100644 newfile.txt

Los cambios se marcan con el nombre de usuario, pero también requieren la inclusión de un mensaje. Si queremos detallar el mensaje en la línea, usamos -m para establecerlo.

NOTA El atajo git commit -a realiza un commit de los archivos modificados directamente en el repositorio local, sin necesidad de invocar add. No añade archivos nuevos. Observe la figura 3-4 en este mismo capítulo.

Envío al repositorio remoto (git push)

Para realizar este paso, debemos poseer una cuenta propia en GitHub. El comando git push envía cualquier cambio en el código al repositorio remoto. Para que tales cambios se apliquen, debemos estar registrados como usuarios que pueden, en efecto, realizar modificaciones. En Git 2.0 se ha implementado un nuevo método llamado simple, más conservador, para enviar a repositorios remotos. Está seleccionado de forma predeterminada, pero puede suprimir algún mensaje de advertencia, y el envío se puede realizar del siguiente modo (sustituya los detalles de usuario y repositorio por los suyos propios):

pi@erpi ~/test $ git config --global push.default simple

pi@erpi ~/test $ git push

Username for 'https://github.com': derekmolloy

Password for 'https://derekmolloy@github.com': mySuperSecretPassword

Counting objects: 4, done.

Delta compression using up to 4 threads.

Compressing objects: 100% (2/2), done.

Writing objects: 100% (4/4), 350 bytes | 0 bytes/s, done.

Total 4 (delta 0), reused 0 (delta 0)

To https://github.com/derekmolloy/test.git

f5c45f4..3eea9a2 master -> master

Después de que el código haya sido enviado (push) al repositorio remoto, podemos traer (pull) los cambios al repositorio local de cualquier máquina gracias al comando git pull desde el interior del directorio del repositorio local:

pi@erpi ~/test $ git pull

Already up-to-date.

En este caso, todo está actualizado.

Ramas de desarrollo de Git

Git contempla el concepto de ramas de desarrollo (branching), lo que nos permite trabajar en múltiples versiones diferentes del conjunto de archivos de nuestro proyecto. Por ejemplo, para desarrollar una nueva característica en nuestro proyecto (versión 2) pero conservar el código de la versión actual (versión 1), crearíamos una nueva rama (versión 2). Ninguna de las nuevas características o cambios introducidos en la versión 2 afectará al código de la versión 1. Después podremos pasar de una rama a otra con facilidad.

Cómo crear una rama de desarrollo (git branch)

Suponga, por ejemplo, que desea crear una nueva rama llamada mybranch (acción denominada "ramificar"). Puede hacerlo con el comando git branch mybranch y, luego, pasar a trabajar con ella usando git checkout mybranch del siguiente modo: