¿Por qué Git es tan complicado?

Cuando aprendes a programar, la gente suele recomendarte aprender Git. En teoría, suena fácil: un programa para realizar un seguimiento de los cambios en su código que lo ayuda a restaurar versiones anteriores del código cuando las necesita. Además de eso, es una herramienta que se usa en casi todas partes en la industria. En la práctica… Git puede ser confuso por decir lo menos.

¿Por qué tiene que ser así?

Interfaz de línea de comandos: CLI

La mayoría de los usuarios cotidianos de computadoras no están acostumbrados al lujo de las interfaces basadas en texto. Lo llamo lujo porque, como he escrito anteriormente , tiene grandes ventajas, aunque puede llevar algún tiempo acostumbrarse a la experiencia del usuario. Entonces, si sus asociaciones coinciden con las de la lista:

• cat —un animal peludo,
• cd : cómo la gente solía escuchar música, y
• grep —algunas onomatopeyas,

entonces es probable que su primera experiencia con Git tenga la dificultad adicional de aprender los conceptos básicos de la línea de comandos. Algo que Windows 95 y los de su clase te quitaron.

Objetivos de diseño de Git

Git nunca tuvo la intención de ser simple. Se hizo con diferentes objetivos en mente: más importantes y más desafiantes también.

Almacenamiento seguro de los datos guardados

Git está destinado a devolverle siempre los datos exactamente como se guardaron O informarle que el repositorio está dañado. Y hace un trabajo increíble con él: puede estar seguro de que el estado que obtiene al verificar un compromiso es exactamente como su autor pretendía que fuera. Por supuesto, esto supone que sabían lo que estaban haciendo.

¿Cómo logra Git una seguridad de datos tan buena? Lo hace de la forma inteligente en que almacena todo : las confirmaciones, las carpetas y los archivos. Cada objeto se identifica mediante un hash criptográfico de su contenido, un número que se genera en función del contenido del objeto, que cambiará si se modifica algo dentro de los archivos. Debido a que las referencias entre objetos también se codifican, casi no hay forma de manipular dentro de un repositorio sin que Git se dé cuenta de que algo está mal. E incluso en esos casos, el código significativo sería reemplazado por un texto incomprensible.

Trabaje en redes no seguras y con participantes que no sean de confianza

Debido a que todo se identifica mediante hashes criptográficos, Git no tiene que confiar mucho en la red para mantener los datos intactos. Git está protegido contra ataques man-in-the-middle: no hay forma de que alguien pueda inyectar código significativo entre dos nodos de Git. Por supuesto, si alguien puede leer confirmaciones que no estaban destinadas a leer, esto también es un problema, pero con consecuencias menos peligrosas que las de los atacantes que inyectan código en el código base.

Para una capa adicional de seguridad, Git ofrece la firma de compromisos, un medio adicional de garantizar que el compromiso fue creado por la persona que está configurada para ser su autor.

Mantenimiento de la compatibilidad con versiones anteriores

La interfaz de Git es más complicada de lo que tiene que ser porque respeta los viejos hábitos de sus usuarios. Aprendí Git en 2011, y hasta la semana pasada no había notado que hay un nuevo comando git switch que se recomienda para cambiar de rama. La forma en que estoy acostumbrado a hacerlo ( git checkout + varios indicadores) sigue funcionando bien. Git prioriza a los usuarios más antiguos y sus hábitos por encima de la simplicidad para los usuarios más nuevos, lo que nos lleva al siguiente punto.

Experiencia de usuario para superusuarios

Git es una herramienta hecha pensando en los superusuarios. Fue escrito por Linus Torvalds para administrar la base de código de Linux, no es una tarea para principiantes. Los usuarios principales de Git desarrollan sistemas operativos, tienen décadas de experiencia en programación y viven dentro de la línea de comandos. Todos los usos además de eso son accidentales y no son la principal preocupación para las personas que desarrollan Git.

Compensaciones de simplicidad

Cuando diseña sistemas, nada es gratis, incluida la simplicidad para los usuarios.

Ocultar la complejidad

