Con esto se configura un nombre y correo para un usuario UNIX, no hace falta hacerlo en cada repositorio y copia local que clones.
$ git config --global user.name "Tu nombre"
$ git config --global user.email "email@example.com"
Al clonar un repositorio remoto con el siguiente comando creara una copia local. La copia local tiene referencia al repositorio remoto y guarda la historia de cambios locales.
git clone urldelrepositorio
El urldelrepositorio puede ser tipo ssh o http e incluir un usuario
Los de tipo ssh son algo asi. Se pueden usar en servidores que tenga usuario con claves publicas tipo ssh
user@servidor:pathalrepositorio/repositorio.git
ej: git@bitbucket.org:rcpracticas2/p1equipo55.git
Los de tipo http. Se pueden conseguir sin usuario y contraseña o a veces piden usuario y contraseña. Normalmente se usan en repositorios publicos que cualquiera puede descargar para tener el software pero no puedes enviar cambios.
http://servidor:pathalrepositorio/repositorio.git
Ver el status de la copia local, lista que cambios hay en los ficheros que no han sido enviados a la historia. Normalmente aparecen en rojo los cambios no añadidos. En verde los cambios que han sido preparados para añadirse a la historia (con git add) pero que aun no han sido formalmente enviados (con git commit). Los cambios que estan en la historia no aparecen
git status
Además, git status muestra las acciones más típicas a realizar después como son las de añadir el fichero para un posible commit (git add que se ve a continuación) o deshacer estos cambios en los ficheros a los que accedemos, con git checkout.
Con git status vemos que el fichero ha cambiado, pero no sabemos qué ha cambiado exactamente. Esto lo podemos ver con git diff:
$ git diff
diff --git a/prueba.txt b/prueba.txt
index 007ac26..62aa032 100644
--- a/prueba.txt
+++ b/prueba.txt
@@ -1 +1,2 @@
Texto de prueba
+Más datos
Las últimas líneas muestran los cambios que se han hecho. En concreto, las líneas que comiencen por el símbolo + indican que se han añadido y si empiezan por el símbolo - indican que se han eliminado. Si tienen un espacio significa que esa línea no ha sufrido variación.
Conociendo esto, podemos ver el fichero contenía la línea Texto de prueba y que hemos añadido Más datos.
Preparar (añadir) un fichero con cambios para ser incluido en la historia
git add fichero
Preparar el borrado de un fichero para que sea incluido a la historia
git rm fichero
Si solo borras el fichero. No lo encuentra pero no asume que quieres que en la historia se apunte que has borrado el fichero para quitarlo de la historia hay que preparar el borrado con un git rm
Despues de añadir cambios se recomiendo hacer git status para ver si vamos a hacer los cambios que queremos
En lugar de añadir las modificaciones podemos descartarlas y volver a la version oficial de la historia. Para descartar los cambios en el fichero prueba.txt
$ git checkout -- prueba.txt
Eso incluye recuperar el fichero si ha sido borrado.
Los cambios preparados se apuntan en la historia (local) haciendo
git commit -m 'comentario sobre que son los cambios'
Esto crea una nueva entrada en la historia de la copia local con ese mensaje. Para ver que esta en la historia puede usar git log
La historia de esta copia local se ve con
git log
Todos los comandos de git tienen una ayuda bastante extensa accesible mediante git help o solamente git.
Si queremos ayuda sobre git commit:
$ git help commit
O sobre git checkout:
$ git help checkout
En determinadas ocasiones, es interesante no añadir ciertos ficheros al repositorio. Los ejemplos más típicos son binarios, ficheros de configuración de datos, ficheros temporales, pruebas, etc.
Imaginemos la siguiente situación en nuestro repositorio local:
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# fichero_a_ignorar.txt
nothing added to commit but untracked files present (use "git add" to track)
Es decir, hemos creado un fichero fichero_a_ignorar.txt pero todavía no está añadido al repositorio. Como queremos que este fichero no se añada y se ignore, vamos a crear un fichero .gitignore (muy importante el punto al inicio del nombre del fichero) y en su interior vamos a escribir el nombre del fichero a ignorar.
Si lo hemos hecho correctamente, al volver a ejecutar git status, obtendremos:
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
nothing added to commit but untracked files present (use "git add" to track)
Es decir, hemos creado un nuevo fichero que se llama .gitignore y que todavía no hemos añadido al repositorio, pero hemos conseguido hacer que git ignore nuestro fichero objetivo. Algunos ejemplos típicos:
# Ignorar todos los ficheros acabados en ~ (temporales de kate)
*~
# Ignorar los ficheros con terminación swp (temporales de vim)
*.swp
# Ignorar todas las librerías compiladas en el directorio lib
/lib/*.o
Prueba a ignorar un fichero y si tienes problemas, avisa al profesor.
En la práctica anterior vimos como se puede enviar ficheros a un repositorio remoto gracias al comando git push. Ahora vamos a conseguir el efecto contrario, actualizar nuestro repositorio local con los datos que haya en el remoto.
Cuando una única persona trabaja sobre un repositorio, no es muy habitual realizar un git pull, pero cuando más de una lo hacen, es necesario para conseguir que todas las personas trabajen con el mismo código.
Para probar, es necesario añadir un fichero al repositorio, ejecutar git add y git commit para añadirlo localmente y hacer un git push para enviarlo al repositorio remoto. Al usar la misma cuenta, no habrá nada nuevo en bitbucket que no esté en el git local, por lo que para probar, será necesario ir al Bitbucket y crear un fichero desde la web. Una vez hecho esto, el otro compañero ejecutará el siguiente comando en el repositorio local:
$ git pull origin master
Si todo ha ido bien, ahora estarán los mismos ficheros en bitbucket y en el git local.