Git es una herramienta de sistema de control de versiones (SCV). Básicamente, te permite gestionar la historia de cambios de un proyecto, facilitando la cooperación entre desarrolladores. En particular, git es distribuido, lo que significa que cada colaborador tiene una copia íntegra del repositorio original localmente, a diferencia de los SCV centralizados que requieren de una conexión a internet para realizar cambios.
Github, por otra parte, es un servicio remoto para almacenar repositorios git
. Existen numerosas
alternativas como Gitlab, Bitbucket, Notabug, pero todavía Github sigue siendo el servicio más utilizado.
De hecho, podríamos describirlo como "la red social de los programadores".
Si bien es posible utilizar la interfaz de usuario de Github para compartir nuestro
trabajo, es preferible acostumbrarse cuanto antes a trabajar con git
desde la línea de
comandos.
En primer lugar, tienes que configurar git
para que guarde tu nombre e email.
Así,
$ git config --global user.name "Tu nombre"
$ git config --global user.email tucorreo@example.com
Empecemos realizando una copia del repositorio en tu ordenador.
El comando git clone
se encarga de ello:
$ git clone https://github.com/DGIIMUnderground/DGIIM1
Este comando te crea una carpeta en el directorio donde es ejecutado con el repositorio íntegro. Puedes utilizar la dirección http, con el inconveniente de que te preguntará por tu usuario y contraseña cada vez que quieras realizar un cambio en el repositorio. Para evitar esto, puedes configurar una clave ssh.
Una vez dentro de esta carpeta "DGIIM1" (mediante la orden cd DGIIM1
) ya podrás
ejecutar los siguientes comandos:
git status
git pull origin master
- Por fin puedes realizar tus cambios
git add
git commit [-am '<titulo>']
git push origin master
Este comando no es necesario ejecutarlo en un momento particular pero, créeme,
es de gran ayuda. Te aporta información sobre el estado del repositorio. Por ello,
ejecútalo después de cada orden que realices con git
. Es útil incluso si no entiendes
esa información porque... ¡puedes copiar y pegarla en google!
Sin embargo, los siguientes comandos deberán realizarse ordenadamente, y constituirán la base para contribuir a un proyecto.
$ git pull <remote <branch-name>
<remote>
: Es la dirección remota del repositorio, en nuestro caso la direcciónorigin
apunta a nuestro sitio en los servidores de Github.<branch-name>
: El nombre de la rama. La predeterminada a utilizar suele sermaster
.
Por tanto, la orden que ejecutaremos será git pull origin master
.
Este comando actualiza tu repositorio local con el remoto. Es decir, "descarga" el trabajo realizado por los otros. Es importante ejecutarlo siempre antes de empezar a realizar cambios, para evitar las situaciones en las que dos personas estén modificando el mismo archivo.
De todos modos, si en algún caso se te olvida, git
no te permitirá sobreescribir el
repositorio, y te informará de que tienes que hacer git pull
antes!
Esta es la fase donde realizas el trabajo real. Es decir, creas archivos, modificas otros... En resumen, pasas un rato de diversión.
$ git add <ruta-archivo>
(Así, git add .
añadiría todo el directorio actual al repositorio.)
Este comando añade a la fase de staging
, que podríamos llamar como
almacenamiento o pre-commit. Para entendernos, es como una fase de preparación
del commit. Primero preparas todo lo que quieres cambiar (git add
), y luego
lo fotografías con (git commit
).
$ git commit [-a -m "Título"]
Este comando registra los cambios en la historia del repositorio. Es recomendable
ejecutar git status
antes de hacer ningún commit. Así puedes comprobar que archivos
están añadidos a la fase de preparación del commit (de color verde), antes de registrar
los cambios definitivamente. En realidad, no hay nada definitivo en git, pues es siempre
posible modificar la historia. Pero si trabajas en equipo y has subido cambios erróneos,
no son para nada recomendable comandos arcanos como git rebase
o git commit --amend
.
El significado del corchete en la orden es que -a -m "<Título>"
son
parámetros opcionales.
Por ejemplo:
-
git commit
: Llamará a tu editor por defecto para escribir el mensaje de commit. Deberás escribir en la primera línea, citando a Blanca "un Título exclarecedor sin aaaaa". (Recuerda que utilizamos un sistema de gestión de versiones que es git para controlar mejor los cambios que vamos realizando). -
git commit -a
: Sera un atajo que realizarágit add .
ygit commit
en el mismo comando. Úsalo sólo si sabes que todo lo que puede añadirse al repositorio, quieres que sea añadido. -
git commit -m "Mensaje del commit"
: Registra el commit con una línea de mensaje (que se correspondería con la primera línea del archivo que se editaría con la ordengit commit
.). Recuerda escribir un mensaje de commit adecuado.
Consejos genéricos:
-
Utiliza
git commit -m
: A no ser que quieras escribir descripciones al estilo Blanca congit commit
, no suele ser necesario añadir otra cosa más que el título (si este está suficientemente claro). -
Debes intentar que un commit reúna en un mensaje cambios relacionados. Ejemplos de títulos pasables son: "Corregir erratas" "Actualizar ejercicio tal" "Ejercicio x portado a latex".
-
No valen mensajes como: "mejorando cosas" "ejercicios" "bomba nuclear". Los dos primeros por ser ambiguos y el siguiente por absurdo.
- git push
$ git push <remote> <branch-name>
(Normalmente git push origin master
)
Una vez tienes tus cambios registrados en tu ordenador es hora de compartirlos con los demás.
Si te fijas la orden es muy parecida a git pull. Y de hecho
y tienen el mismo significado que en esta. Sin embargo,
el objetivo de git push
es justo el contrario, es decir, subir tus cambios
locales al repositorio remoto.
Recomendación: intenta ejecutar git push origin master
cada vez que hayas
hecho un commit para evitar conflictos.
git branch
git checkout <rama>
Más información en git-scm