DEV Community

Oswaldo Echeverría
Oswaldo Echeverría

Posted on • Edited on

Notas rápidas Git - GitHub

#git #webdev #tutorial #spanish

🏁 TABLA DE CONTENIDO 🏁

Idea de este post

Este post está pensado para personas que les gusta aprender de una forma rápida o simplemente quieres tener como desarrollador a la mano una guía simple y sencilla de los comandos y soluciones de Git y GitHub.

Como desarrollador uso Windows, así que los comandos están enfocados a este sistema operativo.

Es una guía completa de comandos básicos y avanzados que he aprendido y usado, creo que son los más relevantes para la solución inmediata del entorno de trabajo personal y en equipo

Si te deseas que añada algun otro comando o resolviste algun problema en tu trabajo y no esta esa solucion aqui puedes enviarla con capturas de pantalla a mi correo con tus datos de contacto para agregarlas otorgandote el respectivo credito

Configuracion inicial

  • Comandos para saber la configuración actual de Git 
git config 
git config --list | grep user
git config --list --show-origin
Enter fullscreen mode Exit fullscreen mode
  • Comandos para configuración personal con tu usuario 
git config --global user.name "Escribe aqui tu nombre"
git config --global user.email "Escribe aqui tu correo git"
git config --global core.editor notepad
Enter fullscreen mode Exit fullscreen mode

Comandos unix relevantes

Todos los siguientes comandos los puedes ejecutar desde la terminal gitbash

  • Crear carpeta mkdir nombre_carpeta

  • Crear archivo touch nombre_archivo.extencion_archivo

  • Visualizar contenido de archivo en consola cat nombre_archivo.extencion

  • Editar archivo en blog de nota de Windows
    notepad nombre_archivo.extencion

  • Ver ubicación actual pwd

  • Listar archivos ocultos ls -al

  • Limpiar consola en gitbash clear

Git ignore

Es un documento en donde nos permite ignorar una serie de archivos que por buenas practicas no deben subirse al repositorio git ni guthub ya que git esta diseñado para alojar texto plano.

¿Que no debería subir a git y github?

  • Passwords
  • Imgenes jpj, png etc
  • Videos
  • Entre otras

Como usar git ignore

  1. Dentro de la carpeta de tu proyecto despues haber iniciado git en tu proyecto y antes de meterle codigo creas un archivo tipo ignore. Si estas en la consola de git puedes usar. touch .ignore
  2. Editas el archivo con tu editor de texto favorito o notepad notepad .ignore y escribimos todo lo que debe ser ignorado ejemplo. Podemos escribir linea a linea
    • * Para ignorar todo tipo de archivo
    • *.jpg Todas las imagenes .jpg
    • *.png Todas las imagenes .png
    • *.svg Todas las imagenes .svg
  3. Despues de guardar la configuracion .ignore haces commit git commit -am "Git ignore". Una ves realizado el commit ahora si metele mano al codigo

Si quieres saber mas sobre como usar git ignore puedes entrar en Github y buscar librerias oficiales y leer su .ignore para que sepas y estudies como funcionan y normalmente que se ignora en el desarrollo deacuerdo a la tecnologia que uses.

Ahora te dejare un recurso que puedes usar. Si vas a ésta página podras escribir la tecnologia que usas y te generar un archivo .ignore de guia mostrandote lo que deberias ignorar en el desarrollo.

Haremos un ejemplo de generar un .ignore para django

Biscador de generador ignore

Ponemos en el navegador django y nos generara el archivo.

git ignore django

Nota:

  1. Si eres nuevo usando git te recomiendo que desde tu primer proyecto uses git ignore ya que cuando recien comenzamos a aprender git trabajamos con imagenes para landing page svg y pngs
  2. Si trabajas con imagenes y quieres guardarlas en tu git te invito a buscar un servidor que aloje imagenes y te de el link de ellas para que la puedas susar en tu proyecto
  3. En caso que trabajes con imagenes locales te recomiendo disminuir su peso quitandole toda informacion meta de ella para ello podrias usar el siguiente recurso

README.md

Cuando estas empezando con git tarde o temprano entras en GitHub en donde usarás este archvivo que por recomendación debes crearlo despues del .ignore antes de meterle codigo a tu proyecto con git, entonces usa touch README.md. No te olvides de hacer commit despúes de la creación del archivo.

