Guide
La guía rápida de comandos Git es una tabla lista para usar: 149 comandos agrupados en once escenarios —inicialización y configuración, commits del día a día, ramas, fusiones y rebase, deshacer y revertir, trabajo remoto, stash, etiquetas, submódulos y worktrees, historial y diagnóstico, e ignorar y atributos—, y cada uno trae una explicación, un ejemplo que se puede pegar tal cual y un nivel de riesgo entre «atención» y «peligro»: los comandos que pueden perder cambios sin confirmar o reescribir una historia ya compartida se reconocen de un vistazo.
Actualizado el 2026-09-094 sources11 min read
La guía rápida de comandos Git es una tabla lista para usar: 149 comandos agrupados en once escenarios —inicialización y configuración, commits del día a día, ramas, fusiones y rebase, deshacer y revertir, trabajo remoto, stash, etiquetas, submódulos y worktrees, historial y diagnóstico, e ignorar y atributos—, y cada uno trae una explicación, un ejemplo que se puede pegar tal cual y un nivel de riesgo entre «atención» y «peligro»: los comandos que pueden perder cambios sin confirmar o reescribir una historia ya compartida se reconocen de un vistazo.
Está pensada para tres momentos: cuando recuerdas qué quieres hacer pero no cómo se escribe el comando (busca «deshacer commit», «borrar rama remota»); cuando conoces el comando pero no estás seguro de si puede perder algo (mira el nivel de riesgo y las notas); y cuando tocas Git por primera vez y quieres entender qué se mueve entre add, commit y push (mira el diagrama de las cuatro áreas del principio y los esquemas de operaciones de más abajo).
Al final de la página hay una terminal Git simulada que funciona solo en memoria: admite más de 30 subcomandos habituales, el grafo de commits de la derecha cambia en tiempo real con cada comando y trae 10 niveles de práctica, del «primer commit» a «resolver un conflicto de fusión». No es un Git real y no toca tu ordenador ni la red, pero su semántica sigue el manual oficial, así que lo aprendido se traslada a una máquina real.
Si escribes «deshacer commit» en el buscador, aparecen estas filas del grupo «deshacer y revertir» (extracto):
Así se resuelve en la terminal simulada el nivel 4, «deshacer el último commit pero conservar los cambios»:
git reset --soft HEAD~1 deshace el último commit y deja los cambios preparados atención
git reset HEAD~1 deshace el último commit y devuelve los cambios al árbol de trabajo sin preparar
git reset --hard <commit> puntero de rama, índice y árbol de trabajo vuelven todos a <commit> peligro
git revert <commit> crea un commit nuevo que invierte los cambios; la historia no cambia y se puede subir sin riesgouser@toolun-lab:~/project (main)$ git log --oneline
7f3a1c2 (HEAD -> main) wip: cambios pendientes
2b9e0d4 init: add README
user@toolun-lab:~/project (main)$ git reset --soft HEAD~1
HEAD está ahora en 2b9e0d4 init: add README
--soft: solo mueve el puntero de rama; el índice y el árbol de trabajo se conservan (el contenido del commit deshecho queda preparado)
Aviso: el commit descartado 7f3a1c2 todavía se puede recuperar con git reflog
user@toolun-lab:~/project (main)$ git status -s
A app.js
A secret.env
✔ Nivel superado: deshace el último commit pero conserva los cambios.Casi cualquier comando de Git se puede entender como «llevar contenido de un área a otra». El árbol de trabajo son los archivos que ves y editas; el índice es la lista de «cómo será el próximo commit»; el repositorio local (.git) guarda todos los commits; y el repositorio remoto es lo mismo, en otra máquina.
Con este esquema, casi todas las dudas de «cómo deshago esto» tienen una respuesta común: si te equivocaste y aún no has hecho add, recupera con git restore <file> desde el índice; si ya hiciste add y no quieres confirmarlo, usa git restore --staged; si ya confirmaste, usa git reset; y si ya lo subiste, solo puedes añadir un commit inverso con git revert.
Un objeto commit registra: la instantánea de todo el árbol de directorios (no un diff), el id del commit padre, el autor y la fecha, y el mensaje. Todo eso se pasa por SHA-1 (en repositorios nuevos, opcionalmente SHA-256) para obtener el id del commit, así que cualquier cambio, aunque sea una letra del mensaje, produce un id completamente nuevo. Por eso --amend, rebase y cherry-pick «reescriben la historia»: generan commits nuevos y los antiguos simplemente dejan de estar referenciados.
Una rama es un archivo de 40 caracteres en .git/refs/heads/<name> cuyo contenido es el id de un commit. HEAD apunta normalmente al nombre de una rama. Por eso crear una rama es instantáneo (escribir un archivo pequeño), cambiar de rama es redirigir HEAD a otro nombre y actualizar el árbol de trabajo a la instantánea de ese commit, y borrar una rama es solo borrar un puntero: los commits no desaparecen de inmediato.
merge registra con fidelidad lo que pasó: las dos líneas se unen en el commit de fusión y cualquiera puede ver que esa funcionalidad se desarrolló en paralelo. rebase hace que la historia parezca siempre lineal, con un git log más legible y un git bisect más útil, pero a cambio cambian todos los ids de commit. La regla práctica: haz rebase sin miedo en tus ramas aún no subidas; en una rama sobre la que pueden estar trabajando otros, haz solo merge. git pull --rebase es la aplicación diaria de esa regla: recoloca tus commits locales no subidos después de lo último del remoto y evita una ristra de «Merge branch 'main' of …».
--soft va bien para «dividir o reagrupar commits»: el puntero retrocede y el contenido sigue en el índice. --mixed (el modo predeterminado) va bien para «volver a elegir qué confirmar». --hard sí descarta de verdad: los cambios del árbol de trabajo que nunca se confirmaron no se pueden recuperar, mientras que los commits deshechos siguen en la base de objetos; git reflog muestra cada movimiento de HEAD y git reset --hard HEAD@{1} vuelve al estado anterior al reset. De forma predeterminada, el reflog se conserva 90 días (30 días para las entradas inalcanzables): esa es la ventana de arrepentimiento que te da Git.
La marca «peligro» se aplica a dos familias: comandos que descartan contenido sin confirmar del árbol de trabajo (restore, reset --hard, clean, stash drop, checkout -- <file>) y comandos que reescriben una historia que otros ya pueden tener (push --force, branch -D de una rama sin fusionar). La marca «atención» se aplica a comandos que cambian el estado pero se pueden revertir, o que exigen confirmar antes el alcance (commit --amend, rebase, merge --squash, push --delete). Los comandos de solo lectura (log, diff, status, show, blame) no llevan marca.
git switch y git restore necesitan la versión 2.23 o superior, y la forma antigua checkout también aparece.hash-object, cat-file, update-ref, etc.) ni operaciones propias de una plataforma (las acciones web de PR en GitHub o de MR en GitLab).reset, rebase lineal, stash y push/pull remotos); no admite rebase interactivo, bisect, submódulos, hooks ni todas las opciones de los archivos de configuración, y un rebase con conflictos se aborta solo en lugar de esperar a que lo resuelvas..git de tu ordenador ni ofrece un resolutor gráfico de conflictos.Busca «deshacer» o entra en el grupo «deshacer y revertir», distingue primero los casos «aún no subido» (reset, --amend) y «ya subido» (revert) y elige después el comando. En «combinaciones habituales» hay recetas completas como «confirmé en main y quiero moverlo a una rama nueva».
git rebase -i HEAD~N junto con squash, fixup o reword; en la tarjeta de rebase del esquema se ve cómo la historia pasa de bifurcada a lineal y por qué los commits antiguos se quedan en gris.
El grupo «trabajo remoto» va de remote add a push -u y --force-with-lease, y los niveles 8 (subir) y 9 (deshacer un commit ya subido) de la terminal de práctica cubren los dos «no me deja subir» más habituales.
git reflog, git fsck --lost-found y git stash list están seguidos en «deshacer y revertir»; la receta «recuperar una rama borrada por error» se hace en dos pasos.
Depende de si el commit ya se subió. Si no se ha subido, reset retrocede el puntero y la historia queda limpia. Si ya se ha subido, revert añade un commit inverso y no reescribe la historia que otros ya tienen; de lo contrario, la próxima vez que hagan pull se encontrarán con una bifurcación.
Porque tienes commits locales sin subir y el remoto también tiene commits nuevos, y el pull predeterminado une las dos partes con una fusión. Para evitarlo, usa git pull --rebase o configura de una vez git config --global pull.rebase true.
--force sobrescribe la rama remota sin condiciones. --force-with-lease comprueba antes si la rama remota sigue en el commit que viste en tu último fetch y lo rechaza si alguien ha subido algo nuevo: deja fuera accidentes como «pisar el commit de un compañero». Para subir después de reescribir la historia, usa siempre esta segunda forma.
En Git real, el id sale de aplicar un hash al contenido, el autor y la marca de tiempo; el simulador usa un reloj lógico en lugar del tiempo real y un hash determinista, así que la misma secuencia de operaciones da el mismo id y es fácil comparar con la solución. Sus ids no coinciden con los que calcularía Git real, y es a propósito.
Los comandos son iguales en todas las plataformas. La diferencia está en el shell: en PowerShell && necesita la versión 7.x y conviene envolver las rutas entre comillas; para los saltos de línea, ajusta la entrada core.autocrlf de «inicialización y configuración».
Todos los datos de esta página (la tabla de comandos, los esquemas y la terminal simulada) son contenido estático que se descarga con la página y se ejecuta en tu navegador; buscar, copiar, guardar favoritos y practicar no envían ninguna petición al servidor. Los favoritos se guardan en el localStorage de este equipo y el sitio no puede leerlos. Los enlaces externos de la página apuntan a la documentación oficial de Git y, al pulsarlos, los gestiona el sitio de destino.
Actualizado el 2026-09-09
149 comandos Git agrupados por situación, cada uno con explicación, ejemplo y nivel de riesgo; búsqueda, copia con un clic y favoritos; incluye diagramas y una terminal de práctica
Esta herramienta no está traducida por completo; parte del contenido usa el idioma de origen o uno de reserva.
git init git init -b main # Especifica el nombre de la rama inicial
git clone https://github.com/git/git.git git clone git@github.com:user/repo.git my-dir
git clone --depth 1 --branch v2.0 https://github.com/user/repo.git
git clone -b develop https://github.com/user/repo.git
git config --global user.name "Zhang San" git config --global user.email "zs@example.com"
git config user.email "me@company.com"
git config --list --show-origin git config --get user.name
git config --global core.autocrlf input
git config --global alias.lg "log --oneline --graph --all" git lg
Windows suele venir con un administrador; macOS usa osxkeychain para mayor seguridad.
git help rebase git reset -h # Uso breve
git status git status -s # Formato corto: M Modificar A Agregar D Eliminar ?? No rastreado
git add src/app.js git add src/ # Directorio completo git add "*.md" # comodín
git add -A git add -u # Solo se almacenan los cambios temporales y las eliminaciones de los archivos rastreados, excluyendo los archivos nuevos.
git add -p src/app.js # y guardar temporalmente esta pieza n saltar s dividir en piezas más pequeñas q salir
git commit -m "solución: juicio correcto sobre el tiempo de espera de inicio de sesión"
git commit -am "docs: update readme"
Es fácil introducir cambios que no desea realizar. Simplemente ejecute git status antes de confirmar.
git add forgotten.js git commit --amend --no-edit #Agregar archivos pero no cambiar la descripción git commit --amend -m "nueva descripción"
Generar una nueva ID de commit; No modifique los commits que ya hayan sido enviados; de lo contrario, será necesario enviarlos.
git diff git diff src/app.js # Ver solo un archivo
git diff --staged
git diff main feature git diff HEAD~3 HEAD -- src/ git diff main...feature # Cambios de características en relación con el punto de bifurcación
git diff --stat HEAD~1
git diff --word-diff=color README.md
git log git log -5 # Últimas 5 entradas git log --oneline # Una línea por línea
git log --oneline --graph --all --decorate
git show HEAD git show a1b2c3d --stat git show HEAD:src/app.js # Ver el contenido del archivo de una determinada versión
git rm old.txt git rm -r legacy/
git rm --cached .env echo ".env" >> .gitignore
git mv utils.js helpers.js
git branch git rama -a # incluye ramas remotas git branch -vv # Con la última relación de commit y seguimiento
git branch feature/login revisión de rama de git a1b2c3d # Crear a partir del compromiso especificado
git switch main git switch - # Regresar a la rama anterior
git switch -c feature/search git switch -c hotfix origin/main # Basado en la rama remota
git checkout -b release/1.2
git branch -m master main git push -u origin main && git push origin --delete master
git branch -d feature/login
git branch -D experiment
los commits únicas en la rama quedarán huérfanas y se podrán recuperar mediante reflog en el corto plazo.
git branch --merged main git rama --no-merged # a la inversa
git branch -u origin/feature/login
git branch -a --contains a1b2c3d
git checkout v1.0 git switch -c fix-from-v1 # Si desea conservar los cambios, cree una rama aquí
Los commits en este estado no pertenecen a ninguna rama y se pierden fácilmente después de ser cortados.
git branch --sort=-committerdate | head
git fetch -p git remote prune origin
git switch main git merge feature/login
git merge --no-ff feature/login
git merge --squash feature/login git commit -m "feat: login"
git merge --abort
git add src/app.js git commit #Descripción predeterminada Fusionar rama...
git checkout --theirs package-lock.json git add package-lock.json
Cuando se rebase, los significados de nuestro/de ellos se invierten: nuestra es la rama que se rebase.
git switch feature git rebase main
Todos los ID de commit que se muevan cambiarán; Las ramas que han sido empujadas y alguien está trabajando en ellas no deben cambiarse de base.
git rebase -i HEAD~3 # elegir mantener reformular cambiar la descripción aplastar fusionar con la anterior arreglar fusionar y perder la descripción soltar eliminar
git add . git rebase --continue
git rebase --abort
git rebase --onto main server client
Adecuado para la situación en la que "la rama se abre en el lugar equivocado".
git commit --fixup a1b2c3d git rebase -i --autosquash a1b2c3d~1
git cherry-pick a1b2c3d git cherry-pick a1b2c3d..e5f6g7h # Un rango (excluyendo a1b2c3d)
git cherry-pick -n a1b2c3d
git config --global merge.tool vscode git config --global mergetool.vscode.cmd "code --wait $MERGED" git mergetool
git restore src/app.js git restaurar. # Directorio completo
Los cambios no preparados se perderán directamente y no se podrán recuperar mediante Git.
git restore --staged src/app.js git reset HEAD src/app.js #Forma antigua de escribir
git restore --source HEAD~2 config.yml git restore --source v1.0 -- src/
git reset --soft HEAD~1 git commit -m "Una descripción más apropiada"
git reset HEAD~1
git reset --hard HEAD~1 # Desecha el último compromiso git reset --hard origin/main # Exactamente igual que el control remoto
Los cambios en el espacio de trabajo son irreversibles; los comprometidos se pueden recuperar usando git reflog.
git reset package-lock.json
git revert HEAD git revert a1b2c3d --no-edit
git revert --no-commit HEAD~3..HEAD git commit -m "revert last 3 commits"
git revert -m 1 f00ba12
Después de deshacer la fusión, debe revertirla antes de fusionarla en la misma rama.
git reflog
git reset --hard HEAD@{2} # Regresar al estado anterior al paso 2
git rama rescate a1b2c3d # Crear una rama para el commit huérfanogit clean -n # Vista previa de lo que se eliminará git clean -fd # ejecutar git clean -fdx # Elimina incluso los ignorados en .gitignore (como node_modules)
git checkout -- src/app.js
git fsck --lost-found git show <dangling-commit-id>
git fsck --unreachable | grep commit | cut -d" " -f3 | xargs git log --merges --no-walk
git remote -v
git remote add origin git@github.com:user/repo.git
git remote set-url origin git@github.com:user/repo.git
git remote rename origin upstream
git remote remove upstream
git fetch git fetch origin main git fetch --all --prune
git pull git pull origin main
git pull --rebase origin main
git push git push origin main
git push -u origin feature/login
git push origin --delete feature/old git push origin --delete v0.1 # También puedes eliminar etiquetas remotas
git push --force-with-lease origin feature/login
Utilice esto con preferencia a --force.
git push -f origin feature/login
Los commits impulsados por otros serán eliminados; Se prohíben las ramas compartidas.
git push --all origin
git ls-remote --heads origin git ls-remote --tags https://github.com/git/git.git
git remote add upstream https://github.com/original/repo.git git fetch upstream git switch main && git merge upstream/main
git pull --ff-only
git stash git stash push -m "Página de inicio de sesión semiacabada"
git stash -u git stash -a # Recopilar incluso archivos ignorados
git stash list
git stash pop
git stash pop stash@{2}git stash apply stash@{1}git stash show -p stash@{0}git stash drop stash@{0}
git stash clear # eliminar todogit stash branch fix-from-stash stash@{0}git stash push -m "Contraer sólo estilos" -- src/styles/
git tag git tag -l "v1.*" # Filtrar por patrón
git tag -a v1.2.0 -m "Release 1.2.0"
git tag build-2026-09-09
etiqueta git -a v1.1.1 a1b2c3d -m "maquillaje"
git show v1.2.0
git tag -d v1.2.0
git push origin --delete v1.2.0
git describe --tags --always
git submodule add https://github.com/user/lib.git vendor/lib
git submodule update --init --recursive
git clone --recurse-submodules https://github.com/user/repo.git
git submodule update --remote vendor/lib git add vendor/lib && git commit -m "bump lib"
git submodule status
git submodule deinit -f vendor/lib git rm -f vendor/lib rm -rf .git/modules/vendor/lib
git worktree add ../repo-hotfix hotfix/1.2.1 git worktree add -b review ../repo-review origin/pr-42
git worktree list
git worktree remove ../repo-hotfix git worktree prune # Limpiar el registro de directorios eliminados manualmente
git clone --filter=blob:none --sparse <url> cd repo && git sparse-checkout set apps/web packages/ui
git log -p -- src/app.js git log --follow --src/app.js # Seguimiento de cambio de nombre cruzado
git log --grep="iniciar sesión" -i --oneline
git log -S"validateToken" --oneline git log -G"regex" --oneline # Versión normal
git log main..feature --oneline git log origin/main..HEAD # commits que aún no se han enviado
git log --pretty=format:"%h %ad %an %s" --date=short -10
git log --since="2026-09-01" --until="2026-09-09" --oneline
git shortlog -sn --all --no-merges
git blame -L 40,60 src/app.js git culpable -w -C src/app.js # Ignorar espacios en blanco, seguir movimientos
git bisect start git bisect malo # Actualmente malo git bisect good v1.1.0 # Esta versión es buena # Pruebe repetidamente y ejecute git bisect good/bad git bisect reset
git bisect run npm test
git grep -n "TODO" -- "*.ts" git grep "foo" v1.0 # Buscar en una versión determinada
git show HEAD~5:src/config.js > old-config.js
git diff --name-only HEAD~3 HEAD git diff --name-status main # con estado M/A/D
git count-objects -vH
git gc --aggressive --prune=now
Prune en realidad eliminará los objetos inalcanzables y la medicina del arrepentimiento en el reflog desaparecerá junta.
git rev-parse --short HEAD git rev-parse --abbrev-ref HEAD git rev-parse --show-toplevel # Directorio raíz del almacén
git archive -o release.zip v1.2.0 git archive HEAD src/ | tar -x -C /tmp/out
# .gitignore node_modules/ dist/ *.log .env* !.env.example
git check-ignore -v dist/app.js
git rm -r --cached . git add . git commit -m "chore: apply .gitignore"
echo ".DS_Store" >> ~/.gitignore_global git config --global core.excludesFile ~/.gitignore_global
git update-index --skip-worktree config/local.php git update-index --no-skip-worktree config/local.php # Cancelar
* text=auto *.sh text eol=lf *.png binary *.psd filter=lfs diff=lfs merge=lfs -text
git lfs install git lfs track "*.psd" git add .gitattributes
Encadenar varios comandos en una receta de «quiero hacer una cosa»; al desplegarla se copia entera.
El commit fue demasiado pronto / la descripción se escribió incorrectamente / Quiero dividirlo en dos commits (y aún no se ha enviado)
git reset --soft HEAD~1Enviar y retirar, los cambios aún están en el área de preparacióngit statusConfirme que todos los archivos estén en "Cambios a enviar"git commit -m "nueva descripción"Es posible que otros ya lo hayan tomado, la historia no se puede reescribir.
git revert <commit>Generar compromiso inversogit pushEl experimento local está mal y quiero volver por completo a un compromiso determinado.
git log --onelineEncuentre la identificación de commit de destinogit stash -u(Opcional) Contrae los cambios que deseas conservar primerogit reset --hard <commit>Olvidé abrir una rama y la envié N veces.
git branch feature/xCree una rama en la ubicación actual ("guarde" estas commits)git reset --hard origin/mainprincipal regresa al estado remotogit switch feature/xOrganice el historial antes de abrir un PR (la rama no es utilizada por otros)
git rebase -i HEAD~4Cambie la selección en las siguientes líneas para aplastar o arreglargit push --force-with-leaseRequerido sólo si la rama ha sido empujadamain tiene una nueva commit y la rama de funciones debe continuar encima de ella
git fetch origingit switch feature/xgit rebase origin/maino git merge origin/main (mantener commits de fusión)Unificar el nombre de la rama predeterminada
git branch -m master maingit push -u origin maingit push origin --delete masterPrimero, corte la rama predeterminada a principal en la plataforma de alojamiento.Lo encontré útil después de git branch -D
git reflogEncuentre la identificación de el último commit de la rama (como "commit: xxx")git branch <name> <commit-id>.env o cientos de archivos MB ingresados al historial
git rm --cached .env && echo ".env" >> .gitignoreSi solo se realiza el último commit: entonces git commit --amendgit filter-repo --path .env --invert-pathsYa en lo profundo de la historia: reescribe todo el historial con git-filter-repo (debe instalarse por separado)git push --force-with-lease --allTodos los colaboradores deben volver a clonarse; Las claves filtradas deben invalidarse y volverse a emitir de todos modos.Los errores corregidos en main también se trasladarán a la versión 1.2.
git switch release/1.2git cherry-pick <commit>git pushgit merge / pull report CONFLICTO
git statusVea qué documentos fueron "modificados por ambas partes"code <file>Procesar <<<<<<< ======= >>>>>>> etiquetas en el editor, conservando el contenido correctogit add <file>Agregue uno después de que cada uno esté arregladogit commitCuando rebase, git rebase --continuarPrimero escribí el código localmente y luego construí un almacén en GitHub.
git init -b main && git add -A && git commit -m "init"git remote add origin git@github.com:user/repo.gitgit push -u origin mainLos círculos son commits y las flechas apuntan al commit padre; las etiquetas verdes son ramas y la violeta indica la rama donde está HEAD; los círculos grises ya no están referenciados por ninguna rama (recuperables con reflog) y los rellenos son los commits que crea esta operación.
git add . && git commit -m "…"Cada commit recuerda su propio commit padre; una rama no es más que un puntero móvil a un commit, así que al confirmar, main y HEAD avanzan juntos.
git switch -c featureLa nueva rama y main apuntan al mismo commit, por lo que crearla es instantáneo; los commits posteriores en feature solo avanzan feature.
git switch main && git merge featureNo se crea ningún commit nuevo y el historial sigue siendo una línea recta. Para conservar el rastro de que aquí hubo una rama, hay que usar --no-ff.
git merge featureGit busca el ancestro común b2, combina los cambios de cada lado respecto a b2 y crea m6 con dos commits padre. Solo hay conflicto cuando la misma zona cambia de forma distinta.
git switch feature && git rebase mainEl historial se vuelve una línea recta, pero c3 y d4 se sustituyen por los nuevos commits c3′ y d4′ (los id cambian). No se debe hacer rebase de una rama ya publicada, o el historial de los demás divergirá.
git reset --hard HEAD~1--soft solo mueve el puntero; --mixed además vacía la zona de preparación; --hard revierte también el árbol de trabajo. El commit huérfano c3 todavía se puede recuperar desde el reflog (se conserva al menos 30 días por defecto).
git revert HEADc3 sigue en el historial y el nuevo commit r4 contiene la inversa de los cambios de c3. Para deshacer un commit ya publicado, conviene usar revert en lugar de reset.
git cherry-pick x7Reaplica sobre main el cambio que x7 introdujo respecto a su commit padre y produce x7′ con el mismo contenido pero distinto id. Es la forma habitual de llevar una corrección concreta a una rama de publicación.
Un simulador de Git completamente en memoria (no es Git real y no se conecta a la red): admite los subcomandos habituales init / add / commit / branch / switch / merge / rebase / reset / revert / stash / tag / remote / push / pull, y el grafo de la derecha se actualiza en tiempo real. 10 niveles van de «la primera confirmación» a «resolver un conflicto de fusión». La práctica de comandos de Linux está enReferencia de comandos de Linux.