cheat_sheet_chuleta_de_git_para_sysadmins
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
cheat_sheet_chuleta_de_git_para_sysadmins [2021/11/23 11:27] – [Cambios en local] busindre | cheat_sheet_chuleta_de_git_para_sysadmins [2022/07/26 12:09] – busindre | ||
---|---|---|---|
Line 62: | Line 62: | ||
git log # Muestra información de todos los commits. | git log # Muestra información de todos los commits. | ||
git shortlog | git shortlog | ||
+ | |||
+ | # Muestra información de todos los commits en formato agradable a la vista. | ||
+ | git log --graph --pretty=format:' | ||
+ | |||
git log -p < | git log -p < | ||
git log --since=' | git log --since=' | ||
git blame < | git blame < | ||
+ | |||
+ | |||
+ | git log --name-status -2 # Muestra los ficheros modificados en los dos últimos commits. Útil para saber qué ficheros se ha modificado después de hacer un git pull (dos commits porque el merge es un commit también). | ||
+ | git log -p -2 # Muestra los cambios de los dos últimos commits. Útil para saber qué se ha modificado después de hacer un git pull (dos commits porque el merge es un commit también). | ||
+ | |||
git log --all --grep='< | git log --all --grep='< | ||
Line 196: | Line 205: | ||
Abortando</ | Abortando</ | ||
+ | ===== Incorporar cambios en local de una pull request que todavía no ha sido aceptada ===== | ||
+ | Es posible usando frameworks como Bitbucket encontrarse en la situación, donde alguien ha realizado una pull request sobre una rama y esta todavía no ha sido aceptada por nadie para que pase a la rama manager. Al clonar el repositorio e ingresar en dicha rama, los cambios de esas pull request que todavía no ha sido aceptada no están en el código. Es decir, solo la persona que hizo la pull request tiene esos cambios en su repositorio local accesibles de manera directa. | ||
+ | |||
+ | La solución para las personas que quieran tener esos cambios de la pull request, es identificar el commit perteneciente a dicha pull request y usar el comando cherry-pick. Este comando de git se usa para coger commits de otras ramas e insertarlos en otra, pero en este caso, pese a ser la misma rama es también muy útil. | ||
+ | |||
+ | <code bash> # Se clona el repositorio y se empieza a usar la rama BRANCH_XX, que es donde hay una PR pendiente de ser revisada. | ||
+ | git clone XXXX | ||
+ | git checkout BRANCH_XX | ||
+ | # Se busca el commit perteneciente a la Pull request, por ejemplo 0ef16eb1370 y se le indica a git que debe coger ese commit. | ||
+ | git cherry-pick 0ef16eb1370</ | ||
===== Deshacer acciones ===== | ===== Deshacer acciones ===== | ||
Line 294: | Line 313: | ||
Una vez realizado el push, se puede visitar de nuevo el estado de la PR y el test DCO debería ser exitoso. | Una vez realizado el push, se puede visitar de nuevo el estado de la PR y el test DCO debería ser exitoso. | ||
+ | |||
+ | ===== Consejos para auditar / eliminar información sensible de repositorio Git ===== | ||
+ | |||
+ | Como ya es sabido, git no implementa ninguna posibilidad de cifrar variables o ficheros de manera nativa, por lo que es mejor intentar mantener ese tipo de información sensible fuera de los repositorios. | ||
+ | |||
+ | Lo mejor para auditar repositorios es clonarlos con la opción %%--%%mirror, | ||
+ | |||
+ | Una vez se tiene el repositorio clonado se pueden usar un sin fin de herramientas para buscar información que no debería estar ahí como llaves SSH, SSL, Certificados cliente, secretos, etc. Estas herramientas se centran en el uso de expresiones regulares y el uso de algoritmos probabilistas. | ||
+ | |||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// |
cheat_sheet_chuleta_de_git_para_sysadmins.txt · Last modified: 2024/05/28 21:09 by busindre