I have 3 separate air-gapped git repositories (hosted on local GitHub 
enterprise) that I'm trying to keep in sync.   Currently, I'm using "git 
bundle" to push revisions back and forth, which worked fairly well with 
just 2 repositories, but I'm struggling a bit since the 3rd (and final) 
repository has been added to the mix.  I was using a single tag to track 
the point of last export as noted in the "git bundle" docs, but I'm 
struggling to make that scale with 2+ total repositories. 

In terms of information flow, we've deemed one of the repositories as 
"primary" and the other two as "secondary" repositories.  So in a sense we 
are using the "primary" repository like a development and merging area so 
that all changes go through the primary repository and trickle down to the 
secondary repositories.  Changes are always pushed upstream to primary, and 
then synced down to the other secondary repository. 

Please note that our use of git is more like a "versioned file system" than 
the typical developer use case.  I go on to explain that a bit more later, 
but wanted to get to my main question before everyone gives up on reading 
this really long and complicated explanation of the mess I made. 

*Q:  Does anyone know of any existing scripts, documented methods, or best 
practices to follow when syncing a branch between multiple air-gapped 
repositories?*

*How we are using git:*  As noted above, this is NOT a typical 
development-centered use-case.  Branching is very infrequent, and most work 
is done on the "master" branch in each repository.  Unlike typical 
developer-centric approaches, each clone (working copy) ends up tied to a 
specific server, rather than a single developer.  So multiple users end up 
working in the same working copy and committing code from one place.  The 
team is small and the changes are infrequent enough that this works for us, 
despite the atypical and less-than-ideal use case.

*How we are using branches:*   We treat each repository as if it has just 
one branch, a single "master".  However, because of the synchronization 
requirements, we create special purpose branches in each repository that 
essentially mirror the master branches of the other repositories.  So the 
primary repository has 2 mirrored branches, one for each of the secondary 
repositories.  And each secondary repository has a single mirrored branch 
that represents the primary (upstream) repository.  (By convention, we have 
agreed never to synchronize revisions directly between the two secondary 
repositories.)  Local changes are never applied to a mirrored repository 
branch, so that it should match the "master" branch of the mirrored 
repository exactly.  (That is, the only changes to these mirrored branches 
are fast-forward only "pull"s made from bundle files exported from 
the mirrored repository.)   The process of merging changes between branches 
is manual, and I think I want to keep it that way for the foreseeable 
future.  (Perhaps one day I'll make fast-forward merges apply 
automatically, but in general I want a human to be responsible for this 
step.)  So while each repositories' "master" branch may diverge, or at 
least have a slightly different history, in the end, they should all end up 
with the same content.  Well, at least that's the ultimate goal. 

*File transfer:  *Transferring bundle files between air-gapped environments 
involve multiple human steps including content review, approval, and some 
safety checks for compliance.  Therefore, there's no way to automatically 
schedule synchronization, which is a bummer.   That being said, I'd like to 
make this as painless as possible within the realm of what I can 
control.  I'm looking to create import and export scripts (or find existing 
ones to borrow from) that handle bundle creation and the import process. 

I'm looking for a little help designing an appropriate synchronization 
solution, and would appreciate any feedback you may have.  The combination 
of using git bundle and our non-traditional use case has made it difficult 
to find relevant resources. If there is anything I've missed, please point 
me in the right direction.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to