![\"xkcd](\"https://imgs.xkcd.com/comics/git.png\")
Los sistemas de control de versiones (VCS, por sus siglas en inglés) son herramientas utilizadas para rastrear cambios en el código fuente (u otras colecciones de archivos y carpetas). Como su nombre lo indica, estas herramientas ayudan a mantener un historial de cambios; además, facilitan la colaboración. Los VCS rastrean cambios en una carpeta y su contenido en una serie de instantáneas, donde cada instantánea encapsula el estado completo de archivos/carpetas dentro de un directorio de nivel superior. Los VCS también mantienen metadatos como quién creó cada instantánea, mensajes asociados con cada instantánea, etc.
\n\n¿Por qué es útil el control de versiones? Incluso cuando trabajas solo, te permite ver instantáneas antiguas de un proyecto, mantener un registro de por qué se realizaron ciertos cambios, trabajar en ramas paralelas de desarrollo y mucho más. Cuando trabajas con otros, es una herramienta invaluable para ver qué han cambiado otras personas, así como para resolver conflictos en el desarrollo concurrente.
\n\nLos VCS modernos también te permiten responder fácilmente (y a menudo automáticamente) preguntas como:
\n\nAunque existen otros VCS, Git es el estándar de facto para el control de versiones. Este cómic de XKCD captura la reputación de Git:
\n\n
Debido a que la interfaz de Git es una abstracción con fugas, aprender Git de arriba hacia abajo (comenzando con su interfaz / interfaz de línea de comandos) puede llevar a mucha confusión. Es posible memorizar un puñado de comandos y pensar en ellos como encantamientos mágicos, y seguir el enfoque del cómic anterior cada vez que algo sale mal.
\n\nSi bien Git admitidamente tiene una interfaz fea, su diseño e ideas subyacentes son hermosos. Mientras que una interfaz fea tiene que ser memorizada, un diseño hermoso puede ser comprendido. Por esta razón, damos una explicación de abajo hacia arriba de Git, comenzando con su modelo de datos y luego cubriendo la interfaz de línea de comandos. Una vez que se comprende el modelo de datos, los comandos pueden entenderse mejor en términos de cómo manipulan el modelo de datos subyacente.
\n\nHay muchos enfoques ad-hoc que podrías tomar para el control de versiones. Git tiene un modelo bien pensado que habilita todas las características agradables del control de versiones, como mantener el historial, soportar ramas y habilitar la colaboración.
\n\nGit modela el historial de una colección de archivos y carpetas dentro de algún directorio de nivel superior como una serie de instantáneas. En la terminología de Git, un archivo se llama \"blob\", y es solo un montón de bytes. Un directorio se llama \"árbol\" (tree), y mapea nombres a blobs o árboles (por lo que los directorios pueden contener otros directorios). Una instantánea es el árbol de nivel superior que se está rastreando. Por ejemplo, podríamos tener un árbol como el siguiente:
\n\n<root> (tree)\n|\n+- foo (tree)\n| |\n| + bar.txt (blob, contents = \"hello world\")\n|\n+- baz.txt (blob, contents = \"git is wonderful\")\nEl árbol de nivel superior contiene dos elementos, un árbol \"foo\" (que a su vez contiene un elemento, un blob \"bar.txt\"), y un blob \"baz.txt\".
\n\n¿Cómo debería un sistema de control de versiones relacionar instantáneas? Un modelo simple sería tener un historial lineal. Un historial sería una lista de instantáneas en orden temporal. Por muchas razones, Git no usa un modelo simple como este.
\n\nEn Git, un historial es un grafo acíclico dirigido (DAG) de instantáneas. Eso puede sonar como una palabra matemática elegante, pero no te intimides. Todo esto significa que cada instantánea en Git se refiere a un conjunto de \"padres\", las instantáneas que la precedieron. Es un conjunto de padres en lugar de un solo padre (como sería el caso en un historial lineal) porque una instantánea podría descender de múltiples padres, por ejemplo, debido a la combinación (fusión) de dos ramas paralelas de desarrollo.
\n\nGit llama a estas instantáneas \"commits\". Visualizar un historial de commits podría verse algo así:
\n\no <-- o <-- o <-- o\n ^\n \\\n --- o <-- o\nEn el arte ASCII anterior, las os corresponden a commits individuales (instantáneas). Las flechas apuntan al padre de cada commit (es una relación \"viene antes\", no \"viene después\"). Después del tercer commit, el historial se ramifica en dos ramas separadas. Esto podría corresponder, por ejemplo, a dos características separadas que se desarrollan en paralelo, independientemente una de la otra. En el futuro, estas ramas pueden fusionarse para crear una nueva instantánea que incorpore ambas características, produciendo un nuevo historial que se ve así, con el commit de fusión recién creado mostrado en negrita:
\n\no <-- o <-- o <-- o <---- o\n ^ /\n \\ v\n --- o <-- o\n\n\n\nLos commits en Git son inmutables. Esto no significa que los errores no puedan corregirse, sin embargo; es solo que las \"ediciones\" al historial de commits en realidad están creando commits completamente nuevos, y las referencias (ver más abajo) se actualizan para apuntar a los nuevos.
\n\nPuede ser instructivo ver el modelo de datos de Git escrito en pseudocódigo:
\n\n// un archivo es un montón de bytes\ntype blob = array<byte>\n\n// un directorio contiene archivos y directorios nombrados\ntype tree = map<string, tree | blob>\n\n// un commit tiene padres, metadatos y el árbol de nivel superior\ntype commit = struct {\n parents: array<commit>\n author: string\n message: string\n snapshot: tree\n}\nEs un modelo de historial limpio y simple.
\n\nUn \"objeto\" es un blob, árbol o commit:
\n\ntype object = blob | tree | commit\nEn el almacén de datos de Git, todos los objetos son direccionados por contenido mediante su hash SHA-1.
\n\nobjects = map<string, object>\n\ndef store(object):\n id = sha1(object)\n objects[id] = object\n\ndef load(id):\n return objects[id]\nLos blobs, árboles y commits están unificados de esta manera: todos son objetos. Cuando hacen referencia a otros objetos, en realidad no los contienen en su representación en disco, sino que tienen una referencia a ellos por su hash.
\n\nPor ejemplo, el árbol para la estructura de directorio de ejemplo anterior (visualizado usando git cat-file -p 698281bc680d1995c5f4caaf3359721a5a58d48d), se ve así:
100644 blob 4448adbf7ecd394f42ae135bbeed9676e894af85 baz.txt\n040000 tree c68d233a33c5c06e0340e4c224f0afca87c8ce87 foo\nEl árbol en sí contiene punteros a su contenido, baz.txt (un blob) y foo (un árbol). Si miramos el contenido direccionado por el hash correspondiente a baz.txt con git cat-file -p 4448adbf7ecd394f42ae135bbeed9676e894af85, obtenemos lo siguiente:
git is wonderful\nAhora, todas las instantáneas pueden identificarse por sus hashes SHA-1. Eso es inconveniente, porque los humanos no son buenos para recordar cadenas de 40 caracteres hexadecimales.
\n\nLa solución de Git a este problema son nombres legibles por humanos para los hashes SHA-1, llamados \"referencias\". Las referencias son punteros a commits. A diferencia de los objetos, que son inmutables, las referencias son mutables (pueden actualizarse para apuntar a un nuevo commit). Por ejemplo, la referencia master generalmente apunta al último commit en la rama principal de desarrollo.
references = map<string, string>\n\ndef update_reference(name, id):\n references[name] = id\n\ndef read_reference(name):\n return references[name]\n\ndef load_reference(name_or_id):\n if name_or_id in references:\n return load(references[name_or_id])\n else:\n return load(name_or_id)\nCon esto, Git puede usar nombres legibles por humanos como \"master\" para referirse a una instantánea particular en el historial, en lugar de una larga cadena hexadecimal.
\n\nUn detalle es que a menudo queremos una noción de \"dónde estamos actualmente\" en el historial, para que cuando tomemos una nueva instantánea, sepamos a qué es relativa (cómo establecemos el campo parents del commit). En Git, ese \"dónde estamos actualmente\" es una referencia especial llamada \"HEAD\".
Finalmente, podemos definir qué es (aproximadamente) un repositorio de Git: son los datos objects y references.
En disco, todo lo que Git almacena son objetos y referencias: eso es todo lo que hay en el modelo de datos de Git. Todos los comandos git se mapean a alguna manipulación del DAG de commits agregando objetos y agregando/actualizando referencias.
Siempre que estés escribiendo cualquier comando, piensa en qué manipulación está haciendo el comando a la estructura de datos de grafo subyacente. Por el contrario, si estás tratando de hacer un tipo particular de cambio al DAG de commits, por ejemplo, \"descartar cambios no confirmados y hacer que la referencia 'master' apunte al commit 5d83f9e\", probablemente haya un comando para hacerlo (por ejemplo, en este caso, git checkout master; git reset --hard 5d83f9e).
Este es otro concepto que es ortogonal al modelo de datos, pero es parte de la interfaz para crear commits.
\n\nUna forma en que podrías imaginar implementar la captura de instantáneas como se describió anteriormente es tener un comando \"crear instantánea\" que cree una nueva instantánea basada en el estado actual del directorio de trabajo. Algunas herramientas de control de versiones funcionan así, pero no Git. Queremos instantáneas limpias, y puede que no siempre sea ideal hacer una instantánea del estado actual. Por ejemplo, imagina un escenario en el que has implementado dos características separadas y quieres crear dos commits separados, donde el primero introduce la primera característica y el siguiente introduce la segunda característica. O imagina un escenario en el que tienes declaraciones de impresión de depuración agregadas por todo tu código, junto con una corrección de error; quieres confirmar la corrección de error mientras descartas todas las declaraciones de impresión.
\n\nGit acomoda tales escenarios permitiéndote especificar qué modificaciones deben incluirse en la siguiente instantánea a través de un mecanismo llamado \"área de preparación\" (staging area).
\n\nPara evitar duplicar información, no vamos a explicar los comandos a continuación en detalle. Consulta el altamente recomendado Pro Git para más información.
\n\nEl comando git init inicializa un nuevo repositorio de Git, con los metadatos del repositorio almacenados en el directorio .git:
$ mkdir myproject\n$ cd myproject\n$ git init\nInitialized empty Git repository in .git\n$ git status\nOn branch master\nNo commits yet\nnothing to commit (create/copy files and use \"git add\" to track)\n¿Cómo interpretamos esta salida? \"No commits yet\" básicamente significa que nuestro historial de versiones está vacío. Arreglemos eso.
\n\n$ echo \"hello, git\" > hello.txt\n$ git add hello.txt\n$ git status\nOn branch master\nNo commits yet\nChanges to be committed:\n (use \"git rm --cached <file>...\" to unstage)\n new file: hello.txt\n$ git commit -m 'Initial commit'\n[master (root-commit) 4515d17] Initial commit\n 1 file changed, 1 insertion(+)\n create mode 100644 hello.txt\nCon esto, hemos agregado un archivo al área de preparación con git add, y luego confirmamos ese cambio con git commit, agregando un mensaje de commit simple \"Initial commit\". Si no especificáramos una opción -m, Git abriría nuestro editor de texto para permitirnos escribir un mensaje de commit.
Ahora que tenemos un historial de versiones no vacío, podemos visualizar el historial. Visualizar el historial como un DAG puede ser especialmente útil para comprender el estado actual del repositorio y conectarlo con tu comprensión del modelo de datos de Git.
\n\nEl comando git log visualiza el historial. Por defecto, muestra una versión aplanada, que oculta la estructura del grafo. Si usas un comando como git log --all --graph --decorate, te mostrará el historial completo de versiones del repositorio, visualizado en forma de grafo.
$ git log --all --graph --decorate\n* commit 4515d17a167bdef0a91ee7d50d75b12c9c2652aa (HEAD -> master)\n Author: Subramanya N <subramanyanagabhushan@gmail.com>\n Date: Tue Dec 21 22:18:36 2020 -0500\n Initial commit\nEsto no se ve muy parecido a un grafo, porque solo contiene un solo nodo. Hagamos algunos cambios más, creemos un nuevo commit y visualicemos el historial una vez más.
\n\n$ echo \"another line\" >> hello.txt\n$ git status\nOn branch master\nChanges not staged for commit:\n (use \"git add <file>...\" to update what will be committed)\n (use \"git checkout -- <file>...\" to discard changes in working directory)\n modified: hello.txt\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git add hello.txt\n$ git status\nOn branch master\nChanges to be committed:\n (use \"git reset HEAD <file>...\" to unstage)\n modified: hello.txt\n$ git commit -m 'Add a line'\n[master 35f60a8] Add a line\n 1 file changed, 1 insertion(+)\nAhora, si visualizamos el historial nuevamente, veremos algo de la estructura del grafo:
\n\n* commit 35f60a825be0106036dd2fbc7657598eb7b04c67 (HEAD -> master)\n| Author: Subramanya N <subramanyanagabhushan@gmail.com>\n| Date: Tue Dec 21 22:26:20 2020 -0500\n| Add a line\n* commit 4515d17a167bdef0a91ee7d50d75b12c9c2652aa\n Author: Subramanya N <subramanyanagabhushan@gmail.com>\n Date: Tue Dec 21 22:18:36 2020 -0500\n Initial commit\nAdemás, nota que muestra el HEAD actual, junto con la rama actual (master).
\n\nPodemos ver versiones antiguas usando el comando git checkout.
$ git checkout 4515d17 # hash del commit anterior; el tuyo será diferente\nNote: checking out '4515d17'.\nYou are in 'detached HEAD' state. You can look around, make experimental\nchanges and commit them, and you can discard any commits you make in this\nstate without impacting any branches by performing another checkout.\nIf you want to create a new branch to retain commits you create, you may\ndo so (now or later) by using -b with the checkout command again. Example:\n git checkout -b <new-branch-name>\nHEAD is now at 4515d17 Initial commit\n$ cat hello.txt\nhello, git\n$ git checkout master\nPrevious HEAD position was 4515d17 Initial commit\nSwitched to branch 'master'\n$ cat hello.txt\nhello, git\nanother line\nGit puede mostrarte cómo han evolucionado los archivos (diferencias, o diffs) usando el comando git diff:
$ git diff 4515d17 hello.txt\ndiff --git c/hello.txt w/hello.txt\nindex 94bab17..f0013b2 100644\n--- c/hello.txt\n+++ w/hello.txt\n@@ -1 +1,2 @@\n hello, git\n +another line\ngit help <command>: obtener ayuda para un comando de gitgit init: crea un nuevo repositorio de git, con datos almacenados en el directorio .gitgit status: te dice qué está pasandogit add <filename>: agrega archivos al área de preparacióngit commit: crea un nuevo commit\ngit log: muestra un registro aplanado del historialgit log --all --graph --decorate: visualiza el historial como un DAGgit diff <filename>: muestra los cambios que hiciste en relación con el área de preparacióngit diff <revision> <filename>: muestra diferencias en un archivo entre instantáneasgit checkout <revision>: actualiza HEAD y la rama actualLa ramificación te permite \"bifurcar\" el historial de versiones. Puede ser útil para trabajar en características independientes o correcciones de errores en paralelo. El comando git branch se puede usar para crear nuevas ramas; git checkout -b <branch name> crea una rama y la activa.
La fusión es lo opuesto a la ramificación: te permite combinar historiales de versiones bifurcados, por ejemplo, fusionar una rama de características de vuelta a master. El comando git merge se usa para fusionar.
git branch: muestra las ramasgit branch <name>: crea una ramagit checkout -b <name>: crea una rama y cambia a ella\ngit branch <name>; git checkout <name>git merge <revision>: fusiona en la rama actualgit mergetool: usa una herramienta elegante para ayudar a resolver conflictos de fusióngit rebase: reorganiza un conjunto de parches sobre una nueva basegit remote: lista los remotosgit remote add <name> <url>: agrega un remotogit push <remote> <local branch>:<remote branch>: envía objetos al remoto y actualiza la referencia remotagit branch --set-upstream-to=<remote>/<remote branch>: establece correspondencia entre rama local y remotagit fetch: recupera objetos/referencias de un remotogit pull: igual que git fetch; git mergegit clone: descarga el repositorio desde un remotogit commit --amend: edita el contenido/mensaje de un commitgit reset HEAD <file>: quita un archivo del área de preparacióngit checkout -- <file>: descarta cambiosgit config: Git es altamente personalizablegit clone --depth=1: clonación superficial, sin todo el historial de versionesgit add -p: preparación interactivagit rebase -i: reorganización interactivagit blame: muestra quién editó por última vez qué líneagit stash: elimina temporalmente modificaciones del directorio de trabajogit bisect: búsqueda binaria en el historial (por ejemplo, para regresiones).gitignore: especifica archivos no rastreados intencionalmente para ignorar