Experiencias con Git fuera de la programación

GitHub es el sitio de moda para crear repositorios de software. En multitud de páginas puede encontrarse la imagen que pide hacer un fork en dicha plataforma, y mucho software del que uso a diario tiene su código alojado en ella. Sumado a esto, he visto varios comentarios alabando las posibilidades de un sistema así, y la potencia que tendrá cuando llegue a los usuarios comunes. Quizá yo tengo conocimientos algo avanzados para considerarme un usuario común, pero desde luego mi foco de interés no está en el código de software por lo que, animado por estas circunstancias, me decidí a hacer unas pequeñas pruebas, unas pruebas del todo insuficientes para entender del todo la potencia de una herramienta así pero sí suficientes para tener un acercamiento y saber si puede servir a mis necesidades o no.

Brevemente: para mí usar una herramienta como Git es como matar una mosca a cañonazos, al menos del modo en que se presenta en lugares como GitHub o Bitbucket.

Git está claramente pensado para un grupo de personas que colaboren en un proyecto basado en texto plano, dado que sistemas como este pierden su razón de ser si tratamos de archivos binarios como puede ser un documento en formato ODT. Cada miembro del grupo trabaja con su copia local y luego la manda al servidor, y el dueño del grupo decide qué hacer con esos cambios. El trabajo no se realiza en directo sino de un modo asíncrono.

Pero la complejidad de Git no radica en su concepto sino en la forma de llevarla a cabo. Yo he probado con la herramienta de línea de comandos, y una vez creado el repositorio y los archivos sobre los que se va a trabajar, para enviar una modificación al servidor es necesario añadirlos a la lista de cambios, crear un commit, y luego mandarlo al servidor. Son varios pasos para realizar una acción simple.

También está la circunstancia obvia de que plataformas como GitHub o Bitbucket presentan su interfaz y sus funciones destinadas principalmente a la programación, por lo que es necesario acostumbrarse a muchos conceptos (issue, commit, fork, merge, pull request, además de los comandos propios del terminal), a pesar de que intenten simplificar ciertas cuestiones con herramientas web.

Buscando herramientas Git destinados a ámbitos lejos de la programación (alguien debía haber que creara algo así) encontré Penflip, que nació con la idea de ser un GitHub para escritores. Esta plataforma elimina todos los elementos complejos de las otras, tanto que se queda en un punto intermedio algo extraño.

La herramienta web no es mucho más que un editor de texto para Markdown bastante estético (aquí cada commit será cada vez que le demos al botón de Guardar) y una herramienta para descargar el resultado en diferentes formatos. Esconde las herramientas propias de Git y para acceder a la URL del proyecto es necesario ir a la configuración avanzada (una vez clonado se puede trabajar exactamente del mismo modo que con cualquier otra plataforma). Lo que sí hace muy bien es disfrazar cierta terminología para hacerlo mucho más amigable (Commits por Historial, Issues por Discusión, etc.).

Por lo que he podido ver, para realizar un proyecto de escritura colaborativa me parece más práctico un documento en Etherpad que lo que ofrece ahora mismo Git para sectores alejados de la programación.

Sí es interesante, por otro lado, el concepto de control de versiones, algo que ofrecen servicios de sincronización como OwnCloud: poder volver a una versión previa de un archivo, pero en este caso no hay colaboración y no necesitaríamos un aparato tan complejo como Git.

El último caso de uso que se me ocurre es tener un repositorio de textos. Por ejemplo, subir los documentos que tengo en mi página de Documentos, quizá con sus ODT originales. Pero tanto PDF como ODT son archivos binarios, por lo que la herramienta pierde su sentido. Y usar un repositorio Git para subir archivos binarios estáticos también me parece matar una mosca a cañonazos. El único modo de justificar el uso de la herramienta sería extraer el texto en formato Markdown.

En resumen, me he asomado a Git quizá con demasiadas expectativas de poder encontrarle una gran utilidad para ámbitos fuera de la programación, y al final considero más útil una carpeta compartida en servicios de sincronización. Fuera de proyectos de programación con algunos colaboradores no le veo mucho sentido a una herramienta así; se me ocurren casos de uso, pero lo veo demasiado complejo, demasiado aparatoso. Quizá es necesario que aparezca algo que simplifique la maquinaria, bien otro servicio web o bien otro sistema de este estilo que resulte más sencillo.

Puede que tenga un concepto erróneo o que no haya entendido bien algún concepto, así que estaré encantado de leer comentarios y experiencias al respecto.

Categorías:

3 respuestas

  1. Adolfo

    que sistemas como este pierden su razón de ser si tratamos de archivos binarios como puede ser un documento en formato ODT

    Existe el formato ODF plano (.fodt) precisamente para utilizarlo en sistemas de control de versiones como Git. ;)
    Además, hay muchos formatos binarios que GitHub puede analizar para crear diffs visuales, como las imágenes.

  2. anonimo

    Bueno, si aún quieres darle una oportunidad a GIT a futuro, déjame darte una recomendación. Por favor NO uses Github.
    Github privativo y se está transformando en un maldito estandar de facto (como veo, tú eres muy defensor del software libre y los buenos estándares). Mejor dale oportunidades a alternativas como Gitlab o Gitorious, que son libres, puedes instalar en tu propio server, o sino puedes usar su propio plan de hosting gratuito.

  3. […] como GitHub, GitLab o Codeberg. En este caso, además, debemos superar la pared que supone Git. Yo no fui capaz cuando lo intenté hace […]

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *