1. Inicio del repositorio

git init

2. Agrega el archivo o los archivos al repositorio

git add file.txt file_v1.txt

3. Envia el archivo al repositorio local, control de versiones

git commit -m "comentario"

4. Guardar todos los archivos con cambios en staging area

git add .

5. Guardo los archivos y hago commit, siempre que los archivos ya existan, no agrega los arvhicos nuevos

git commit -am "comentario"

6. Status de mi base de datos local

git status 

7. Cambios historicos hechos

git show

8. Historia de un archivo

git log file.txt 

9. Enviar cambios al repositorio remoto

git push 

10. Traer los cambios de un repositorio remoto

git pull

1. Cambios sobre un archivo

git show archivo.txt

2. Ver los cambios entre 2 commits, commit2 debe ser el mas reciente, para leer de mejor manera los cambios

git diff commit1 commit2

1. Volver a una version anterior, todos los cambios

git reset COMMIT --hard

2. Volver a la version anterior, pero lo que esta en staging, sigue en staging, es decir lo que esta en git add se mantiene

git reset COMMIT --soft

3. Cambios especificos en los archivos

git log --stat 

4. Volver a un commit especifico de un archivo

git checkout COMMIT archivo.txt 

5. Volver a la version mas actualizada

git checkout master archivo.txt 

1. Git rm elimina archivos de Git sin eliminar su historia, lo podemos recuperar volviendo en el tiempo

git rm --cached // elimina del area de staging y del proximo commit 
git rm --force // elimina el archivo de git y del disco duro 

2. Git reset permite volver al pasado, sin la posibilidad de volver al futuro, borra la historia y no hay vuelta atras

git reset --soft // borramos todo el historial y registros de Git, pero guardamos los cambios que tenemos en staging 
git reset --hard // borra todo, borra el historial y registro de Git, incluido staging 
git reset HEAD // saca los archivos de staging, para no enviarlos en el commit, se pueden volver a agregar con git add .

1. Tara traer los cambios del repositorio remoto al local

git fetch 

2. Para copiar los cambios del repositorio local al directorio de trabajo

git merge // se hace un git fetch, seguido de git merge 

3. Para traer los cambios del repositorios remotro y al directorio con un solo comando

git pull

1. El merge se realiza desde la rama que uno se traera los cambios, no de donde estan los cambios.

git merge branch_donde_estan_los_cambios

1. Agregar un rpositorio remoto al repositorio local

git remote add origin URL_REPO

2. Revisar las versiones de origin y main

git remote -v 

3. Antes de enviar los cambios al repositorio remoto, hay que hacer un merge, por tanto hay que hacer un:

git pull origin main --allow-unrelated-histories 

4. Ahora podemos subir los cambios

git pull origin main 

1. Ver toda la historia de mi proyecto, con lineas de ramas y commits

git log --all --graph --decorate --oneline

1.1 Crear un alias, con el comando mas cool para ver la historia del repositorio

alias arbolito="git log --all --graph --decorate --oneline"

2. Crear tag

git tag -a v0.1 -m "resultado de las primeras clases del curso" 6f4e648

3. Ver tags creados

git tag

4. Obtener el hash y el tag asociado, el uso del tag es que siempre este en el servidor remoto, para que los coladores pueden ver en que estado esta la version.

git show-ref --tags

5. Publicar el tag en el repositorio remoto

git push origin --tags 

6. Borrar un tag

git tag -d dormido

1. Muestras las ramas

git show-branch 
git show-branch --all

2. Ver desde una app la historia del repositorio

gitk 

1. Primero ingregar a la rama base para el merge (la rama base, se trae los cambios de la rama con cambios y se hace el merge y se sube)

git checkout main

2. Traigo los cambios del repositorio en internet a local

git pull origin main

3. Traigo los cambios desde la rama a la rama

git merge header

4. Subo los cambios

git push origin main

El pull request lo revisa el lider del equipo o el devops (generalmente, en casos excepcionales el lider de desarrollo).

