Raspberry Pi® a fondo para desarrolladores. Derek Molloy

(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 <file>..." 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 <file>..." 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 [email protected]

      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://[email protected]': 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:

      pi@erpi ~/test $ git branch mybranch

      pi@erpi ~/test $ git checkout mybranch

      Switched to branch 'mybranch'

      Ahora, para demostrar el funcionamiento de todo esto, suponga que un archivo temporal llamado testmybranch.txt se añade al repositorio. Este podría ser un nuevo archivo de código para nuestro proyecto. Puede observar que el estado de la rama de desarrollo deja claro que el directorio de trabajo contiene un archivo sin seguimiento:

      pi@erpi ~/test $ touch testmybranch.txt

      pi@erpi ~/test $ ls

      newfile.txt README.md testmybranch.txt testobject.o

      pi@erpi ~/test $ git status

      On branch mybranch

      Untracked files:

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

      testmybranch.txt

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

      Puede