Usando Git sin conexión
El diseño distribuido de Git permite flujos de trabajo completamente sin conexión y aislados de la red, desde tratar carpetas locales, unidades USB y recursos compartidos en LAN como remotos hasta mover cambios mediante `git bundle` o parches por correo en lugar de depender de GitHub u otras forjas alojadas. Los comentaristas contrastan esto con la cultura actual, en gran medida centralizada, de las pull requests, debatiendo las ventajas y desventajas entre la comodidad, una “fuente única de verdad” y modelos de colaboración realmente descentralizados como las listas de correo o las forjas federadas. También destacan usos más amplios —copias de seguridad de configuraciones, manuscritos y servidores de juegos— y señalan alternativas como git‑annex y Fossil para archivos grandes o la portabilidad de repositorios en un solo archivo.
Usando Git sin conexión y remotos locales
- Muchos usan Git completamente sin conexión para notas privadas, configuraciones o en entornos aislados de la red.
- Los remotos pueden ser rutas de archivo simples: memorias USB, carpetas locales, recursos compartidos de red, NAS u otra máquina por SSH.
- Los repositorios bare en máquinas de la LAN sirven como copias de seguridad y centros de sincronización; pueden coexistir varios remotos (GitHub, LAN, USB, etc.).
- Los clones locales pueden compartir almacenamiento mediante hard links, así que varios clones no necesariamente duplican los datos de los blobs.
git bundley los flujos de trabajo basados en parches (format-patch,am,send-email) se destacan como herramientas para mover cambios sin conectividad en vivo.
Uso distribuido frente a centralizado
- Muchos tratan Git como “almacenamiento remoto” (como SCP), ignorando su naturaleza distribuida.
- Los humanos tienden a gravitar hacia una única “fuente de verdad” (por ejemplo, la rama main de GitHub), aunque en principio cada clon es equivalente.
- Algunos sostienen que la verdadera distribución solo significa que cualquier par puede ser el punto de integración; otros insisten en que aun así se termina con al menos una rama de publicación autoritativa.
- Debate sobre las PR: funcionalmente descentralizadas (todos tienen un fork), pero operativamente centralizadas porque las PR y las cuentas viven en una sola forja, a menudo GitHub.
Colaboración basada en correo/parches
- Varios comentarios enfatizan el flujo de trabajo original de Git con correo/parches: los contribuyentes envían parches por listas de correo; los mantenedores los aplican y los encaminan hacia arriba en una jerarquía.
- Ventajas citadas: descentralización natural, no hace falta tener cuentas en múltiples forjas y distribución resistente de “PR” mediante la infraestructura de correo.
- Críticas: es más difícil rastrear qué se ha aplicado, los hilos largos de correo pueden parecer PR difíciles de manejar, y muchos prefieren herramientas web centralizadas por comodidad.
Usos más amplios, herramientas y alternativas
- Se describe Git como fundamental y útil más allá del código: currículums, novelas, servidores de juegos, configuraciones del sistema, etc.
- Preguntas y sugerencias sobre usar Git para sincronizar archivos; se señalan limitaciones para archivos grandes, y se mencionan
git-annexy git‑LFS. - Se elogian alternativas como Fossil por sus flujos de trabajo sin conexión y todo en uno (un solo repositorio SQLite, interfaz web integrada, incidencias, wiki).
- Algo de nostalgia por configuraciones totalmente descentralizadas basadas en SSH contrasta con la preferencia actual por plataformas alojadas (GitHub, GitLab, Bitbucket).