La ultima recomendación es a nivel de Github, cuando crees un repositorio en GitHub, crealo sin el README.md ya que cuando creas un repo te pregunta si quieres generar ese archivo.
crealo mejor tu mismo desde tu repositorio local y cuando hagas tu primer push se enviará el README.md con tu proyecto. De esta manera evitarás conflictos que para alguien nuevo es un dolor de cabeza.
Este conflicto se suele dar ya que antes de hacer push deberias hacer pull al servidor eso sirve para primero actualizar tu repositorio local con el de Github por que en realidad son dos repositorios distintos entonces si tienes el README.md en Github tendrás que resolverlo con un merge entre dos ramas distintas, borrar la rama antigua local y dejar la actual que ahora es la de github

¿Para que sirve?
Este archivo sirve para mostrar tipo documentación lo que hace tu repositorio o lo que quieras decir de tu repositorio en Github donde todo el mundo lo verá.

Para escribir en el README.md debes usar html o MARKDOWN Asi que te recomendare el siguiente recurso, aquí, tendrás un ejemplo y un editor

Atajos y soluciones

  • Si ingresas un commit sin mensaje y quieres salir del error usa
    esc + shift + z + z

  • Para escribir en el editor vim esc i

  • Para salir de alguna venta de información como git log usamos la letra q

  • Ayuda de comandos git git help comando_git o
    git comando_git --help.

  • Ver el historial de comandos usados git history.

    Se desplegara una lista enumerada y ordenada con todos los comandos usados y si queremos hacer uso de alguno de ellos escribimos ! seguido del numero del comando

Inicializar un repositorio

  • Si no tienes creada ni la carpeta del proyecto.
    Esté comando, te creará la carpeta y te iniciará el proyecto en git
    git init nombre_carpeta_proyecto o si piensas que lo vas a usar en GitHub git init nombre_carpeta_proyecto -b main

  • En caso de que ya esté creada la carpeta del proyecto.
    Dentro de la carpeta ejecutas git init y si lo vas usar con github
    git init -b main

Manejo del staging area

  • Observar el estado de los archivos git status

  • Agregar un solo archivo al staging area
    git add nombre_archivo.extencion

  • Agregar todos los archivos al staging area sin excepciones, es decir, con los que estemos trabajando, modificando o no git add .

  • Agregar todos los archivos con los que estamos trabajando al staging area git add -A

  • Sacar un archivo del staging sin que los borre del disco duro, pero git le sigue dando seguimiento
    git reset HEAD nombre_archivo.extencion

Este es el comando mas usado ya que aveces solo queremos que el archivo salga de la zona de staging en un estado de untracked. Esto significa que de inmediato podras hacer git add y git commit nuevamente.

  • Sacar un archivo del staging area y del seguimiento de git git rm -cached nombre_archivo.extencion

Una vez que apliques este comando sacaras del repositorio de git el archivo, no lo borra del disco duro. Si quisieras hacerle un add y commit no lo encontrarias en el repositorio, tendrias que esperar hasta el proximo commit para que apareciera.

  • Sacar un archivo del stagig area y borrarlo de forma local
    git rm -f nombre_archivo.extencion

  • Comprobar si un archivo fue agregado al staging area aunque parezca que no git add -n nombre_archivo.extencion

  • Recuperar un archivo borrado por error
    git checkout -- nombre_archivo.extencion

  • Ver diferencias entre el estado actual y el staging git diff

Git commit

El proceso de tradicional de realizar un commit es:

  • Primero: Ver el estado del archivo modificado git status

  • segundo: Añadir archivo al stagind area 📌
    git add nombre_archiv.extencion

  • Tercero: Hacer commit añadiendo una descripción del commit
    git commit -m "Entre comillas escribe la descripcion"

Comandos avanzados para commit

  • Hacer commit directamente sin pasar por el staging
    git commit -am "Descripcion"

  • Ver la diferencia de un commit con otro
    Para esto necesitamos el identificador de los dos commit.
    Para ver el identificador podemos usar git log

Nota: El identificador del commit es el numero alfanumerico. Este numero es muy largo pero es suficiente para identificarlo si solo usamos los primeros 5 numeros.

Luego de saber el identificador de los dos commit usamos
git diff identificador1 identificador2

  • Sobreescribir un commit. Este comando lo usamos inmediatamente después que hemos cometido el error. Antes de ejecutarlo corrigen el error git commit --amed -m "Descripcion"

