Armé este repo para explicar qué onda Git, para qué sirve, cómo laburo yo e inclusive abordamos conceptos avanzados a medida que vamos avanzando.
La idea es que si no cazás una de Git, con esto salgas jugando y tengas fundamentos solidos.
Fuentes:
Utilice el libro de Pro Git y la documentacion oficial de Git para poder armar este tutorial. Recomiendo que si queres seguir estudiando mas a fondo sobre Git y Github, le pegues un ojo a estas fuentes que son buenisimas.
Si tienen sugerencias de como mejorar este README ayudaria un monton. Una estrella en el repo se agradece 😉
Imaginate que estás codeando sin Git, si te mandás una moco, perdés todo o terminás con archivos tipo: app_FINAL_esta_si_v3_PROMETO_(1).zip. Lo tenes que pedir.
Git es como el sistema de checkpoints de un juegito:
- Sirve para: Sacar "fotos" (snapshots) del proyecto.
- Permite: Viajar en el tiempo si rompes algo (pasa seguido) y laburar con otros sin que se pisen los cambios.
(antes de poder usarlo lo vas a tener que instalar, googlea no es dificil)
--> Arrancas git en tu proyecto con git init
Antes de arrancar a usarlo tenes que conocer los tres estados en git:
-
Working Directory: Es la carpeta en tu computadora donde editas, creas o borras archivos. Cuando cambias un archivo pero todavia no le avisaste a Git que lo tenga en cuenta, se encuentra en este estado ("modificado" o modified).
-
Staging Area: Es una carpeta invisible donde colocas los cambios que quieres incluir en el próximo commit. Podes stagear tus cambios usando
git add, y para ver que cambios estan stageados o faltan por stagear usasgit status. -
Git Directory: Es donde Git almacena la base de datos de los cambios (el historial). Cuando haces
git commit, los archivos preparados pasan del staging area a guardarse definitivamente como una foto (snapshot).En un toque vamos a ver los comandos en profundidad
(lo que esta con signo de exclamacion lo vamos a volver a ver mas adelante, no te hagas la cabeza si no lo cazas de una)
- Local: Tu compu.
- Repo (Repositorio): Es la carpeta del proyecto que Git está vigilando.
- Commit (
*): Una foto de tus archivos en un momento exacto. Cada commit se le tiene que poner un nombre para saber qué corno hiceste. - !Remote (u "Origin"): Es la copia que vive en la nube.
- !Rama (Branch): Un camino aparte, como una difurcacion del codigo. Te poes abrir una rama para probar algo sin romper la versión principal que ya funciona.
- !HEAD: Es un puntero que indica la rama o commit actual en el que estás trabajando. Sirve para saber dónde estas en el historial, y usualmente apunta al último commit realizado en tu rama activa.
Antes de poder sacarle una "foto" a tu projecto, tenes que hacer esto.
git add <archivo>(guardas los archivos): Acá elegís qué archivos querés guardar.- Estado: Staging. Los archivos están "en espera".
Tip
Podes usar "git add ." en lugar del nombre de los archivos para guardar todos los archivos modificados del repo
Y si te arrepentis podes tirar git reset para sacar los archivos del staging area
git commit -m "descripción": Acá confirmás que lo que está guardado, le sacas la "foto".- Estado: Committed. El cambio ya es parte de la historia oficial en tu PC.
Y ahora tenes tu nueva "foto" (correctamente llamado commit) de tu proyecto
Note
Si queres volver a algun commit antiguo podes usar git log --oneline para ver la lista de commits
Y despues git reset --hard <commit-hash> para hacer el rollback hacia ese commit
| Aspecto | Git | GitHub |
|---|---|---|
| Qué es | Herramienta de control de versiones | Plataforma para alojar repositorios Git |
| Dónde funciona | Local (tu computadora) | Remoto (en la nube) |
| Para qué sirve | Gestionar cambios y versiones | Compartir y colaborar en proyectos |
| Instalación | En tu computadora personal. | No requiere (se usa en el navegador). |
Note
Para poder subir tu proyecto a github tenes que configurar tu terminal para que tengas acceso a tu cuenta de GitHub
Si estas en windows podes usar winget para instalar el CLI de Github
Una vez instalado podes hacer gh auth login y seguir los pasos, eligiendo HTTPS como protocolo y logeandote desde el browser.
Note
Si preferis una opcion mas segura podes optar por configurarlo con una clave de ssh (este paso a paso funciona para linux/wsl pero lo podes activar en cualquier OS).
Generala con este comando ssh-keygen -t ed25519 -C "tu-mail@tu-mail.com"
Arrancas tu agente de ssh y lo agregas con eval "$(ssh-agent -s)" y despues ssh-add ~/.ssh/id_ed25519
Una vez que hiciste eso, copia tu clave publica con cat ~/.ssh/id_ed25519.pub y agregala en tus Settings de GitHub
-
Para poder subir tu repo a GitHub tenes que Crear un repositorio en la web y linkiarlo a tu repo local con: ->
git remote add origin "el link de tu origen" -
Una vez hiciste eso poder pushear tus cambios commiteados al remote haciendo:
git push origin main
- Esto sube tus cambios a la branch main (en un toque vemos que es una branch)
Important
El verdadero poder de Git entra cuando lo laburas junto a GitHub (Hay otras alternativas como GitLab, Bitbucket entre otros). Ademas es fundamental cuando lo laburas con otros en tu equipo
| Comando | Qué hace? | Toca mis archivos? |
|---|---|---|
git fetch |
Se trae las novedades del origin pero las guarda en una carpeta "invisible". | NO modifica tus archivos. Es super seguro. |
git merge |
Agarra los cambios de otra rama y los pega en la mía a la fuerza. | SÍ. Crea un commit de unión que a veces ensucia el historial. |
git pull |
Es el vago: hace un fetch y un merge todo de una. |
SÍ. Es cómodo pero te puede saltar un quilombo de golpe. |
git rebase |
Mueve mis cambios para que parezca que los hice "después" de lo último del servidor. | SÍ. Deja el historial prolijo, como una línea recta. |
Git muestra el historial como un grafo (un mapa de estaciones).
(Lo último que se hizo)
* 7a2b3c4 (HEAD -> main) El "Merge": acá se une todo.
|\
| * 5e6f7g8 (rama-nueva) Antes de mergiar nos tenemos que traer los ultimos cambios de main
| * 3h4i5j6 cambiamos los colores a un botón.
| |
* 1k2l3m4 Un compañero arregló un bug en la rama principal (main o master tipicamente).
| |
| |
|/
* 9n0o1p2 El commit base.
(El pasado)
¿Cómo se lee?
- De abajo para arriba: Lo viejo abajo, lo nuevo arriba.
- Las ramitas (
|/): Alguien se abrió para hacer algo distinto. - Los cruces (
|\): Volvimos a juntar los caminos.
Algo que te puede pasar es que estes laburando en una funcionalidad, con todo el código por la mitad y de repente te tenes que poner a laburar en otra cosa mas urgente
- No querés hacer un commit porque el código está roto o incompleto. Ahí es donde entra el
git stash. Hacés lo urgente, y después seguis con lo que estabas laburando.
-
git stash(Ogit stash save "mensaje")- Agarrás todos tus cambios que no guardaste (los que están en
addo sueltos) y los guardás en una pila secreta. - Tu rama queda limpia, como si no hubieras tocado nada. Ahora sí podés cambiar de rama y arreglar el bug urgente.
- Agarrás todos tus cambios que no guardaste (los que están en
-
git stash list- Te muestra todos los stash que hiciste.
-
git stash pop- Es el que más vas a usar. Saca lo último que guardaste en el stash y lo vuelve a poner en tu código. Ojo: una vez que lo hacés, lo borra de la lista.
-
git stash apply- Igual que el
pop, pero deja una copia en la lista por las dudas.
- Igual que el
-
git stash drop- Si al final decidiste que lo que habías guardado en el stash era malardo y no lo querés más, con esto lo borrás al carajo.
- Estás programando un botón:
index.htmlmodificado. - "Hay un error en el formulario de login!": No podés cambiar de rama porque Git no te deja si tenés cambios sin guardar.
- Tirás un
git stash. - Te vas a la rama del error (o creas una para el hotfix), lo arreglás, hacés el push.
- Volvés a tu rama y tirás
git stash pop. - ¡Magia! El código del botón vuelve a aparecer y seguís como si nada.
Para que el historial no sea un bardo y quede cheto, yo sigo este orden:
git add .(Meto los cambios en el stage).git commit -m "feat: agregué el login"
git fetch origin(Me bajo lo que hicieron los pibes mientras yo estaba en la mía).git diff HEAD..origin/main(Clave: comparo mi código con el de ellos. Si veo que tocamos lo mismo, ya me mentalizo que se viene un conflicto).git rebase origin/main(Git saca mis commits, pone lo nuevo de los demás y después pega mis cambios arriba. Queda una línea recta hermosa!)
Si el rebase se traba:
- Abro el archivo que llora y elijo qué código queda.
git add <archivo_arreglado>.git rebase --continue(Listo! Seguimos camino). Si se fue todo al pasto y no sabés qué hiciste:git rebase --aborty lo ves despues cuando te de el bocho.
git push origin mi-rama
Caution
NUNCA hagas rebase en ramas publicas. El rebase "reescribe la historia". Si vos ya subiste algo y después le hacés un rebase, le vas a romper la cabeza a tus compañeros cuando quieran bajar tus cambios. Hacelo siempre antes del push, en la intimidad de tu local en una branch que solo estas laburando vos.
| Si queres... | Usas... |
|---|---|
| Ver el mapa de ramas de colores | git log --oneline --graph --all |
| Ver qué esta guardado en el stage | git status |
| Comparar el laburo con el del origin | git diff HEAD..origin/main |
| *Muestra el historial de las acciones de un repo | git reflog |
-
El reset "soft" mueve tu HEAD a el commit que le indiques. Este mantiene los archivos modificados desde que se hizo el commit, es decir, los cambios posteriores
-
El reset "hard" este como el anterior, mueve tu HEAD hacia el commit que le indiques. La diferencia es que este borra todos los commits posteriores que se han hecho desde el commit que le indicaste
Podes usarlos utilizando
git reset --soft HEAD~2ogit reset --hard HEAD~2dependiendo de tu caso concreto.
(en este ejemplo estamos volviendo hacia atras 2 commits detras del HEAD "~2")
- Este agrega un commit a el historial de commits que revierte el ultimo commit que se haya hecho
Podes usarlo utilizando
git revert (commit).
- Crea un nuevo commit con los cambios que el commit indicado introdujo. Para evitar commits vacios, el cherry pick aplica por defecto los cambios que la rama no tiene
Podes usarlo utilizando
git cherry-pick (commit).
Poné a prueba lo que aprendiste antes de terminar con el tutorial. Hace click en cada pregunta para ver la respuesta!
1. Si modifiqué un archivo pero todavía no hice "git add", en qué estado se encuentra?
🟢 Se encuentra en el Working Directory (estado "modified"). Git sabe que cambió, pero aún no está preparado para la foto. 🟢2. Cuál es la diferencia principal entre "git pull" y "git fetch"?
🟢git fetch solo descarga las novedades a una carpeta invisible sin tocar tus archivos. git pull hace el fetch y además intenta pegarlos (merge) en tu código de una. 🟢
3. Por qué se dice que el "rebase" reescribe la historia?
🟢 Porque el rebase agarra tus commits, los "despega" y los vuelve a "pegar" encima de lo nuevo. Esto cambia los IDs (hashes) de los commits, por eso nunca hay que hacerlo en ramas donde laburan otros. 🟢4. Tengo código a medio terminar y surge una urgencia en otra rama. Qué comando uso?
🟢 Usasgit stash para guardar tus cambios en una "pila secreta" y dejar la rama limpia para moverte. 🟢
5. Qué diferencia hay entre un "reset --hard" y un "reset --soft"?
🟢 El--soft te vuelve atrás en el tiempo pero te deja los archivos como los tenías (no perdés el laburo). El --hard borra todo y deja la carpeta exactamente como estaba en ese commit antiguo. 🟢