git trackaera los cambios en archivos agregados, y los archivos nuevos deben ser agregados al HEAD por primera vez para iniciar el trackeo, ademas a git le importan los archivos e ignorara completamente las carpetas vacias.
Subir cambios al repostorio
git push remote rama
git push origin master
Descargar cambios del repositorio
git pull remote rama
git pull origin master
es buena practica hacer pull de manera frecuente y antes de hacer cambios
git clone $URL_O_SSH_DEL_REPOSITORIO
git status
dice el status actual de archivos en git
git reset HEAD^
deshace el ultimo commit sin borrar los cambios
git reset sha_del_commit --hard
resetea los cambios al estado anterior borrando todos los cambios locales no añadidos
git reset sha_del_commit --soft
resetea los cambios al estado anterior manteniedo todos los cambios locales no añadidos
git log nombre_de_archivo
log de los commits con cambios en ese archivo
git log --stat
para ver el status de los archivos cambiados por commit
git show nombre_de_archivo
ver cambios historicos en el archivo
git show
muesta el commit del ultimo cambio que hiciste
git checkout sha_del_commit nombre_del_archivo
cambio solo el archivo seleccionado a su estado en ese commit
git checkout nombre_rama
cambia la branch principal a la branch que se definio en el comando
git diff shacommit_mas_viejo shacommit_mas_nuevo
ver cambios entre un commit y otro
git commit -am
hace commit agregando todos los cambios de archivos trackeados ( modificados ) ignorando archivos nuevos
git commit -a
hace lo mismo que lo anterior pero abre una consola para el mensaje del commit
git branch nombre_de_la_rama
crear una nueva rama con ese nombre
ver todas las branches disponibles en local
git show-branch --all
hacer checkout a una rama y crearla al mismo tiempo
git checkout -b branch_name
ver todas las ramas remotas
git branch -r
ver todas las ramas remotas y locales
git branch -a
git merge rama
fusiona la rama actual con la rama especificada
un merge es un commit en la rama donde se realiza
caso de ejemplo tienes un repo local que deseas subir a github pero al crear el repositorio de github lo iniciaste con un readme , que hacer?
git pull origin master --allow-unrelated-histories
ese comando permitira hacer pull al origin a pesar de que la historia de commits entre master y origin/master es distinta
git config -l
comando de crear un tag
git tag -a $NOMBRE_DEL_TAG -m "Mensaje del tag" $HASH_DEL_COMMIT
mostrar tag y su commit
git show-ref --tags
enviar los tags al repositorio en internet
git push origin --tags
borrar un tag en local
git tag -d $NOMBRE_DEL_TAG
borrar un tag en el repositorio
git push origin :refs/tags/$NOMBRE_DEL_TAG
en proyectos de codigo abierto el manejo del codigo con pull request es algo comun ya que permite colaborar de forma organizada y ordenada al proyecto
al hacer esto se hace necesario que tu fork del proyecto se mantenga al dia con el master por lo cual lo mejor es tener un remote aparte
agregar un remote con nombre al proyecto
git remote add $nombre_del_remote $url_o_ssh_del_proyecto
ademas plataformas como GitHub permiten hacer pull request desde el proyecto padre hacia tu fork, cuando el padre empieza a tener cambios que el fork no posee
Existen servicios como:
-
Travis CI que permiten mantener al servidor actualizado constantemente, lo que haces le das accesos de git y accesos de tu servidor y cuando haya push en la rama especificada en el git, travis le hara pull en el server a los cambios. travis cuesta dinero a menos que sea un proyecto open source.
-
Jenkins , este se instala en el servidor es complejo y poderoso
ambos servicios permiten aplicar integracion continua
No todos los archivos deberian ir a un repositorio ya sea por seguridad, porque son archivos binarios que no deberian ser guardados , son cache o son archivos autogenerados
Es mala practica guardar archivos binarios en un repositorio ya que estos deberian ser suministrados por un content delivery network.
hay pocas execepciones a esta regla como puede ser el logo del programa, pero cualquier imagen que deberia ser mandada por internet no deberia estar en el repositorio.
para ignorar estos archivos exites el .gitignore
, el cual almacena una lista de rutas de archivos a ignorar
este archivo 😄, se utiliza para poder contar al historia de un proyecto de forma bonita y legible. permite contar informacion de que es un proyecto, como funciona, que requerimientos posee entre otros.
Muy buen curso
- Luis Reyes
GitHub Pages y GitLab Pages son servicios que proveen GitLab y GitHub para publicar en un sitio web de forma gratuita un repostorio publico como una pagina web.
Este servicio permite publicar paginas web que no poseean backend.
ejemplo: NOMBRE_REPOSITORIO.github.io
y entonces al abrir es sitio web abrirars el index.html del repositorio
para que funcione el nombre del repositorio debe ser NOMBRE_DE_USUARIO.github.io
Permite reescribir la historia de los repositorios y pegar todos los cambios de rama A a rama B, pero de tal forma como si rama jamas hubiese existido.
ESTA ES UNA MUY MALA PRACTICA HACERLO CON RAMAS QUE ESTAN EN REPOSITORIOS REMOTOS por lo cual solo se deberia hacerse internamente y en repositiorios Locales.
en la rama que borras ejecutas el comando rebase para mandar sus cambios a la rama donde se fucionaran, reescribiendo la historia del repositorio
git rebase $RAMA_A_LA_CUAL_SE_UNIRAN_LOS_CAMBIOS
al hacer esto si la rama a la que se fusionara tiene commits mas adelante de la actual el rebase ejcutara los cambios, tambien considerar que solo funcionara cuando la rama a hacer rebase es una bifurcacion con la que se trata de unir.
es una mala practica porque cambia la historia de en que momento se creo un branch
para ejecutar el rebase, primero se hace un rebase de la rama que deseas borrar con la que uniras los cambios y depues un rebase desde la rama a la que uniras los cambios con la que desear borrar, ejemplo:
para hacer rebase de la rama exp
en master
se hace
(exp)$ git rebase master
(master)$ git rebase exp
funciona para guardar cambios sin comitearlos de forma temporal
Le hace Stash a los cambios que no forman parte de un commit
git stash
puedes ver la lista de stash creados
git stash list
le haces pop al ultimo stash aplicando los cambios en la branch actual
git stash pop
pasar los cambios del stash a una branch nueva
git stash branch $nuevo_nombre_de_la_rama
borrar el ultimo stash
git stash drop
funciona para borrar archivos que no estan siendo trackeados por git, pero ignora los archivos que se ignorarian con el git ignore
para ver los archivos que git clean borrara es con
git clean --dry-run
para borrar los archivos que se vieron con el dry-run es con
git clean -f
Usar cherry pick es una mala practica, para pasar cambios entre ramas es mejor hacer un merge
(es de mis comandos favoritos) es un comando util y que permite copiar un unico commit de una rama y fusionarlo en otra
copia un commit y lo fusiona con la rama actual
git cherry-pick $SHA_DEL_COMMIT
en ciertos casos haces un commit pero te das cuenta que no debias hacer commit aun porque faltaban, cambios por agregar. para solucionar esto SIN HACER PUSH , amend no funcionara si el commit ya esta en el repositorio remoto ya que esto causaria conflicto de historias.
commitear los cambios en el ultimo commit
una vez los cambios se hayan agregado en el head
se fusionan estos cambios con el commit anterior con:
git commit --amend
usar git reset es mala practica porque borra la historia del repositorio como si los cambio nunca hubieran pasado.
si en caso de que un error masivo de archivos, se perdieron datos y no hay forma de recuperarlos con el git log, use reflog
Muestra la historia de TODO desde merge fallidos a branch borrados, orden en que se ejecutaron resets incluso estados del repositorio antes de un reset
git reflog
con este comando muestra la historia de acciones que han occurido en el repositorio
y usando git reset
con el SHA de un commit de git reflog
puedes volver en el tiempo a cualquier momento en el rpeositorio incluso a branches que ya no existen.
hacer esto es mala practica y solo deberia realizarse si algo se rompio en de forma tan grave que no se puede reparar y solo se puede volver en el tiempo.
buscar palabras en los archivos en el branch actual
git grep "palabra a buscar"
mostrar la linea en la cual la pablara aparece en el archivo
git grep -n "palabra a buscar"
mostrar cuantas veces aparce la palabra en cada archivo
git grep -c "palabra a buscar"
buscar los commits en los cuales sale una palabra
git log -S "palabra a buscar"
git rm permite borrar archivos del repositorio siempre y cuando hayan estado en staging. Es equivalente a darle click a un archivo y eliminarlo
ver el archivo que se borrara
git rm $nombre_del_archivo --dry-run
Borrar el archivo del disco
git rm $nombre_del_archivo
Permite ver un historial de todos los commits por persona
git shortlog
muestra solamente la cantidad de commits por persona
git shortlog -sn
muestra la cantidad de commits (considerando todos los commits) por persona
git shortlog -sn --all
muestra la cantidad de commits (considerando todos los commits) sin contar los merges por persona
git shortlog -sn --all --no-merges
permite crear comandos custom de git que ejecutan otro comando de git.
Superlog: git superlog
, git log
mas bonito:
git config --global alias.superlog "log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all"
Stats: git stats
, git shortlog
mas resumido que permite ver la cantidad de commits por persona, (estadisticas):
git config --global alias.stats "shortlog -sn --all --no-merges"
Sistemas de automatizacion de deployment
Ciclo de vida DevOps de un proyecto desde:
- Testing
- Deployment
- Code Maintenance
- Constant Development Constant Deployment
- DevOps y GitLab
- Usar
git $comando --help
para conocer mas de los comandos y crear mis propios comandos custom y geniales