Podemos reescribir solo la descripcion, algun error, u algo faltante.

Comandos avanzados de sobreescritura

Los siguientes comandos hay que tratarlos con cuidado porque podríamos perder código en el proceso

  • Nos quitará el último commit, pero los archivos los dejará preparado en el staging para un nuevo commit. Usamos git log para ver el identificado del commit y luego 📌
    git reset --soft identificador

  • Nos quitará el último cambio y datos, no se guardarán en ningún lugar ni en el staging ni en el disco duro. Usamos git log para ver el identificado del commit y luego 📌
    git reset --mixed identificador

  • Borra todos los commits, stagings y working hasta el punto del commit que se requiere. Usamos git log para ver el identificado del commit y luego 📌
    git reset --hard identificador

  • Recuperar commits depues de un reset hard.
    Lo primero que necesitamos es buscar el identificador de un commit seguro antes del reset hard.
    Usamos git reflog o git log -g.

Una vez encontrado el commit seguro ejecutamos
git reset --hard identificador_commit_seguro

  • Ver un commit a través del tiempo. Sabemos que a medida que se hacen los commit se van añadiendo cambios. Entonces este comando nos ayuda a ver el estado y el contenido de un commit pasado, es decir, antes de los cambios actuales. Los cambios que se realicen no serán permanentes.

: Para ir al estado anterior del commit.
Usamos git log para ver el identificado del commit y luego
git checkout identificador nombre_archivo

: Para regresar al tiempo actual git checkout master

: Si queremos hacer permanentes los cambios que hemos hecho en
un commit pasado. Después de hacer los cambios correspondientes hacemos git add . y 📌
git commit -m "Descripcion".

Se hace un commit y los cambios seran enviados al commit
actual.

  • Mover un commit de rama. Este commit se lo debe ejecutar dentro de la rama donde se lo quiere mover 📌
    git cherry-pick identificador_commit

  • Visualizar en consola los cambios de un archivo en su historia. Este comando nos permitirá observar los cambios que existe en un archivo en el actual commit con el mismo archivo pero en el commit pasado. No solo nos muestra las modificaciones entre un commit y el otro, sino también donde están los cambios en la base de datos, diferencia en peso, bytes 📌
    git show nombre_archivo.extencion

  • Que cambios hubo entre un commit y otro
    git diff identificador1 identificador2

El orden de los identificadores hara que muestre la informacion de una manera u otra.

Git tag o Etiquetas

Que es un tag

  • Es un nombre que puedes usar para marcar un punto relevante, estructural o especifico de tu codigo en la historia del repositorio.

  • Son relevantes en producción, trabajando en remoto GitHub con equipos. En GitHub se lo usa mucho para detallar versiones listas o release de un proyecto

  • Aunque los tags no son commit hay que enviarlos al repositorio principal

