如何将变更集从脱机计算机推/拉到服务器？

Question

The software project I am working on recently migrated from ClearCase to Git. I am still learning the fundamentals, so this question might be resolved later once I am more familiar with Git and its capabilities.

My question is this: Does Git have a good workflow mechanism for a developer's machine that cannot connect to a central repository (ie., no network connection)?

Details

We have a centralized Git repository/server at our office (Location A). Most developers will be able to connect to the server directly, whether it is through the LAN at the office or through VPN. The security policy for this project does not allow any direct ssh/https connections to the server from outside the LAN - everything must go through VPN in that case.

A developer on the team is moving to work on-site at a customer's facility (Location C). The developer will be working on a development machine at Location C that is offline only, and data can be transferred in and out of the machine using media (CD or DVD). The developer will need to have a branch or two of code on the offline machine, as he will be doing bug fixes, prototyping features for the customer, and acting as a front-line representative for the project.

The developer will also have a machine at home (Location B) where he can connect to Location A using VPN and push/pull from the central repo. We have tested this, and this works fine.

We are attempting to determine if it is possible to update the repository on the machine at Location C using DVDs. The current repostitory is ~1.6GB source and 3GB of third-party binaries (we have not broken it up yet due to a huge amount of interconnectivity between various modules. It's a 25+ year old legacy R&D codebase). After the initial clone, to update/pull the changes, would we need to burn the entire source to a disk, or can we use patches/archives to make it more efficient? If possible, I would like to maintain the history on the machine at Location C transparently (I know applying a patch makes a commit for it, but I don't believe it pulls the entire commit history for each item in the patch).

We will also need to go in the opposite direction (hence my desire to maintain the history). The bug fixes/features will need to be pushed back to the central repository, and the only way to export data is through a DVD. Would we need to burn the entire repository to a disk, or can we do this only through diffs? In this case, keeping the version history is less important, but I'd like to maintain it if possible.

We are testing various methods now (Git has only been live for about 3 working days for us), so I'm lacking a good deal of "what we've tried." I'd like to see if anyone has done this or has done anything similar to this and collect any recommendations of workflows, tools, etc., to make this easier. In the ideal world, once we have the repository set up at Location C, I would like to have small updates (only the changesets since the last pull) available through CD/DVD to the developer.

Specifics : Developer Machine will be Windows 7 x64, Central Repository is Atlassian Stash, the team generally uses SourceTree (but the developer is learning the Bash commands for Git to really understand it). We are open to running scripts,

I did look at this question and it hints that patch files are a way to go; however, the requirements are different.

Answer 1

You can zip a .git folder up and transfer it to another location (eg burned on DVD). This will allow you to get the source inside. You can also unzip it and use git pull ../somewhere/unpackedgit to get changes both in and out.

You can however, use the git bundle command to create what is essentially off-line pushes which is what you need to get your updates back out. The git pro-book explains in detail how to do this, and has this introduction:

The scenario is thus: you need to sneakernet a git push. Maybe your network is down and you want to send changes to your co-workers. Perhaps you're working somewhere onsite and don't have access to the local network for security reasons. Maybe your wireless/ethernet card just broke. Maybe you don't have access to a shared server for the moment, you want to email someone updates and you don't want to transfer 40 commits via format-patch.

Enter git bundle. The bundle command will package up everything that would normally be pushed over the wire with a git push command into a binary file that you can email or sneakernet around, then unbundle into another repository.

"sneakernet" is slang for "moving files between computers by foot (wearing sneakers)" and a pun on "ethernet".

Answer 2

If you want to transfer the last commit use

git bundle create ../b1.bundle HEAD~..HEAD

(There are many ways to describe the range of the bundled commits.)

This creates the file ../b1.bundle. You may bundle many commits into a single bundle file. Then transfer somehow the bundle file to the other system. On that system run

git bundle unbundle ../b1.bundle

This will create and print the commit(s) in your git repo as detached commits. Let's say this command printed:

3db621f037d15cf00ad5f92b96cdd189c761a8f8

Then merge this commit into your branch:

git merge 3db621f037d15cf00ad5f92b96cdd189c761a8f8

And if you pulled some changes in your online system, you can bundle these and bring them back into your offline system too.