Guía de Git de Beej

 (beej.us)
1 puntos por GN⁺ 2025-02-06 | 1 comentarios | Compartir por WhatsApp
  • Es una página de guía que ofrece distribuciones en HTML y PDF en varios formatos para lectores que quieren aprender Git o consultarlo como referencia
  • La guía en sí parte de la premisa de que puede contener errores, y acepta sugerencias de corrección por correo electrónico para contenido incorrecto sobre Git
  • Las distribuciones HTML se pueden elegir según el entorno de lectura: versión dividida, página única, widescreen, ZIP, etc.
  • Los PDF se pueden descargar en combinaciones de US Letter y A4, una o dos caras, con resaltado de sintaxis o en blanco y negro
  • Traductores y autores pueden clonar todo el material desde GitHub y trabajar siguiendo el README

Formatos de distribución para lectura

Sugerencias de corrección y material fuente de trabajo

  • La guía deja abierta la posibilidad de que haya errores, y las sugerencias de corrección se reciben por correo electrónico
  • Traductores y autores pueden clonar el repositorio de GitHub y seguir el README

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-02-06
Opiniones en Hacker News

  • Si encuentran algún error, súbanlo. Lo revisaré y lo corregiré yo mismo — Beej

    • No es un error, pero si vas a tratar vim en el contexto de Git, también valdría la pena incluir :cq. Permite salir con un estado de salida distinto de cero, para que Git no pueda completar el commit o la operación
    • De verdad, excelente trabajo, y gracias por crear un recurso tan completo. No lo leí todo, pero me llamó la atención la redacción de la sección 5.1
      En https://beej.us/guide/bggit/html/split/branches-and-fast-for... dice que “la rama predeterminada es main” y que “antes era master, y los repositorios antiguos todavía tienen master”, pero eso no es correcto. Git sigue usando master como valor predeterminado, y solo permite cambiarlo para futuros git init con git config --global init.defaultBranch
      Fuente: https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...
      Además, la expresión “repositorios antiguos” transmite un mensaje equivocado. GitHub decidió este cambio y otros lo siguieron, y Git en sí pasó a permitir la configuración mencionada; no es una cuestión de repositorios nuevos o antiguos, sino más bien de preferencia
    • Fui uno de los muchos estudiantes que aprendieron en Lambda School, y esa clase fue uno de los momentos que más me marcaron
    • Leí la guía de programación en C cuando era adolescente, y ahora, como desarrollador de firmware, todavía siento que le debo muchísimo
    • No es un error, pero también valdría la pena mencionar git worktree. Fue clave en mi flujo de trabajo, y mucha gente ni siquiera sabe que existe
      Es una buena forma de mantener las ramas sin enredarse entre sí, sin la molestia de lidiar con stash

  • Beej's Guide to Network Programming y Beej's Guide to Unix IPC, que leí cuando era adolescente, eran accesibles pero también profundos, e influyeron mucho en el tipo de programador en el que me convertí después
    [0] https://beej.us/guide/bgnet/
    [1] https://beej.us/guide/bggit/

    • [1] es https://beej.us/guide/bgipc/
    • A mí me pasó algo parecido. Era adolescente a mediados de los 90 y me fascinaban el código de servidores IRCd y los bots
      Compré usado Slackware Linux Unleashed con un CD-ROM incluido; traía ejemplos de networking en C, y como ese código me confundía terminé encontrando el sitio de networking de Beej. Ahí me enganché más y me fui metiendo en una madriguera profunda, recorriendo varias librerías en busca de libros de programación
      Después de comprar el excelente libro de referencia de Richard Stevens, ya no hubo vuelta atrás, y hasta hoy le agradezco a Beej por haber hecho posible esa pasión
    • Recuerdo que, cuando estaba aprendiendo a usar select, quería hacer más rápido un escáner de puertos (¿quizá “grabb”?) y traduje al italiano la guía de redes de Beej. Eran buenos tiempos
    • Vine a confirmar si era la misma persona, y al ver ese viejo diseño web en el que cada página tenía personalidad, quedé casi seguro
      Eran los tiempos en que guardaba las páginas para leerlas sin conexión y que mi papá no se enojara por la cuenta del teléfono; cuando el código funcionaba, se sentía como una validación que superaba los fracasos y rechazos anteriores de la vida. Era enorme la alegría de enviar un mensaje de una computadora a otra

  • Al ver “comando antiguo: git checkout”, ni siquiera sabía que existía git switch, ni que git checkout se considerara una alternativa antigua. Me siento viejo
    Empecé a aprender Git hace casi 10 años, así que supongo que tiene sentido, pero se siente raro pensar que alguien que aprende Git hoy podría confundirse por qué uso git checkout. Es como hablar con expresiones pasadas de moda
    Volviendo al texto, creo que esta guía me habría sido realmente útil cuando estaba aprendiendo. Es fácil de seguir y cubre bien las preguntas comunes
    También recuerdo con cariño cuando me asusté con mi primer conflicto de merge, me detuve y luego busqué rodeos para evitar conflictos

    • git switch es un comando bastante nuevo y se lanzó por primera vez en 2019
      Hay discusiones de 2021 y de hace unas semanas, respectivamente, y en la segunda también se menciona que, según la documentación, git switch todavía se considera una función experimental
      https://news.ycombinator.com/item?id=28024972
      https://news.ycombinator.com/item?id=42649858
    • No creo que git checkout todavía se considere una “alternativa antigua”. La última vez que revisé, switch seguía siendo experimental, y nunca se me ocurrió apartarme del flujo de trabajo y los comandos que aprendí cuando empecé con Git hace unos 15 años
      Todo lo que quiero hacer sigue funcionando igual, git checkout sigue haciendo lo mismo de siempre, y no tengo problemas para colaborar con otras personas usando Git; entonces, ¿para qué cambiar mi flujo de trabajo?

  • El solo hecho de que haga falta una guía de más de 30 partes para explicar cómo usar Git hace sentir que Git se perdió el panorama general.

    • No entiendo por qué los programadores se enfurecen tanto ante el hecho de que una herramienta compleja que hace cosas complejas con estructuras de datos complejas tenga cierto grado de complejidad.
    • Si la gente hubiera dedicado a aprender Git tan solo la mitad del esfuerzo que dedica a quejarse de Git, probablemente no habría hecho falta crear una guía de más de 30 partes para explicar cosas que se pueden encontrar en las páginas del manual.
      Un commit es una instantánea de un árbol y tiene una lista de ancestros. Normalmente es uno, pero no siempre. Una etiqueta es un rótulo inmutable para un commit, y una rama es un rótulo mutable para un commit. El índice es un pequeño protocommit en progreso que se llena con add antes de hacer commit.
      Eso es Git. Si quieres saber más, no leas una guía: busca cosas como “cómo cambiar a un commit específico de Git sin afectar el árbol”, “cómo hacer commit solo de algunos de los archivos modificados” o “cómo copiar un commit de otro lugar al árbol actual”.
      La abstracción básica es minimalista y fácil. Lo sofisticado y complejo es lo que quieres hacer con esa abstracción. Aprende lo primero y busca lo segundo; no hace falta leer una guía.
    • El uso de Git se puede explicar en 5 líneas de comentarios de HN: git clone, git checkout, git pull, git add + commit + push, git reset / rebase.
    • Aun así puedes pegarte un tiro en el pie.
    • Sí y no. Los comandos de usuario de Git probablemente son suficientemente buenos para el 95% de los usuarios.
      rebase -i trae indicaciones sobre qué hace cada comando, y explicar cómo formatear la salida de git log según tus gustos y compromisos toma unos cuantos párrafos. Normalmente considero que los comandos de usuario incluyen también cosas bastante variadas como git gc, git fsck y git rev-parse.
      Los comandos de bajo nivel definitivamente son más crípticos, y por sí mismos hacen muchas cosas que no siempre son fáciles de hacer con comandos de usuario optimizados para casos de uso comunes.
      En resumen, Git es grande, incluso enorme, pero para la mayoría de los desarrolladores una parte considerable de lo que ofrece está bastante lejos del camino principal.

  • Lo aterrador es que la guía sea tan larga.
    Sé que las guías de Beej suelen ser exhaustivas, pero no había dimensionado de verdad la enorme cantidad de sutilezas de Git hasta ver esto.
    Con Jujutsu, siento que sería una guía mucho más delgada o, al menos, una que la gente podría ir descubriendo y aprendiendo con más facilidad.

    • Intento que la mayoría de mis guías estén hechas para que puedas dejar de leer cuando sientas que ya leíste suficiente. No hace falta leerlas completas.
      Siento que esta guía cubre apenas alrededor del 10% de Git, pero espero que cubra el 90% del uso común.
    • Esta guía va hacia el lado exhaustivo; en el extremo opuesto hay una hoja de una sola página con el 90% de los comandos de Git que necesitarás en adelante: https://wizardzines.com/git-cheat-sheet.pdf
    • Parece una señal de que Git no es la herramienta adecuada para la mayoría, pero de algún modo terminó solidificándose como estándar.

  • En el trabajo, una o dos veces al año doy un curso de 2 horas de introducción al modelo de datos de Git.
    Entramos literalmente al directorio .git, descomprimimos archivos y muestro que todo es solo una representación en texto plano de las estructuras de datos básicas. Es realmente genial ver el momento en que a la gente le hace clic en la cabeza.
    Compartimos un documento con recetas básicas de Git para que los recién ingresados empiecen a hacer commits de código, pero la mayoría solo las sigue sin entender qué está pasando.
    En cambio, quienes toman la clase, aunque no conozcan todos los comandos, obtienen una comprensión operativa bastante razonable de lo que realmente ocurre en Git. Los comandos se pueden buscar fácilmente, así que si el modelo mental es correcto, los comandos en sí no son gran problema. Aun así, casi todas las discusiones sobre Git en HN terminan hablando de la línea de comandos.
    Curiosamente, esta clase suena parecida al texto alternativo de https://xkcd.com/1597/. La diferencia es que, para un público técnico, esa sí es realmente la forma correcta de enseñar Git, y una vez que lo entiendes te llevas una comprensión fundamental que no olvidas.
    Honestamente, el retorno por el tiempo invertido es tan alto que me parece raro no hacerlo.

    • Yo también lo hice una vez y fue excelente; la discusión posterior también fue muy buena.
      En la última diapositiva de la presentación puse preguntas para que mis colegas respondieran basándose en el modelo de datos de Git. Por ejemplo: “¿se puede mover un commit a otra rama?” y “¿qué garantiza que no haya ciclos en el grafo de commits?”.
      Fue muy satisfactorio ver que la gente no se quedó solo en usar Git, sino que empezó a pensar en Git.
    • La frase “si el modelo mental es correcto, los comandos no son gran problema” al principio me habría sonado como esa lógica que se veía mucho en los 90: “usar Linux es fácil si entiendes todas las capas y todas las partes de Linux”. Correcto en teoría, pero para la mayoría suena prácticamente imposible.
      Por suerte, al principio vi un video que explicaba parte del modelo interno de Git, y descubrí que en la práctica no hace falta tener un conocimiento interno tan grande ni tan profundo para marcar una gran diferencia. Con saber quizá un 5% de cómo funciona Git, entendí mucho mejor qué hacen los comandos y cómo usarlos.
    • Me pregunto si podrías compartir los materiales o la grabación de ese curso de 2 horas, siempre que no haya información propietaria ni restricciones que lo impidan.
      Si está basado en material público y lo bastante conciso como para caber en 2 horas, estaría bueno que lo compartieras en este hilo o como artículo en HN. Creo que, sobre un mismo tema, mientras más recursos de aprendizaje haya con distintas premisas, analogías y enfoques, mejor.
    • Me pregunto si hay una copia de la presentación o un video, o si tienes algún material similar para recomendar.
    • Comparte el video, por favor.

  • Sé manejar hasta cierto punto el flujo general de Git, merges, rebases, etc., pero en vez de intentar mejorar en Git estoy considerando seriamente pasarme a jujutsu. jj es compatible con Git, y puedo usarlo solo yo mientras mis compañeros siguen usando Git.

  • Siento que hay un truco que muchas guías y la mayoría de las GUI de Git pasan por alto. Como excepción, magit lo maneja bien
    Se trata de configurar la rama upstream no como origin/feature/foo de feature/foo, sino como el destino al que se quiere fusionar, es decir, la rama de integración master u origin/master
    Esto simplifica muchas cosas. Al ejecutar git status, te dice cuánto te has desviado de la rama de integración, lo cual es útil, y si ejecutas git rebase sin argumentos, hace el rebase directamente sobre el upstream
    Tener origin/feature/foo como upstream es menos útil. Los desarrolladores, por lo general, también “poseen” su propia rama remota, así que no importa mucho cuánto se desviaron de ella, y tampoco suele haber motivo para querer hacer rebase sobre ella
    Si configuras push.default como "current", git push también empuja feature/foo a origin/feature/foo como se esperaría
    Me pregunto por qué esta configuración no es más común

  • En la sección de colaboración no se tratan para nada las ramas de funcionalidad. Me parece que es una forma de trabajo bastante común
    Sería útil contrastarla con el enfoque de la guía de “que cada quien use su propia rama”. Además, en la sección 17 valdría la pena cubrir la forma de reutilizar ramas para pull requests de GitHub y la de crear una rama nueva por cada PR

  • Todavía no revisé el artículo, pero parece bueno. Otra recomendación es el curso de Git de boot.dev, impartido por Primeagen
    Es interactivo y profundiza hasta el nivel de manipular directamente archivos dentro del directorio .git. Después de tomar ese curso, me quedó un modelo mental completamente nuevo de cómo funciona Git