Hoxe en día é impensable programar sen usar un sistema de control de versións. Tan impensable é, que levo corenta e sete Follas escritas e nunca falei do tema, así que é hora de corrixir esta omisión.
O control de versións, como o seu nome indica, consiste en gardar un rexistro das distintas versións polas que pasa un documento ou un código fonte ou calquera outra cousa. Como sabemos todos os que algunha vez mandamos por email un ficheiro chamado “traspas_final_2_actualizadas.pptx”, o control de versións é crucial para poder organizar o noso traballo, especialmente se traballamos nun grupo.
Hoxe en día o control de versións é ubicuo. Cando un programador sube algo a GitHub, usa control de versións; cando usades “comparar revisións” no Google Docs, usades control de versións; tamén a Wikipedia usa control de versións. Toda a xente de ben usa control de versións, así que non vou tratar de convencervos das avantaxes de usalo. Se aínda non o usades, só vos vou dicir que aprendades Git e paredes de facer o parvo.
Hai uns anos, iso non era así. Cando fun á universidade, un profesor díxonos que, ao acadar certo nivel de madureza, unha organización produtora de software tiña que ter unha persoa encargada de recadar no final do día os cambios que fixera cada programador, integralos nunha copia mestra, arquivar o resultado e distribuír a nova copia mestra. Ou sexa: control de versións manual. Por sorte, a industria xa estaba bastante máis avanzada ca iso (incluso os linuxeiros usabamos CVS), pero iso dávos unha idea do pouco coñecido que era, daquela, ese concepto.
Antigamente, os sistemas de control de versións eran todos centralizados: había un só repositorio e a xente tiña “clientes” que recibían e enviaban cambios a este repositorio. Hoxe están de moda os sistemas descentralizados: cada cliente é tamén un repositorio, e os clientes poden enviar e recibir cambios entre si sen ter que pasar por un repositorio central.
Vouvos recomendar que, aínda que usedes un sistema de control de versións descentralizado, teñades sempre un repositorio “central” que conteña a copia mestra do voso proxecto. Ninguén traballaría directamente nese repositorio: cada persoa tería cadanseu cliente que recibiría e enviaría cambios ao repositorio central. Así é como funcionan GitHub e GitLab, pero tamén o podedes facer vós mesmos na vosa casa sen tanta parafernalia.
Hai dúas razóns polas que recomendo isto. A primeira é por seguridade: hai persoas que teñen un só repositorio e traballan directamente nel, e un día realizan unha operación que estraga o repositorio (un “rebase” mal feito, por exemplo). Se tiveran un repositorio central separado, abondaría con borrar o seu cliente e clonalo de novo para arranxar o problema. Se é o seu único repositorio, van pasar unha mala experiencia tratando de reparalo.
Noutras palabras: así tedes unha copia de seguridade.
O segundo motivo polo que recomendo ter un repositorio central é que hoxe en día, a utilidade do control de versións vai moito máis aló de gardar un rexistro de versións vellas ou facilitar a cooperación entre varios membros dun equipo. O control de versións está no centro de moitas prácticas modernas, como a revisión de código, integración continua ou aseguramento da cadea de subministros, e todo isto pasa por ter un repositorio central.
Por exemplo, o sistema de revisión de código controla quen pode enviar cambios ao repositorio central; o sistema de integración continua inicia unha nova integración cando o repositorio central reciba un novo cambio; finalmente, podemos asegurar o código que compilamos e distribuímos se o sistema de compilación sempre descarga a última versión do repositorio central.
E con isto xa curei a miña omisión. Dos monorrepositorios e os multirrepositorios xa falarei outro día.
A ilustración desta Folla combina un gravado de Samuel Ireland e outro de Martin Droeshout.
1 comentario