Hasta ahora todo tu historial vive en una carpeta de tu computador. Eso basta para trabajar, pero deja dos agujeros: si el disco se daña se pierde todo, y no hay forma de que otra persona colabore.
Un remoto es una copia del repositorio en otro sitio -GitHub, GitLab, o un servidor de la empresa- con la que la tuya se sincroniza cuando tú lo pides. No es una nube que copia archivos sola: subir y bajar son comandos explícitos.
Antes de subir nada, mira otra vez tu .gitignore.
Un repositorio local con una contraseña dentro es un descuido; el mismo repositorio
publicado en internet es una credencial regalada, y hay programas que recorren
GitHub buscando exactamente eso. Si el repositorio va a ser público, revisa el
historial completo, no solo los archivos de hoy.
Este es el muro donde se atasca todo el mundo la primera vez. Haces el
primer push, Git pide usuario y Password, escribes la
contraseña de tu cuenta de GitHub y falla. Y como el mensaje no lo explica, la
conclusión natural es que te equivocaste al teclear.
No te equivocaste. La documentación oficial de GitHub lo dice sin rodeos: «Password-based authentication for Git has been removed in favor of more secure authentication methods». La contraseña de la cuenta no se acepta para operaciones de Git.
Una clave larga que generas en la configuración de tu cuenta y que se escribe en el sitio donde Git pide la contraseña.
Se le dan solo los permisos que necesita y una fecha de caducidad. Si se filtra, se revoca ese token y ya: la cuenta no se toca.
Un par de llaves -una pública que subes a GitHub y una privada que nunca sale de tu equipo-.
Es lo más cómodo a diario: una vez configurada, no te vuelve a pedir nada. Es la misma idea que se usa para entrar a un servidor.
El programa gh. Con gh auth login abre el
navegador, te autenticas ahí y él se encarga de guardar las credenciales.
Es el camino más corto si estás empezando y no quieres pelear con llaves.
Da igual cuál elijas: el resto de la lección funciona idéntico con las tres. Lo que no funciona es la contraseña de la cuenta. Si Git te la vuelve a pedir cada vez, es que no hay ningún gestor de credenciales guardándola; en Windows, el instalador de Git trae uno activado por defecto.
O el repositorio ya existe en GitHub y lo traes, o existe en tu equipo y lo subes. Son dos comandos distintos y confundirlos es el segundo tropiezo típico.
git clone https://github.com/empresa/plantillas-cotizacion.git
cd plantillas-cotizacionCloning into 'plantillas-cotizacion'... remote: Enumerating objects: 47, done. Receiving objects: 100% (47/47), 12.31 KiB, done.
clone se ejecuta una sola vez por proyecto, y
te trae el historial completo: todos los commits, todas las ramas. No es «descargar
los archivos»; es duplicar el repositorio entero, incluido lo que pasó hace tres
años.
En la web, New repository. Sin marcar que
añada README ni .gitignore: si lo haces, GitHub crea un commit
que tu repositorio no tiene y el primer push es rechazado.
git remote add origin https://github.com/tu-usuario/plantillas-cotizacion.git
origin es solo un apodo -el habitual- para esa dirección. Con
git remote -v compruebas que quedó bien.
git branch. Si dice master y en GitHub la
principal es main, renómbrala ahora:
git branch -M main.
Es exactamente el choque que anticipamos en la lección 1 con
init.defaultBranch.
git push -u origin main
El -u deja emparejada tu rama con la del remoto. A partir de
ahí basta con git push, sin más palabras.
# Traer lo que hicieron otros ANTES de ponerte a trabajar
git pull
# ... trabajas, add y commit como siempre ...
# Subir lo tuyo
git push
# Mirar si hay novedades SIN tocar tu carpeta
git fetch
git log --oneline HEAD..origin/mainSon parecidos y no son lo mismo, y entenderlo ahorra bastantes disgustos:
fetch se entera, pull se entera y además
fusiona.
git fetch baja lo que hay en el servidor y lo deja aparte, sin tocar
tus archivos ni tu rama: puedes mirar qué llegó antes de aceptarlo. git
pull hace eso mismo y a continuación lo mezcla con tu trabajo, que es cuando
pueden aparecer conflictos.
El hábito que menos conflictos produce: git
pull antes de empezar a trabajar, no cuando ya llevas dos horas y quieres
subir. Cuanto más viejo sea tu punto de partida, más grande es la fusión y más
probable el choque.
Alguien subió algo que tú no tienes. El servidor no deja sobrescribirlo, y hace bien.
Se arregla con git pull, resolver lo que haga falta y volver
a push. Nunca con push --force:
eso borra el trabajo del otro.
Es el muro del principio de la lección. Estás escribiendo la contraseña de la cuenta donde va un token de acceso personal.
Genera el token en GitHub y pégalo en el hueco de Password. Si Windows guardó la contraseña mala, hay que borrarla del Administrador de credenciales o seguirá reintentándola sola.
Estás intentando subir una rama que no existe. Casi siempre porque todavía no hiciste ningún commit, y sin commits no hay rama.
git log lo confirma en un segundo.
Creaste el repositorio en GitHub con README y en tu equipo con commits: son dos historias que no tienen ningún commit en común.
Se junta con git pull --allow-unrelated-histories, o se evita
creando el repositorio vacío como decía el paso 1.
En un equipo, casi nadie sube directamente a la rama principal. El camino normal es: subes tu rama, abres una pull request en la web, alguien la revisa y comenta, y solo entonces se fusiona.
La pull request no es una función de Git -es de GitHub-, pero es donde ocurre la revisión, la discusión y la aprobación. En un repositorio serio es el único camino hacia la rama principal.
git switch -c feature/cotizacion-por-zonas
# ... trabajas y haces commits ...
git push -u origin feature/cotizacion-por-zonasremote: Create a pull request for 'feature/cotizacion-por-zonas' on GitHub by visiting: remote: https://github.com/empresa/plantillas-cotizacion/pull/new/feature/cotizacion-por-zonas
Git te pide Password al hacer push y tu contraseña de GitHub falla. ¿Qué pasa?
¿Cuál es la diferencia entre fetch y pull?
fetch te deja mirar qué llegó antes de aceptarlo.
pull es fetch más la fusión, y por eso es el que
puede producir conflictos.Tu push es rechazado con non-fast-forward. ¿Qué haces?
--force lo borraría: es cómo se pierde el trabajo de un
compañero.Ya subes y bajas trabajo. Falta lo que pasa cuando dos personas tocaron las mismas líneas: el conflicto. Suena a catástrofe y es una situación normal y perfectamente manejable, siempre que sepas leer lo que Git te deja escrito en el archivo.
Siguiente: Fusionar y resolver conflictos
Continuar ← Deshacer sin romper nada