Guía rápida de Git: comandos por tarea
Comandos de Git organizados según lo que quieres hacer: deshacer el último commit, renombrar una rama, eliminar una rama remota. Los comandos modernos switch/restore con sus equivalentes clásicos y avisos de peligro.
Última verificación: 2026-10-18, contrastado con la referencia de git-scm.com para Git 2.56 y el manual de GitHub CLI. Fuentes: Git reference (git-scm.com/docs), git restore, git switch, git reset, git config, GitHub CLI manual.
Configuración (una vez por equipo)
Con --global, los ajustes se guardan en ~/.gitconfig. Desde Git 2.46 la forma documentada es git config set / get / list; la forma clásica sigue funcionando.
git config set --global user.name "Ana Lee" git config set --global user.email "ana@example.com"
Clásico: git config --global user.name "Ana Lee"
Queda registrado en cada commit que hagas. Usa el email que conoce tu servicio de Git para que los commits se vinculen a tu cuenta.
git config set --global init.defaultBranch main
Clásico: git config --global init.defaultBranch main
Sin esto, git init sigue llamando master a la primera rama (y muestra una sugerencia).
git config set --global core.editor "code --wait"
Clásico: git config --global core.editor "code --wait"
Sirve cualquier comando que espere hasta que se cierre el archivo: "nano", "vim", "subl -n -w".
git config set --global core.autocrlf true # Windows git config set --global core.autocrlf input # macOS, Linux
Clásico: git config --global core.autocrlf true
Guarda LF en los commits y extrae CRLF en Windows. Para todo un equipo, un archivo .gitattributes con "* text=auto" es más fiable que los ajustes de cada persona.
git --version
git switch y git restore necesitan 2.23+, y los subcomandos de git config, 2.46+.
Crear un repositorio
git init
git init -b main # name the first branchCrea un directorio .git. Añade un .gitignore antes del primer commit para que nunca entren archivos compilados ni secretos.
git clone https://github.com/owner/repo.git git clone git@github.com:owner/repo.git my-folder
Descarga todo el historial y configura el remoto "origin". La segunda forma usa SSH y un nombre de carpeta propio.
git clone --depth 1 https://github.com/owner/repo.git
Omite el historial; útil para CI y repositorios grandes. git fetch --unshallow trae el resto más tarde.
git remote add origin git@github.com:owner/repo.git git push -u origin main
Crea antes el repositorio vacío en el servicio (o usa gh repo create, más abajo). -u recuerda origin/main como upstream.
Preparar y confirmar (stage y commit)
git status
git status -s # short formLista los archivos preparados, sin preparar y sin seguimiento, y sugiere el siguiente comando.
git add file.txt
git add . # everything in this folder and belowgit add -A también prepara los borrados en todo el repositorio.
git add -p file.txt
Recorre cada cambio ("hunk"): y para prepararlo, n para saltarlo, s para dividirlo, e para editarlo.
git commit -m "Add login form"
git commit -am "Fix typo" # stage tracked files and commit-a incluye los archivos con seguimiento modificados y borrados, nunca los nuevos.
git mv old.txt new.txt git rm file.txt
Ambos preparan el cambio por ti. Git detecta los renombrados por el contenido, así que un mv normal más git add también funciona.
git rm --cached .env echo ".env" >> .gitignore
Lo quita del repositorio a partir del siguiente commit. Sigue en los commits anteriores: si contenía un secreto, cámbialo.
Ramas
git branch git branch -a # include remote branches git branch -vv # show upstream and ahead/behind
La rama actual aparece marcada con *.
git switch -c feature/login
Clásico: git checkout -b feature/login
Parte del commit actual; añade un punto de partida para crearla desde otro sitio: git switch -c hotfix origin/main.
git switch main
git switch - # back to the previous branchClásico: git checkout main
Si solo existe origin/feature, git switch feature crea automáticamente una rama local que la sigue.
git branch -m new-name # current branch
git branch -m old-name new-nameSolo la renombra en local. Para renombrarla también en el remoto, mira la siguiente entrada.
git branch -m old-name new-name git push -u origin new-name git push origin --delete old-name
No existe el renombrado remoto: sube el nombre nuevo y elimina el antiguo. Las pull requests abiertas sobre el nombre antiguo pueden cerrarse; el botón de renombrar de la web de GitHub las redirige.
git branch -d feature/login
git branch -D feature/login # even if unmerged-d se niega si la rama tiene commits sin fusionar en su upstream o en HEAD; -D la elimina de todos modos.
Recuperación: Los commits sin fusionar siguen en el reflog: git reflog, busca la punta y luego git branch feature/login <sha>.
git push origin --delete feature/login
Clásico: git push origin :feature/login
Tus compañeros la seguirán viendo hasta que ejecuten git fetch --prune.
Recuperación: Cualquiera que tenga la rama en local (o tú, mediante git reflog) puede volver a subirla.
git branch -u origin/main
git push -u origin HEAD # push current branch and track itClásico: git branch --set-upstream-to=origin/main
El upstream es lo que usan git pull y git push sin argumentos.
git switch --detach a1b2c3d
git switch -c rescue # keep work made thereClásico: git checkout a1b2c3d
Los commits hechos con HEAD desacoplado no pertenecen a ninguna rama; crea una antes de cambiarte o solo se podrán alcanzar mediante el reflog.
Merge, rebase y cherry-pick
git switch main
git merge feature/login
git merge --no-ff feature/login # always create a merge commitHace fast-forward cuando puede; --no-ff mantiene la rama visible en el historial.
git merge --squash feature/login git commit -m "Add login"
Prepara los cambios combinados sin registrar un merge; después la rama no aparece como fusionada.
git status # list conflicted files # edit the files, remove <<<<<<< ======= >>>>>>> markers git add file.txt git commit # or: git rebase --continue
Quédate con un lado entero con git restore --ours file.txt o --theirs. Durante un rebase, "ours" es la rama sobre la que se hace el rebase, al revés que en un merge.
git merge --abort
Vuelve al estado anterior al inicio del merge.
Recuperación: Se pierden las resoluciones de conflictos que hayas hecho. Si tenías cambios sin confirmar al empezar el merge, puede que --abort no pueda restaurarlos, así que haz commit o stash antes de fusionar.
git switch feature/login git rebase main
Vuelve a aplicar tus commits encima de main para tener un historial lineal. Resuelve los conflictos, git add y luego git rebase --continue; --abort lo cancela.
Recuperación: Justo después: git reset --hard ORIG_HEAD. Más tarde: busca la punta antigua en git reflog.
git rebase -i HEAD~3
Abre una lista: cambia pick por squash/fixup para combinar, reword para editar un mensaje, drop para borrar, o reordena las líneas.
Recuperación: git reflog muestra el commit anterior al rebase; git reset --hard <sha> lo restaura.
git commit --fixup=a1b2c3d git rebase -i --autosquash a1b2c3d~1
El commit fixup se integra automáticamente en a1b2c3d al hacer rebase.
Recuperación: Igual que con el rebase interactivo: git reflog.
git pull --rebase
git config set --global pull.rebase true # make it the defaultHace rebase de tus commits locales encima de lo descargado.
git cherry-pick a1b2c3d
git cherry-pick -x a1b2c3d # note the source in the messageCrea un commit nuevo con los mismos cambios. Un rango: git cherry-pick A..B (excluye A).
Remotos: fetch, pull, push
git remote -v git remote set-url origin git@github.com:owner/repo.git
set-url cambia un clon de HTTPS a SSH (o a un repositorio renombrado).
git fetch
git fetch --prune # also drop deleted remote branchesSolo actualiza origin/*; tus ramas no se tocan.
git pull
git fetch más merge (o rebase, si pull.rebase está configurado).
git push
git push -u origin HEAD # first push of a new branch
git config set --global push.autoSetupRemote trueCon push.autoSetupRemote (Git 2.37+), un simple git push en una rama nueva configura el upstream por sí solo.
git push --force-with-lease
A diferencia de --force, se niega si el remoto tiene commits que no has descargado. Añade --force-if-includes (Git 2.30+) para más seguridad si hay fetch en segundo plano.
Recuperación: Los commits remotos sobrescritos sobreviven en el reflog de quien los tuviera, y GitHub los mantiene accesibles por SHA durante un tiempo.
git remote add upstream https://github.com/original/repo.git git fetch upstream git switch main git merge upstream/main
O con GitHub CLI: gh repo sync.
Deshacer cosas
Elige según dónde esté el error: en el directorio de trabajo, en el área de preparación, en un commit local o en un commit ya subido. Casi todo lo que alguna vez se confirmó se puede recuperar con git reflog; los cambios sin confirmar que descartes, no.
git reset --soft HEAD~1
El commit desaparece; sus cambios quedan preparados, listos para volver a confirmarlos. Usa git reset HEAD~1 (sin --soft) para dejarlos sin preparar.
Recuperación: git reset ORIG_HEAD recupera el commit. Si ya estaba subido, usa git revert.
git reset --hard HEAD~1
Retrocede la rama un commit y deja todos los archivos con seguimiento igual que en él.
Recuperación: El commit está en git reflog (las entradas inalcanzables caducan a los 30 días por defecto): git reset --hard HEAD@{1}. Los cambios sin confirmar en archivos con seguimiento se pierden para siempre.
git revert a1b2c3d
git revert HEAD # the latest commitAñade un commit nuevo que invierte el anterior, así que el historial de nadie cambia. Es la forma segura de deshacer en ramas compartidas.
git revert -m 1 <merge-sha>
-m 1 conserva el primer padre (normalmente main). Para volver a fusionar la rama más adelante, primero hay que revertir este revert.
git commit --amend -m "Better message"
Sustituye el último commit por uno nuevo. Sin problema antes de hacer push; después necesita --force-with-lease.
Recuperación: git reset --soft HEAD@{1} vuelve al commit anterior al amend.
git add forgotten.txt git commit --amend --no-edit
Mantiene el mensaje y añade el archivo.
Recuperación: git reset --soft HEAD@{1}.
git restore --staged file.txt
git restore --staged . # everythingClásico: git reset HEAD file.txt
Los cambios se quedan en el directorio de trabajo; solo se deshace la preparación.
git restore file.txt
Clásico: git checkout -- file.txt
Devuelve el archivo a la versión preparada (o al último commit si no hay nada preparado).
Recuperación: Git no puede recuperarlos: los cambios nunca se confirmaron. Puede que el historial local de tu editor aún los tenga.
git restore --staged --worktree .
git clean -fd # also delete untracked filesClásico: git reset --hard
git clean -fd
Vuelve al último commit. Ejecuta antes git clean -n para ver qué se borraría.
Recuperación: No se puede recuperar: se borran los cambios sin confirmar y los archivos sin seguimiento. git stash -u es la alternativa reversible.
git restore file.txt # deletion not committed git restore --source=a1b2c3d~1 file.txt # deleted in commit a1b2c3d
Clásico: git checkout a1b2c3d~1 -- file.txt
Encuentra el commit que lo borró con git log --diff-filter=D -- file.txt.
git restore --source=main -- config.yml
Clásico: git checkout main -- config.yml
Solo sobrescribe la copia de trabajo; añade --staged --worktree para prepararlo también. Para solo mirarlo: git show main:config.yml.
Recuperación: Se sobrescriben los cambios sin confirmar de ese archivo.
git reflog git branch rescued a1b2c3d
El reflog registra cada sitio por el que ha pasado HEAD. Busca el SHA de antes del error y crea una rama en él.
git reset --hard ORIG_HEAD
merge, rebase y reset fijan ORIG_HEAD en el punto donde estabas antes. El siguiente comando de ese tipo lo sobrescribe.
Recuperación: git reflog sigue mostrando el commit de merge.
git reflog # find "rebase (start)"; the entry below it is the old tip
git reset --hard HEAD@{5}Justo después del rebase, git reset --hard ORIG_HEAD hace lo mismo.
Recuperación: --hard descarta los cambios sin confirmar; guárdalos antes con stash.
git reset --hard HEAD@{1}HEAD@{1} es donde estaba HEAD antes del último movimiento. Solo funciona con trabajo confirmado.
git filter-repo --invert-paths --path secrets.env
git filter-repo es una herramienta aparte (pip install git-filter-repo), recomendada por la documentación de git-filter-branch. Después, todos los clones tienen que volver a clonar. Cambia el secreto de todos modos: fue público desde el momento en que se subió.
Recuperación: filter-repo trabaja sobre un clon nuevo; conserva el clon antiguo hasta que estés seguro.
Stash
git stash
git stash push -m "half-done login"
git stash -u # include untracked filesGuarda los cambios con seguimiento y limpia el directorio de trabajo para que puedas cambiar de rama.
git stash pop # apply and drop git stash apply stash@{1} # apply, keep the stash
Puede haber conflictos; con pop, el stash se conserva si falla al aplicarse.
git stash list
git stash show -p stash@{0}Del más reciente al más antiguo; stash@{0} es el último.
git stash push -- src/login.ts
git stash push --staged # only what is staged (2.35+)Los stashes limitados a rutas dejan todo lo demás donde está.
git stash branch feature/login stash@{0}Crea la rama en el commit donde hiciste el stash, lo aplica y lo elimina; así se evitan conflictos.
git stash drop stash@{0}
git stash clearclear elimina todos los stashes.
Recuperación: Un stash eliminado es un commit inalcanzable hasta la recolección de basura: git fsck --unreachable | grep commit y luego git stash apply <sha>.
Historial y diffs
git log --oneline --graph --all
Una línea por commit con la estructura de ramas. En versiones muy antiguas de Git, añade --decorate para ver los nombres de las ramas.
git log --follow -p -- path/file.txt
--follow sigue a través de los renombrados; -p muestra cada cambio.
git log -S "functionName" --oneline git log -G "regex" --oneline
-S detecta cambios en el número de apariciones; -G compara cada línea cambiada con una regex.
git log --author="Ana" --since="2 weeks ago" --oneline
También --until, --grep="fix" para los mensajes, y main..feature para los commits que están en feature pero no en main.
git show a1b2c3d git show a1b2c3d:path/file.txt
La segunda forma muestra el archivo tal como estaba en ese commit sin tocar tu copia.
git diff # unstaged git diff --staged # staged, i.e. what will be committed
--stat resume por archivo; --word-diff va mejor para texto en prosa.
git diff main...feature # changes on feature since it branched git diff main feature # the two tips directly
Los tres puntos comparan con la base de merge, que es lo que muestra una pull request.
git blame -L 10,20 path/file.txt
Añade -w para ignorar los espacios en blanco y -C para seguir líneas movidas desde otros archivos.
git bisect start git bisect bad # current commit is broken git bisect good v1.4.0 # this one worked # test, then mark each step good or bad git bisect reset
Búsqueda binaria: unos log2(n) pasos. git bisect run ./test.sh lo automatiza.
git grep -n "TODO"
Más rápido que grep en repositorios grandes y se salta los archivos ignorados. Añade un commit para buscar en una versión antigua.
Tags y versiones
git tag -a v1.2.0 -m "Release 1.2.0"
git tag -a v1.1.1 a1b2c3d -m "Hotfix" # tag an older commitLos tags anotados (-a) guardan autor, fecha y mensaje; úsalos para las versiones. git tag v1.2.0 a secas crea un tag ligero.
git tag -d v1.2.0 git push origin --delete v1.2.0
Evita reutilizar el nombre de un tag de versión eliminado: los otros clones conservan el tag antiguo.
Recuperación: El commit etiquetado no se ve afectado; vuelve a crear el tag en él.
Submódulos y worktrees
git submodule add https://github.com/owner/lib.git vendor/lib git commit -m "Add lib submodule"
Registra la URL en .gitmodules y fija un commit exacto del otro repositorio.
git clone --recurse-submodules <url>
git submodule update --init --recursive # already clonedSin esto, las carpetas de los submódulos están vacías.
git submodule update --remote git commit -am "Bump submodules"
Descarga la rama que sigue cada submódulo; confirma los nuevos commits fijados en el repositorio padre.
git worktree add ../repo-hotfix hotfix git worktree add -b review ../repo-review origin/main
Una segunda carpeta de trabajo que comparte el mismo repositorio; sin stash ni un segundo clon.
git worktree list
git worktree remove ../repo-hotfix
git worktree prune # forget folders deleted by handremove se niega si el worktree tiene cambios sin confirmar (usa --force para forzarlo).
Limpieza
git clean -n -d
Ejecútalo siempre antes de git clean -f.
git clean -fd # untracked files and folders git clean -fdx # also ignored files (build output, .env!)
-x también elimina los archivos ignorados, lo que incluye configuración local como .env.
Recuperación: No se puede recuperar: estos archivos nunca estuvieron en Git.
git branch --merged main git branch -d branch-a branch-b
Revisa antes la lista; -d se niega con las ramas sin fusionar, así que es seguro probarlo.
git fetch --prune git config set --global fetch.prune true
Elimina las referencias origin/* cuyas ramas se borraron en el servidor.
git maintenance start git gc
maintenance start programa tareas en segundo plano de prefetch, commit-graph y repack; gc empaqueta los objetos y elimina ya los inalcanzables.
Configuración y alias
git config list --show-origin
Clásico: git config --list --show-origin
Muestra los valores del sistema, globales y del repositorio con el archivo en el que está cada uno.
git config set --global alias.st "status -s" git config set --global alias.lg "log --oneline --graph --all"
Clásico: git config --global alias.st "status -s"
Después, git st y git lg. Ponle delante ! para ejecutar un comando de shell: alias.root "!pwd".
git config set --global pull.rebase true git config set --global push.autoSetupRemote true git config set --global rerere.enabled true git config set --global merge.conflictStyle zdiff3 git config set --global diff.algorithm histogram
Clásico: git config --global pull.rebase true
Rebase al hacer pull; upstream automático en el primer push (2.37+); recordar resoluciones de conflictos; mostrar el ancestro común en los conflictos (2.35+); diffs más claros.
git config set --global core.excludesFile ~/.gitignore_global
Clásico: git config --global core.excludesFile ~/.gitignore_global
Para la basura del sistema operativo y del editor (.DS_Store, .idea/). Las reglas propias del proyecto van en el .gitignore del repositorio.
Lo básico de GitHub CLI (gh)
gh es la herramienta de línea de comandos oficial de GitHub, que se instala aparte de Git.
gh auth login
gh auth setup-git # let git use gh for HTTPS credentialsAbre un navegador o acepta un token; funciona con github.com y GitHub Enterprise.
gh repo create my-app --private --source=. --push
Crea el repositorio, lo añade como origin y sube la rama actual.
gh repo clone owner/repo
En un fork, añade además el repositorio padre como remoto upstream.
gh pr create --fill gh pr create --draft --title "WIP: login" --body "…"
--fill usa los mensajes de commit para el título y la descripción.
gh pr checkout 123
Descarga la rama de la PR (también desde forks) y se cambia a ella.
gh pr list gh pr view 123 --web gh pr merge 123 --squash --delete-branch
gh pr status muestra las PR que te afectan.
gh issue create --title "Bug: …" --body "…" gh issue list --assignee @me
gh issue view 42 --comments lee un hilo en el terminal.
gh run list gh run watch
gh run view --log-failed muestra solo los pasos que fallan.
¿Necesitas un .gitignore de partida? Usa el generador de .gitignore. ¿Comparas dos versiones de un archivo fuera de Git? El comparador de textos muestra los cambios lado a lado.
Una referencia estática: la búsqueda se ejecuta en tu navegador y nada de lo que escribes se envía a ningún sitio. Ver todas las herramientas gratis.
¿Encontraste un problema o algo que podría mejorar? Leemos todos los mensajes y lo arreglamos rápido.
Esta guía rápida de Git está organizada por tareas y no por comandos, porque nadie busca “git reset --soft”; busca “deshacer el último commit”. Encuentra lo que intentas hacer, copia el comando y lee la explicación de una línea sobre lo que cambia. La búsqueda prioriza las tareas, así que “eliminar rama remota” o “renombrar rama” te llevan directamente a la entrada correcta.
Los comandos que reescriben el historial o tiran trabajo a la basura están marcados, con una nota sobre lo que se puede recuperar: casi todo lo que alguna vez se confirmó con commit se puede volver a encontrar con git reflog, mientras que los cambios sin confirmar que descartas con restore, reset --hard o clean se pierden. Cuando Git tiene ahora un comando más claro (git switch y git restore desde la 2.23, git config set y list desde la 2.46), se muestra primero, con la forma clásica al lado, así que la guía te sirve tanto si tu equipo aprendió Git el año pasado como en 2010. Comprobada con la referencia de git-scm.com para Git 2.56.
Cómo usarla
- Escribe lo que quieres hacer en el cuadro de búsqueda, como “deshacer último commit”, “quitar del stage” o “combinar commits”, o haz clic en una de las tareas habituales.
- Lee los avisos antes de ejecutar nada: ámbar significa que el comando reescribe el historial y rojo, que puede descartar trabajo. La nota de recuperación explica cómo volver atrás.
- Haz clic en Copiar comando. La copia omite los comentarios # para que se pegue limpia en un terminal; sustituye los marcadores como a1b2c3d o feature/login por los tuyos.
- Comparte una respuesta concreta con el enlace # junto a cada tarea o imprime la guía completa como PDF a dos columnas.
Preguntas frecuentes
¿Cómo deshago el último commit en Git?
Si no lo has subido con push, git reset --soft HEAD~1 elimina el commit y mantiene sus cambios en el área de preparación (stage), y git reset HEAD~1 los mantiene fuera de ella. git reset --hard HEAD~1 elimina el commit y sus cambios. Si el commit ya está subido a una rama compartida, usa git revert HEAD, que añade un commit nuevo que lo deshace sin reescribir el historial de nadie.
¿Qué diferencia hay entre git reset, git restore y git revert?
git restore cambia archivos: descarta los cambios del directorio de trabajo o los quita del stage, y nunca mueve una rama. git reset mueve la rama actual a otro commit (y con --hard también sobrescribe tus archivos), así que reescribe el historial. git revert crea un commit nuevo que aplica lo contrario de uno anterior; el historial solo crece, por eso es la opción segura en ramas que usan otras personas.
¿Cómo renombro una rama de Git, en local y en el remoto?
git branch -m nuevo-nombre renombra la rama en la que estás (git branch -m vieja nueva para otra). Los remotos no tienen una operación de renombrar, así que sube el nuevo nombre con git push -u origin nuevo-nombre y elimina el antiguo con git push origin --delete nombre-antiguo. En GitHub, renombrar la rama desde la interfaz web también redirige los pull requests abiertos.
¿Debo usar git switch o git checkout?
Los dos funcionan. git checkout hace dos trabajos que no tienen nada que ver, cambiar de rama y restaurar archivos; por eso Git 2.23 los separó en git switch y git restore. Los comandos nuevos son más claros y es más difícil usarlos mal (git checkout -- archivo descarta cambios sin avisar), así que esta guía los muestra primero. git checkout no está obsoleto y cada comando de esta página indica su equivalente clásico.
¿Puedo recuperar un commit después de git reset --hard?
Normalmente sí. Ejecuta git reflog, busca la línea de antes del reset y ejecuta git reset --hard HEAD@{n} o crea una rama en ese SHA. Por defecto, los commits siguen siendo accesibles a través del reflog durante 30 días cuando ya nada más apunta a ellos. Lo que no se puede recuperar es el trabajo sin confirmar: los cambios que nunca se confirmaron ni se guardaron con stash se sobrescriben para siempre.
¿Qué hace git push --force-with-lease?
Sobrescribe la rama remota solo si el remoto sigue apuntando donde lo vio tu último fetch. Si alguien hizo push entretanto, el push se rechaza en lugar de borrar sus commits sin avisar, que es lo que hace --force a secas. Úsalo después de un rebase o un amend en una rama que ya habías subido.
¿Qué comando para deshacer? Decide según dónde esté el cambio
• Editaste un archivo y quieres eliminar el cambio: git restore archivo. No se puede recuperar, porque nunca se confirmó.
• Añadiste algo al stage por error: git restore --staged archivo. No se pierde nada; el cambio sigue en el archivo.
• Confirmado pero sin subir: git reset --soft HEAD~1 para rehacer el commit, o git commit --amend para corregirlo directamente.
• Confirmado y subido a una rama compartida: git revert <sha>. No hagas reset de una rama que otras personas ya han descargado.
• Perdiste un commit, una rama o el resultado de un rebase fallido: git reflog y después git branch rescatada <sha>.
La regla de fondo: cualquier cosa que reescriba commits está bien mientras los commits sean solo tuyos, y pasa a ser un problema de todos en cuanto se comparten.
¿Merge o rebase?
Los dos llevan los cambios de una rama a otra. Un merge registra que se unieron dos historiales, con un commit de merge que tiene dos padres; no se reescribe nada, así que siempre es seguro en ramas compartidas. Un rebase vuelve a aplicar tus commits encima de la otra rama, lo que da un historial en línea recta como si hubieras empezado desde el último commit, pero crea nuevos identificadores de commit, así que quien ya tenga los antiguos tendrá que conciliarlos.
Una convención habitual en los equipos: haz rebase de tu rama de funcionalidad sobre main para mantenerla al día (git pull --rebase o git rebase main), e integra la rama terminada en main mediante un pull request. El squash merge deja un commit por funcionalidad en main; los merges normales conservan todos los commits y la forma de la rama. Elige uno por repositorio y configúralo en los ajustes de la plataforma, para que el historial sea coherente.
Ajustes de Git que vale la pena cambiar respecto a los valores por defecto
• pull.rebase true: git pull hace rebase en lugar de crear commits de merge en cada sincronización.
• push.autoSetupRemote true (Git 2.37+): el primer git push de una rama nueva configura su upstream, sin necesidad de -u.
• merge.conflictStyle zdiff3 (Git 2.35+): los marcadores de conflicto incluyen el ancestro común, lo que hace evidentes la mayoría de los conflictos.
• rerere.enabled true: Git recuerda cómo resolviste un conflicto y vuelve a aplicarlo cuando el mismo conflicto reaparece durante un rebase.
• fetch.prune true: las ramas remotas eliminadas en el servidor desaparecen en local en el siguiente fetch.
• init.defaultBranch main: los repositorios nuevos empiezan en main.
Herramientas gratis relacionadas
- Generador de .gitignore — Combina plantillas de .gitignore para lenguajes, frameworks, editores y sistemas operativos en un solo archivo limpio.
- Comparador de textos — Compara dos versiones de un texto, código o archivo JSON y ve exactamente qué líneas, palabras y caracteres cambiaron.
- Guía rápida de Markdown — Todos los elementos de Markdown con su código y su vista previa, la sintaxis extendida (tablas, listas de tareas, notas al pie, fórmulas matemáticas, Mermaid, alertas), una tabla de compatibilidad con 9 plataformas y un editor de prueba en vivo.
- Guía rápida de regex — Todos los tokens de expresiones regulares con un ejemplo que funciona, su compatibilidad en JavaScript, PCRE/PHP, Python, Go, Java y .NET, y un enlace Pruébalo que abre el probador de regex ya relleno.