Es una caracter’stica œnica de GitHub en la que se crea una copia exacta del estado actual de un repositorio directamente en GitHub, Žste repositorio podr‡ servir como otro origen y se podr‡ clonar (como cualquier otro repositorio), en pocas palabras, lo podremos utilizar como un git cualquiera . Un fork es como una bifurcaci—n del repositorio completo, tiene una historia en comœn, pero de repente se bifurca y pueden variar los cambios, ya que ambos proyectos podr‡n ser modificados en paralelo y para estar al d’a un colaborador tendr‡ que estar actualizando su fork con la informaci—n del original. . Al hacer un fork de un poryecto en GitHub, te conviertes en due–@ del repositorio fork, puedes trabajar en Žste con todos los permisos, pero es un repositorio completamente diferente que el original, teniendo alguna historia en comœn. . Los forks son importantes porque es la manera en la que funciona el open source, ya que, una persona puede no ser colaborador de un proyecto, pero puede contribu’r al mismo, haciendo mejor software que pueda ser utilizado por cualquiera. . Al hacer un fork, GitHub sabe que se hizo el fork del proyecto, por lo que se le permite al colaborador hacer pull request desde su repositorio propio. Trabajando con m‡s de 1 repositorio remoto Cuando trabajas en un proyecto que existe en diferentes repositorios remotos (normalmente a causa de un fork) es muy probable que desees poder trabajar con ambos repositorios, para Žsto puedes crear un remoto adicional desde consola.

git remote add <nombre_del_remoto> <url_del_remoto> 
git remote upstream https://github.com/freddier/hyperblog

Al crear un remoto adicional podremos, hacer pull desde el nuevo origen (en caso de tener permisos podremos hacer fetch y push)

git pull <remoto> <rama>
git pull upstream master

ƒste pull nos traer‡ los cambios del remoto, por lo que se estar‡ al d’a en el proyecto, el flujo de trabajo cambia, en adelante se estar‡ trabajando haciendo pull desde el upstream y push al origin para pasar a hacer pull request.

git pull upstream master
git push origin master

Solo para los repositorios locales, mala practica para los repositorios remotos.

1. Desde el branch con todos los cambios, se hace el rebase. Cambia la historia del branch tomando el ultimo commit de master y le pega los cambios del repositorio local, por eso es una mala practica.

git rebase master

2. Posteriormente, hay que hacer un rebase desde master, sino se hacer se genera un error super raro (confiemos en Freddy)

git rebase experimento

Es para guardar cambios en memoria para usarlos despues.

1. Guarda las modificaciones

git stash 

2. Regresa a las modificaciones

git stash pop 

3. Ver la lista de stash

git stash list

4. Mover el stash a un branch

git stash branch english-version

5. Borrar el stash guardado sin commitear todavia

git stash drop

1. Para limpiar el espacio de trabajo es necesario hacer primero una revision de lo que se va a borrar.

git clean --dry-run

2. Para ejecutar el borrado usamos clean, pero ojo, a Git no le interesan las carpetas, solo los achivos que no esten en el historial.

git clean -f

1. Para traer un commit desde otra rama es necesario ingresdar a la rama que se usara vcomo base y ejecutar el siguiente comando

git cherry-pick hash

1. Para recontruir un commit, es necesario tener un commit y agregar cambios a ese commit (sin hacer otro commit).

git commit --amend 

1. Relog te muestra todo el log, incluso de elementos elimiunados.

git relog

2. Reset te deja el workplace con la historia del cierto Header o commit.

SOFT

git reset HEAD@{4}

HARD

git reset --HARD c894650

1. Para buscar en archivos, hay que estar en la rama correcta y usar grep.

git grep <a buscar >

2. Buscar conociendo la linea exacta.

git grep -n <a buscar>

3. Cantidad de veces que esta una palabra en los archivos.

git grep -c <a buscar>

4. Buscar en los commits.

git log -S "cabecera"

1. Ver los commits con los comentatios como principal

git shortlog

2. Todas las personas que han hecho commits, incluso lo que han eliminado.

git shortlog -sn --all

3. Todas las personas que han hecho commits, omitiendo los merge.

git shortlog -sn --all --no-merges

4. Generar alias en mi configuracion de Git

git config --global alias,stats "shortlog -sn --all --no-merges"
git stats 

5. Quien hizo que?

git blame -c archivo 

6. Abrir el manual de cierto comando.

git blame --help

7. Ver los branch remotos

git branch -r