Cuando se trata de un problema que es intrínsecamente complejo, facilita las soluciones abstrayendo la complejidad. ¿Se ha ido? No, simplemente está oculto para el usuario. Por ejemplo, en el caso de la conexión a Internet, yo y la mayoría entendemos la calidad de la conexión solo como la cantidad de barras en 📶:

• menos es malo
• más es bueno

Esto es suficiente para usar Internet, pero dificulta la comprensión y la solución de cualquier problema de conexión.

Git se centra en exponer toda la complejidad que conlleva el cambio de archivos en paralelo y la sincronización de forma asíncrona. En el extremo opuesto, tiene acceso directo al disco compartido. Es fácil de usar, pero ¿qué sucederá cuando dos personas intenten editar el mismo archivo al mismo tiempo? Uno tendrá suerte y mantendrá sus cambios, y el otro lo perderá todo. No es un buen flujo de trabajo, especialmente si los cambios perdidos valen horas de trabajo costoso. Debido a que Git expone al usuario todos los problemas que pueden aparecer en esta situación, permite resolver los conflictos en los archivos de manera inteligente, lo que en algunos casos requiere que los usuarios lo hagan manualmente.

Fácil versus seguro

Otra parte de Git que confunde a los usuarios son los ID de confirmación que son muy largos, así como números imposibles de memorizar. Incluso en la forma abreviada fácil de usar, se ven como 0828ae1 . Y el ID completo es 0828ae10b20500fbc777cc40aa88feefd123ea5e . ¿Podríamos tener solo números en orden en su lugar, o solo usar nombres de sucursales? El problema es que los ID de confirmación son hashes que garantizan la integridad de los datos: garantizan que la confirmación X en mi máquina es la misma que la confirmación X en el control remoto o en su máquina. Y los desajustes entre ellos pueden aparecer por diferentes motivos:

• intencional: rebase, enmienda, squash o cualquier otra operación que cambie el historial
• involuntario: un error o un ataque al código base

Al simplificar la interfaz y ocultar el formulario de ID de compromiso, el usuario eliminaría la posibilidad de que el usuario comprenda lo que está sucediendo en la base de código que está ejecutando en su máquina. Y debido a que el código, por definición, se ejecuta en la máquina, cualquier vulnerabilidad de seguridad sería extremadamente peligrosa.

¿Es este el enfoque correcto?

Cuando estaba aprendiendo Git, todavía era una novedad: lo estaba aprendiendo en 2011, y Git se creó en 2005 (la primera confirmación es del jueves 7 de abril a las 15:13:13 de 2005 -0700 ). En ese momento estaba usando SVN en el trabajo, y Mercurial a menudo se consideraba una alternativa más fácil de usar que Git. ¿Has escuchado esos nombres recientemente? Git dominó el mercado de control de versiones casi por completo. Ganó mucha popularidad con el surgimiento de GitHub, pero incluso si es difícil para los principiantes, es una herramienta muy eficiente y está aquí para quedarse.

¿Qué hacer como programador principiante?

Mi consejo es aprenderlo más temprano que tarde. Es muy poco probable que Git pronto se vuelva más simple. O alguna vez. Los sistemas de control de versiones en general ahorran muchos dolores de cabeza mientras programa. No puedo imaginar ser eficiente trabajando con código si tiene dificultades para mover versiones de su base de código. Aprender bien Git lo ayudará a concentrarse en los desafíos del código en lugar de luchar con archivos perdidos o solucionar los llamados "problemas de Git", que casi siempre son solo personas que arruinan su repositorio.

Además de eso, aprender Git se convirtió en un rito de iniciación para los nuevos desarrolladores. Como desarrollador, tienes que usarlo, y Git te hará la vida imposible si intentas usarlo sin entenderlo bien. La elección inteligente es aprenderlo en sus términos y no esperar hasta que los comentarios de los revisores o los problemas de código lo obliguen a aprenderlo mientras maneja otras responsabilidades al mismo tiempo.

¿Cómo aprender más?

Si está interesado en obtener más información sobre Git, regístrese aquí para recibir actualizaciones sobre mi contenido centrado en Git.