git status: Muestra el estado de actual de los archivos ubicados en el área de staging
22 |
git add nombreArhivo.extension: Agrega al área de staging el o los archivos.
23 |
git commit -m "Descripcion commit": Agrega los cambios a la BD del repositorio de git
24 |
git commit -am "Descripción commit": Nos ahorra el tener que utilizar git commit ., este comando solo es válido para archivos que ya existen en el repositorio, no afectará a archivos nuevos que no hayan sido agregados con add
25 |
git commit: Abrirá el editor Vim para poder agregar un comentario, siempre es obligatorio agregar un comentario para el commit. Para poder editar el comit usar "ESC i". Para guardar cambios ESC + SHIFT + Z Z
26 |
git log: Muestra el historial detallado con commit e id, de todos los commits en dicho repositorio
27 |
Git log repotenciado: Para tener una visualización más gráfica de tu historial en un repositorio, puedes usar el comando git log --all -decorate- oneline con esto, podrás ver el historial de cambios y ramas de forma más gráfica.
28 |
git log para buscar si deseas buscar palabras que hayas dejado en tus commits, puedes usar git log -S palabra, esto te retornará todos los commits que incluyan la palabra a buscar.
29 |
git diff: Permite ver las diferencias entre el staging y nuestro archivo en local. tiene las variaciones git diff id1 id2 donde se comparan dos versiones según los id del commit seleccionado. y git diff --stat donde ves las diferencias más resumidas.
30 |
git show: Se utiliza para ver el commit y la rama en el que te encuentras actualmente.
31 |
32 |
git grep: se usa para buscar texto en nuestros archivos del repositorio, puedes ver la cantidad de veces que se usa una palabra, incluso incluir expresiones regulares. Un ejemplo sería usar git gre -n palabra para ver en que archivos y que líneas esta la palabra "palabra" o git grep -c palabra para ver la cantidad de veces que se repite la palabra "palabra"
33 |
34 |
35 |
Comando de consola útiles
36 |
Esta sección es un extra, no tiene que ver directamente con Git, pero puede apoyar de una u otra manera tu repositorios.
37 |
38 |
Crear un alias: para resumir comandos que sean muy extensos, se puede utilizar el comando alias nombreNuevoComando="Comando a convertir" de esta manera, podemos usar una palabra más fácil de recordar para nosotros. Ejemplo: alias arbolito="git log --all --graph --decorate --oneline"
39 |
40 |
41 |
Comandos importantes
42 |
Estos comandos se separan ya que tienen funciones muy importantes.
43 |
44 |
git reset idCommit --hard/soft Este comando se encarga de regresar a una versión especificada. Se debe tener cuidado con este comando, ya que borrará absolutamente todos los cambios realizados despues de dicho commit. existen dos variastes para el mismo. --hard hará que regrese por completo todo a la versión elegida, perdiendo incluso, los cambios en staging. --soft cumple el mismo rol, pero mantiene los cambios en staging para su posterior commit.
45 |
git reset HEAD (Me encanta XD): Regresa todos los cambios en staging como unstaged. Es decir, revierte el git add.
46 |
git checkout idCommit archivo.extension: Obtiene la versión especificada de dicho archivo. PERO, no elimina sus versiones posteriores. La versión obtenida se tomará como untracked y podrá ser agregada al staging para realizar commit y crear una nueva versión.
47 |
git rm --cached: Elimina los archivos del área de Staging y del próximo commit pero los mantiene en nuestro disco duro.
48 |
git rm --force: Elimina los archivos del área de Staging y de nuestro disco duro.
49 |
Para visualizar todo el historial de git, aunque lo hayamos eliminado, usamos el comando git reflog con este, podemos ver las referencias de los commit e ir y venir entre las distintas versiones con git RESET
50 |
Recordatorio: ¡GIT RESET es una mala práctica! Solo usarlo en casos de extrema emergencia y como última opción.
51 |
52 |
53 |
54 |
Comandos en ramas
55 |
Estos son los comandos aplicados para manejarse entre ramas, crear nuevas ramas, etc.
56 |
57 |
git branch nameBranch: Se utiliza para crear una nueva rama.
58 |
git checkout nameBranch Se utiliza para dirigirse hacia la rama elegida.
59 |
git branch -D nombreRama se utiliza para eliminar ramas en git.
60 |
git push origin nombreRama se utiliza para enviar a un repositorio remoto la rama que hemos creado
61 |
git merge nombreRama: Este comando es súper importante, se utiliza cuando quieres unir los cambios entre 2 ramas. Cuando tienes los cambios de una nueva que creaste y ya les hiciste commit, puedes hacer un merge para fusionarlos con tu rama de master. El proceso puede ser MASTER -> RAMA_NUEVA o RAMA_NUEVA -> MASTER. Cuando quieres dejar todo en master para tener todo en la rama principal, debe usar la segunda opción.
62 |
63 |
Conflictos: En GIT, los conflictos aparecen cuando existen diferencias en las mismas líneas de código de los archivos. Ya sea que un compañero modifico la misma línea de un archivo CSS que tú y tienen diferentes cosas.
64 | Los conflictos son fáciles de solucionar y no debe generarte caos ni confusión. La consola de GIT te indicará el estatus del merge que intentaste realizar. Auto-merging archivo.extension indicará un merge correcto y CONFLICT (Content) archivo.extension indicará un conflicto.
65 |
66 |
67 |
68 | Al revisar nuestro archivo en conflicto, encontraremos algo muy peculiar en el, GIT nos muestra exactamente cual fue la línea en conflictos y cuales son las diferencias entre nuestra rama actual y la que queremos obtener. Así se debe ver al usar el bloc de notas:
69 |
70 |
71 |
72 | Debemos elegir entre el código que deseamos dejar en el repositorio y para esto, debemos comunicarnos con la persona que escribió el código (si es que estamos trabajando colaborativamente con alguien más) para decidir que código debe irse a la versión del merge. Posterior a este paso, se deben comentar la línea de "<<<<", las de "====" y las de ">>>>" junto con el código que no irá al repositorio.
73 |
74 | Se deben guardar los cambios en el archivo y realizar un nuevo git add . además de un git commit -m "Comentario relacionado con la solución del conflicto en el merge"
75 |
76 | Adicional: Si usas VSCode, podrás ver que el te da una sugerencia de que hacer con los cambios:
77 |
78 |
79 |
80 | Si eliges Accept Current Change estarás dejando los cambios de la rama actual, en cambio, si elgies Accept Incoming Change estarás obteniendo los cambios de la rama desde la cual estás obteniendo los cambios.
81 |
82 |
Publicar ramas en repositorio remotos: Si deseas que tu rama pueda ser usada/visualizada por otros desarrolladores en un repositorio remoto, debes usar el comando git push origin nombreRama
83 |
Otros errroes
84 |
Justo como se menciona arriba, una vez resuelves el conflicto puedes hacer el merge, pero suele pasar sobretodo a los que estamos empezando que se olvida añadir los archivos y hacerles commit por lo que Git nos arrojará este error:
85 |
86 |
Lo que sucede es que Git te dice que tienes que hacer commits antes de volver a realizar un merge (es decir asume que probablemente arreglaste los conflictos, sin embargo también te dice que puede seguir existiendo el conflicto, osea te da todas las opciones posibles), justo después de esto simplemente debes hacer commits a tus nuevos cambios que son la resolución de los conflictos, enviar, el problema debe estar resuelto y podrás hacer merge sin problema. Un error sencillo pero para los que recién empiezan pueden estar varios minutos tratando de resolverlo.
87 |
88 |
89 |
90 |
91 |
Repositorios remotos - GitHub
92 |
Conoceremos como poder conectar nuestro repositorio local con algún repositorio remoto, subir nuestros cambios a dicho repositorio, obtener los cambios desde el repositorio y mucho más.
93 |
Para este caso de prueba utilizaremos el repositorio remoto más conocido del mundo, GitHub.
94 |
95 |
Primero, debemos crearnos una cuenta en GitHub y crear un nuevo repositorio. Preferiblemente, debemos crear el archivo README ya que a través de el podremos indicarle a otros desarrolladores de que va nuestro código.
96 |
Luego de crear el repositorio, Github nos dará la url del mismo, esta la utilizaremos para agregar este origen remoto desde nuestro repositorio local. Se debe copiar la ruta HTTPS que github nos dió:
97 |
Usar el comando git remote add origin urlRepositorioRemoto con esto, estaremos agregando la referencia del repositorio remoto a nuestro repositorio en local. Posterior a esto, la consola de git no arrojará ningún mensaje, pero si usamos el comando git remove -v podremos visualizar el repositorio remoto al que hacemos referencia actualmente.
98 |
99 |
100 |
101 | Te dejo la url de este mismo repositorio para que puedas probar: https://github.com/avasquez-ve/gitCommands.git
102 |
Como ya tenemos la referencia del repositorio remoto, ahora debemos obtener la historia que se encuentre en dicho repositorio, esta acción se debe realizar siempre antes de enviar los cambios desde el repositorio local.
Si el repositorio remoto es diferente a nuestro repositorio local, es probable que Git nos de un warning con el mensaje "refusing to merge unrelated histories" esto quiere decir que no puede hacer la fusión debido a que las historias de los dos repositorios son diferentes. Para forzar esta acción y poder obtener la historia del repositorio remoto debemos usar el comando git pull origin master --allow-unrelated-histories para permitir unir ambas historias.
103 |
104 |
105 |
106 |
107 |
Con el comando ls -al podremos ver el archivo README creado desde GitHub. Y al ejecutar git log también veremos el commit hecho en GitHub para dicho archivo.
108 |
109 |
110 |
111 |
112 |
Ahora, para subir los cambios locales al repositorio, debemos usar el comando git push origin master, con esto, ya nuestros cambios locales estarán dentro del repositorio remoto. Recordar siempre que este comando lo debemos ejecutar desde la rama master para no generar conflictos.
113 |
114 |
115 |
116 |
Así quedó nuestro repositorio remoto en GitHub luego de agregar los cambios desde el repositorio local
117 |
118 |
119 |
120 |
121 |
122 |
Configurar tus llaves SSH en local
123 |
Aprenderemos como usar las llaves SSH para conectarnos a GitHub usando SSH y dejar a un lado HTTPS
124 |
Para hacer nuestra conexión aún más segura, podemos usar llaves encriptadas, con las cuales enviamos nuestros datos cifrados. Dichos datos solo podrán ser decifrados con una llave pública que compartiremos con GitHub.
125 |
126 |
Primer paso: Generar las llaves SSH con el comando ssh-keygen -t rsa -b 4096 -C "tu@email.com" debemos usar el mismo email que usamos para Github. Tomar en cuenta que luego de apretar enter, nos va a sugerir agregarle una contraseña a dicha llave para hacerla aún más segura. Este paso es opcional, si no queremos agregarle una contraseña solo aprietas ENTER.
127 |
Las llaves se guardaran en una carpeta oculta llamada .ssh donde tendremos la llave pública id_rsa.pub y la privada id_rsa NOTA: La llave privada jamás se debe compartir con nadie ni con ningún otro dispositivo.
128 |
Segundo paso: para terminar de configurar las claves, debemos comprobar que el servidor se encuentre activo, para esto usar el comando eval $(ssh-agent -s) lo cual nos debería retornar un mensaje Agent pid numeroAleatorio
129 |
Tercer y último paso: ahora, solo debemos agregar al servidor nuestra llave privada, para esto, usar el comando ssh-add ruta-donde-guardaste-tu-llave-privada Y listo, ya tendremos configurada nuestra llave privada para poder conectarnos a través de SSH con GitHub
130 |
131 |
La documentación oficial de GitHub para configurar las llaves SSH para Windows, Linux y Mac, se encuentra en:
Luego de haber creado y configurado nuestra llave privada. Debemos configurar nuestra llave pública (la única que podemos compartir) con Github. Es importante tener en cuenta que debemos realizar los pasos anteriores, de lo contrario, no podremos continuar con este paso.
135 |
136 |
Como primer paso: debemos agregar nuestra llave pública a nuestra cuenta de Github. Para eso debemos copiar el contenido de nuestra llave publica, ubicada en el archivo id_rsa.pub
137 |
El segundo paso es: Ingresar en nuestra cuenta de Github y dirigirnos a la configuración y posteriormente a la gestion de KEYS SSH url: https://github.com/settings/keys Debemos hacer click en New SSH Key y luego agregar como título, el pc que tendrá asignado dicha key publica, esto es para poder identificarlo, ya que podemos tener varios equipos conectados por SSH a nuestros repositorios. Al finalizar, hacer click en Add SSH KEY
138 |
Ahora podremos ver que nuestra key SSH se agregó correctamente
139 |
140 |
Como siguiente paso, debemos configurar nuestro repositorio local para dejar de usar HTTPS y empezar a usar SSH con nuestras nuevas keys. Para esto, debemos ir a nuestro repositorio y ejecutar el comando git remote set-url origin url-ssh-del-repositorio-en-github Con esto estaremos cambiando la url del repositorio en github. Podemos comprobar la nueva url usando git remove -v
141 |
Ahora puedes hacer un git pull origin master confirmar los mensajes, realizar cambios en tu repositorio local y hacer un git push origin master
142 |
143 |
144 |
Tags y versiones en Git y GitHub
145 |
Los tags nos permiten asignar versiones a los commits con cambios más importantes o significativos en nuestro proyecto. A continuación, se presentan los comandos para trabajar con las etiquetas:
146 |
147 |
Crear un tag: antes de crear un tag se debe elegir el commit el cual queremos identificar, para esto, podemos hacer un:
git log --all --graph --decorate --oneline o un git log --all --oneline y copiar el id del commit.
Se usan los comandos anteriores para poder obtener el id más corto. Luego, ejecutamos el comando para crear el tag git tag -a nombreDelTag -m "Comentario asociado al tag" idDelCommit
148 |
Visualizar tags creados: Para visualizar los tags que tenemos creados podemos usar los comandos git tag o git show-ref --tags con el primero, solo veremos el nombre del tag y con el segundo, podremos ver el commit generado al crear el tag y la ubicacion.
149 |
Enviar tags a un repositorio remoto: Para publicar nuestros tags se debe usar el comando git push origin --tags si te das cuenta, se hace diferente a publicar un commit común.
150 |
Eliminar tags: Los tags son publicados en Github como releases, versiones estables de nuestro código que deberían funcionar sin problemas. Si llegas a publicar un tag por equivocación, puedes borrarlo con los siguientes dos comandos:
git tag -d nombreDelTag con esto estaremos borrando el tag en el repositorio local. Para eliminarlo del repositorio remoto se debe usar git push origin :refs/tags/nombreDelTag
151 |
152 |
153 |
Usando Rebase
154 |
Rebase se utiliza para unir los cambios que tengamos en una rama con nuestra rama master y no dejar rastros de la existencia de dicha rama creada.
155 |
El rebase es útil, por ejemplo, si estamos realizando arreglos de un bug y no se desean mostrar estos cambios como tomados de una rama, si no como parte del flujo normal de la aplicación.
156 |
Rebase se encarga de ajustar los cambios al momento en que se realizaron y hacer un merge desde el primer commit, no desde el último (como funciona normalmente un flujo en git)
157 |
158 |
Para hacer un rebase, primero debemos crear una nueva rama, posicionarnos en dicha rama con git checkout y realizar los cambios.
159 |
Luego de tener nuestros cambios, debemos ejecutar el comando git rebase master desde nuestra rama de cambios es importante que git rebase se haga desde la rama con los cambios primero
160 |
Con esto, ya tendremos unidas las historias de master con nuestra nueva rama. Posteior a esto se debe realizar checkout a mastery ejecutar el rebase desde master apuntando a nuestra rama de cambios git rebase nombreRamaCambios
161 |
Esto lo que hará es integrar master con nuestra rama de cambios y luego pasarla a master nuevamente con todos los cambios incluidos, como un merge.
162 |
Nota: Usar rebase es una mala práctica, ya que no tenemos historia de lo que sucede, no se sabe quien hizo que cambios y en ocasiones, si master avanzó mucho, se pueden generar muchos conflictos.
163 |
164 |
165 |
Usando Git Stash
166 |
Git stash es muy útil cuando tienes cambios que no deseas realizarle commits aún, o para realizar pruebas, experimentos que no requieran o no quieras crear una rama para poder visualizarlos
167 |
El stash es una forma de almacenar tus cambios pendientes para luego poder obtenerlos y hacerles commit, incluso puedes crear una rama con esos cambios pendientes, hacerle commit en la nueva rama y luego realizar un merge en master.
168 |
Pasos para usar Stash
169 |
170 |
Primero, puedes realizar cualquier cambio en un documento y guardar los cambios.
171 |
Luego, usar el comando git stash, esto guardará tus cambios pendientes en un listado de WIP (Work in Process).
172 |
El listado lo puedes consultar usando git stash list
173 |
Para obtener los cambios pendientes, debes usar el comando git stash pop ¡OJO! esto lo debes realizar en la misma rama que estabas creando los cambios, ya que si haces pop en una rama diferente, puedes generar un conflicto.
174 |
Una alternativa para guardar tus cambios pendientes y visualizarlos sin tocar la rama master, es usa el comando git stash branch nombreRama esto creará automáticamente una nueva rama con los cambios que estaban en el stash
175 |
Eliminar un stash si deseas eliminar un stash, puedes usar el comando git stash drop esto eliminará el stash que tengas y dejará la versión original.
176 |
177 |
178 |
Git Clean
179 |
Este comando es utilizado para eliminar archivos que no forman parte de nuestro directorio de trabajo, archivos como .logs, resultados de una compilación, etc.
180 |
181 |
Para eliminar dichos archivos podemos probar creando copias de archivos existentes en nuestro repositorio
182 |
Luego, ejecutar git clean --dry-run esto se usa para verificar que eliminará git clean
183 |
Al confirmar lo que borrará, ejecutamos git clean -f con esto, ya estaremos borrando dichos archivos
184 |
Nota: Git no eliminará los archivos que se encuentren dentro del .gitignore, tampoco eliminará los archivos que tengan el mismo nombre, asi esten en directorios distintos.
185 |
186 |
187 |
Git cherry pick
188 |
Existe un mundo alternativo en el cual vamos avanzando en una rama pero necesitamos en master uno de esos avances de la rama, para eso utilizamos el comando git cherry-pick IDCommit.
189 |
cherry-pick es una mala práctica porque significa que estamos reconstruyendo la historia.
190 |
191 |
Para usar cherry pick, debes ejecutar el comando git cherry-pick IDCommit desde la rama donde deseas traer los cambios de dicho commit.
192 |
Es posible que genere conflictos este comando, así que debes tenerlo en cuenta para poder hacer el cherry pick.
193 |
194 |
195 |
Git amend
196 |
A veces hacemos un commit, pero resulta que no queríamos mandarlo porque faltaba algo más.
197 |
Amend remienda nuestro error y los cambios que hicimos nos los permite agregar al commit más reciente.
198 |
199 |
Para esto, se debe hacer los cambios necesario, hacer un git add y posterior a esto, ejecutar el comando git commit --amend
200 |
201 |
202 |
Magia para desarolladores
203 |
Si has llegado hasta aquí y ya manejas de memoria los principales comandos de git, los comandos para las ramas,sabes hacer un merge sin caer en la locura y trabajar con repositorios remotos.
204 |
Te dejo un buen comando de git que te ayudará a ver fácilmente tu historial de commits.
205 |
¡OJO! haz clic en el siguiente enlace solo si REALMENTE manejas y comprendes los comandos anteriores y el flujo de Git, de lo contrario, REGRESA OTRO DÍA 👺
11 | Comandos de GitHub
12 | 
67 | 
71 | 
79 | 
86 | 
100 | 
105 | 
110 | 
115 | 
119 | 