Comandos

  • Tags lijeras git tag nombre_tag

  • Tags firmado por correo `git tag -a nombre_tag -m "Descripcion"

  • tags formados por clave GPT del correo electronico
    git tag -s nombre_tag "Descripcion"

  • Ver la lista de los tags git tag -l

  • Renombrar tag 📌
    git tag -f -a nuevo_nombre_tag "Descripcion"

  • Borrar tag git tag -d nombre_tag

    Si borras un tag y trabajas con repositorios remoto no olvides actualizar la accion git pull origin master y despues git push origin --tags

Aunque de esta manera se borro localmente aun queda en github ya que los releases o versiones listas son muy importantes asi que para evitar equivocaciones de borrado hay que borrarlo de forma especial con 📌
git push origin :ref/tags/nombre_tag

  • Ver el commit que pertenece a la etiqueta 📌
    git show nombre_tag

  • Saber a que commit o hash esta vinculado un tag 📌
    git show-ref --tags

  • Filtrar etiquetas git tag -l "patron de busqueda"

Git log

Muestra instantáneas confirmadas. Se utiliza para enumerar y filtrar el historial del proyecto, y buscar cambios particulares. El git log solo funciona en el historial comprometido en comparación con de git status que trabaja con el área de preparación o staging.

Si eres un scrum master o lider de proyecto usaras muchas configuraciones con este comando para revisar el trabajo de tus compañeros o ver como va el codigo en el dia etc. Pero para uso personal y para mi son las mas necesarias son:

  • Instantánea estándar git log
  • Muestra todas las ramas git log --all
  • Instantáneas abreviadas en una línea git log --pretty=online
  • Instantáneas gráficamente con el identificador abreviado y descripción git log --pretty=format:"%h %s" --graph
  • Muestra las diferencias introducidas entre cada commit con limite en las dos ultmas entradas git log -p -2

Para mas configuraciones puedes visitar la Pagina oficial

Ramas

Imagen que muestra como funcionan las ramas en git

Nota:
Si creamos una rama y no hacemos commit todo lo realizado se perdera.

  • Crea una rama git branch nombre_rama

  • Entrar en una rama diferente git checkout nombre_rama

  • Crear una nueva rama y entrar en ella al mismo tiempo git checkout -b nombre_rama

  • Listar ramas git branch -l

  • Listar ramas remotas | GitHub git branch -r

  • Listar ramas remotas GitHub y locales git branch -a

  • Historia de rama git show-branch --all

  • Elimina rama git branch -d nombre_rama

  • Elimina rama con commits adentro git branch -D nombre_rama

  • Renombrar una rama
    git branch -m nombre_rama_anterior nombre_rama_nueva

Git merge o fusiones

Imagen de ejemplo grafico de merge

Comenzamos con esta imagen para dar un ejemplo.
Tenemos
Rama master: Tenemos el contendio html
Rama Cabecera: Tenemos el diseño en cabecera

Queremos llevar el diseño de la rama cabecera a la rama master. Entonces guardamos commit en cabecera, nos dirigimos a la rama master git checkout master y en la rama master hacemos el merge a cabecera
git merge cabecera -m "Descripcion"

El git merge es un commit mas en el proyecto.

  • Para saber que ramas no han sido fucionadas aun en la rama actual
    git branch --no-merged

  • Para saber las ramas que ya han sido fucionadas. Si las ramas se eliminaron despues del merge entonces saldra master.
    git branch --merged

Algunos conflictos con merge

  • Si sale un mensaje de Fast-forward significa que estas haciendo un merge en la continuacion directa de la rama en la cual salio

  • Si no eres el primero en hacer un merge te va a pedir en tu editor para que coloques que quieres mezclar y como se va a llamar. Esto es un commit que pide confirmar los cambios, en otras palabras es una mezcla recursiva que obliga hacer un commit adicional, este se presenta en log como un commit mas a la rama principal.

  • Cuando e ha cambiado lineas de codigo anteriores o archivos se denomina Auto-mergin y saldrá un mensaje de CONFLICT en donde preguntará con que version se quedará. Una vez que se haya escojido u arreglado el conflicto se debe hacer un nuevo commit

  • Cuando una rama intenta hacer merge en un documento que ha sido modificado por dos ramas distintas eso genera un conlicto. Entonces abrimos el documento y corregiremos de forma manual una vez eso mandamos al staging y luego hacemos commit.

    VisuslCode tiene ayudas para estas situaciones

Git rebase

Se usa cuando quieres que una rama no sea una rama si no mas bien que sea parte de la historia del master y no quede huella de que fue una rama.

Caracteristicas

  • Primero quiero decirte que git rebase es una muy mala practica usarla de forma remota por lo cual esta puesta en este post ya que si puede ser usada de forma local de algunas formas.
  • Es una mala practica por que reescribe la historia de los repositorios
  • Uno de los inconvenientes es que cuando haces rebase no queda historia, no se sabe quien hizo que cosa o que cambios y si la rama master avanzo mucho antes del rebase los problemas y conflictos seran muchos y habrá que solucionarlos de forma manual uno por uno causando retraso a todo el equipo

La unica forma en que se la puede recomendar es trabajarla de forma local en un proyecto personal o en un proyecto en equipo siempre y cuando apliques rebase y arregles los conflictos antes de enviarlo al servidor. Por ejemplo.

Supongamos que traiste localmente el codigo del proyecto de equipo para hacer tu parte que es desarrollar el script de unas funciones en el diseño y el diseño entonces el primer dia tuviste un error que no pudiste resolver, al siguinte, dia2 resulves hacer una rama para arreglar el bugfix pero seguir trabajando en la linea principal en el diseño,

rebase1

terminaste el diseño en el mismo dia 2.
En el dia 3 comienzas a resolver el bugfix y lo logras, entonces tu trabajo esta terminado. Puedes hacer un merge e incorporarlo a tu linea de trabajo principal

merge

pero no deseas que esa rama de bugfix quede en tu historial por que no ha sido algo relevante asi que haces rebase, resulves los conflictos y a la finl tu linea de trabajo quedará asi

rebase

Como si nunca hubiera habido una rama y sin huellas de que haya habido una.

Comandos

Usaremos el mismo ejemplo anterior para el codigo de acontinuación

  • Estando en la rama del bugfix
    git rebase master

  • Lugo desde el master. 📌
    git rebase nombre_rama_rebase_anterior

  • En este momento hay dos ramas que contienen lo mismo el master y en bugfix

  • Solucionar de forma manual los conflictos en la rama master

  • Por ultimo eliminar la rama bugfix
    git branch -D rama_bugfix

Git stash

Sabemos que si hacemos cambios en una rama y luego cambiamos de rama sin hacer commit antes, perderemos los cambios hechos anteriormente.

Para evitarlo existe git stash. Nos permite guardar cambios temporalmente para usarlos despúes o en una nueva rama

Se usa cuando estas probando algun codigo que no merece un rebase o una nueva rama y quieres regresar rapido a tu estado anterior

Si usas un stash en una rama antes ya creada causarias muchos conflictos. Solo se recomienda usarla en una nueva rama

Comandos

  • Para guardar el cambio temporal git stash
  • Para listar stash guardados git stash list
  • Para ejecutar el stash guardado en una nueva rama 📌 git stash pop
  • Para deshacer el pop Control z
  • Guardar un stash en una rama nueva git stash branch nombre_rama y luego git commit -am "Descripcion"
  • Eliminar stash git stash drop

Git clean

Es un comando que nos ayuda a limpiar el entorno de trabajo. Ejemplo

Si tenemos archivos duplicados o archivos que no han sido utilizados, llamados entre otros

A git clean no le interesan las carpetas solo los archvivos, tampoco tomará encuenta todo lo que este en .ignore

El comando que se usa es git clean pero no se usa solo. Cuando lo quieras usar ejecuta
git clean --dry-run
Este comando te mostrara en lista una simulacion de todo lo que puede ser eliminado por clean.
Si estas satisfecho con todo lo que te muestra para borrarlo entonces ahora si ejecutas git clean -f para eliminar

Git cherry pick

Se usa cuando estamos trabajando un avance en una rama y se requiere en el master de urgencia un commit especifico de tu rama en al que estas trabajando

Pasos para ejecutar cherry pick

  1. Hacer git checkout a la rama donde esta el commit solicitado
  2. Hacer git log para copiar el identificador del commit solicitado.
  3. HRegresamos al master con git checkout master y ejecutamos en el master git cherry-pich identificador_commit_solicitado

Cuando se termine lo que se estaba haciendo en la rama y se valla hacer un merge oviamente abran conflictos por que la rama master ya tiene un commit de la rama, pero esto se soluciona simplemente fixeandolo manualmente o con ayuda del editor de codigo

Su estas trabajando con Github
Cuando lo quieras enviar al servidor no olvidar primero hacer git pull origin master y ahora si git push origin master para enviarlo

GitHub nunca se enterará de los combios locales

Git Reset y Reflog

  • Se usa en casos de emergencia, se usa cuando hemos hechos cambios tan drasticos que queremos recuperar el punto antes de ese momento.
  • En regflog no se borra ningun commmit o cambio en el tiempo
  • si en git log no se ecuentran los cambios por que han sido eliminados de seguro en git reflog si estarán

Pasos para ejecutarlo

  1. Ejecutamos git reflog
  2. Nos aparecera una lista de commit incluyendo los commits borrados y los que no han sido borrados
  3. Buscamos el ultimo commit en donde todo esta correcto o el que deseamos recuperar y copiamos su identificador o head.
  4. Para recuperar tenemos tres opciones:

  • Reset soft: Te regresa a un punto donde los archivos estan preparados en el staging a la espera de un nuevo commit
    git reset --soft identificador_commit

  • Reset mixed: Te regresa a un punto donde los archivos estan en el repositorios de git y no se ha hecho ni staging ni commit.
    git reset --mixed identificador_commit

  • Reset hard: Te regresa a un punto donde se recuperan los archivos pero solo lo puedes ver localmente es decir git no les esta dando segumiento, tendrias que darle commit a ese estado para que la proxima vez ya git le pueda dar seguimiento en el repositorio. Este reset solo se usa cuando has hecho algo masl y quieres volver a empezar de nuevo pero quieres los archivos
    git reset --hard identificador_commit

Git grep

Este comando lo usamos cuando el proyecto es muy grande y por ovia razones muchos archivos y queremos buscar algo dentro de un archivo como una sintaxis. Por ejemplo

Si queremos buscar la etiqueta

entre todos los archivos

Comandos

  • Buscar el archivo donde esta la palabra o etiqueta. 📌
    git grep "codigo, palabra o etiqueta"

  • Buscar el archivo y la linea de codigo.
    git grep -n "codigo, etiqueta o palabra"

  • Contar la cantidad de veces que una palabra aparece. 📌
    git grep -c "palabra, codigo o etiqueta"

  • Si quiero buscar algo que no esta en el codigo sino en la historia de los commit. Por ejemplo. Cuantas veces escribi la palabra diseño en los commit o donde la palabra diseño tiene algo que ver con respecto a los commit. 📃 ✏️ 📌 git log -S "diseño"

Comandos para lider de equipo de desarrollo o scrum

  • Cuantos commits ha realizado cada miembro del equipo.
    git short log

  • Mostrar las personas que han realizado ciertos commits en el equipo.
    git short log

  • Mostrar todos los commits incluidos los eliminados
    git shot log -sn --all

  • Mostrar todos los commits incluidos los eliminados pero que no incluya los merges o los commits fusionados.
    git short log -sn --all --no-merges

  • Saber quien hizo que en el codigo.
    git blame -c nombre_archivo

  • Saber quien hizo que en el codigo especificando las lineas de codigo de donde(33) hasta donde(55).
    git blame nombre_archivo -L33,55

Git alias

Lo usamos para abreviar un comando largo y dificil de recordar en uno mas corto y facil de recordar y referenciado con su accion

Ejemplo:
git short log -sn --all --no-merges

Para tranformarlo en un alias usamos:

git config --global alias.nombre_nuevo "git short log -sn --all --no-merges"

GitHub

Inicializar un repositorio local y en github vacio

  1. Crear repositorio en Github sin el archivo README.md
  2. Crear la carpeta del proyecto y dentro de la carpeta del proyecto crear de forma manual el archivo readme o por cmd echo "# readme" >> README.md

  3. Dentro de la carpeta del proyecto iniciamos git. 📃 ✏️
    git init -b main

    En caso que la rama master se llame master debemos cambiarle a main con el comando
    git branch -M main.

  4. Verificamos que todo este listo. Ejecutamos git add . y git commit -m "Inicio de proyecto"

  5. Copiamos el link del repositorio que creamos en Github el de http ejecutamos
    git remote add origin http.tulinkrepositorio

  6. Hacemos push git push -u origin main

  7. Puedes comprobar que tus archivo README.md esta en GitHub

Apartir de aqui cada cambio que quieras enviar

  1. Revisalo y soluciona errores
  2. Refrescar a tu repositorio local el Github con 📌 git pull origin main
  3. Enviar tus actualización con git push origin main

Si estas trabajando despues con varias ramas pero deseas enviar la actualizacion de una sola rama al master en Github usa
git push -u origin main

Top comments (2)

Collapse
 
dennistobar profile image
Dennis Tobar •

Hola... gracias por el post. Si hubiera existido una guía así en mis inicios, hace tiempo no hubiera sufrido con las reversas locales de ramas (era mejor ver arder el mundo y luego bajar nuevamente el master)

Te sugiero que cambies una etiqueta del post a Spanish para que la comunidad en español lo pueda encontrar con facilidad :)...

Saludos ;:)

Collapse
 
oswald_echeverri profile image
Oswaldo Echeverría •

Hola gracias por tu comentario ya busco como hacer ese cambio

Read next

suzuki0430 profile image

Avoiding Connection Pinning in Lambda and RDS Proxy with NestJS and Proxy Splitting

Atsushi Suzuki -

carrie_luo1 profile image

Why Homelab Users Need a WAF

Carrie -

rezmoss profile image

From WHOIS to SSL: How DNS Checker Pro Unveils the Hidden Details of Any Website

Rez Moss -

devops_den profile image

5 Best Reasons You Should Choose Microservices Architecture for Your Project

Devops Den -