如何使用 git-bundle 保持开发同步？

How to use git-bundle for keeping development in sync?

提问by matli

I need to keep my development trees in sync on different computers, with no network connection between them.

我需要在不同的计算机上保持我的开发树同步，它们之间没有网络连接。

We have a central git repository, and I normally work on my own clone on my office computer. Sometimes I need to do some development on another computer, which is never connected to the office network. None of the computers are ever connected to Internet. Development may be performed on both computers between synchronizations.

我们有一个中央 git 存储库，我通常在我的办公室计算机上进行自己的克隆。有时我需要在另一台从未连接到办公网络的计算机上进行一些开发。没有一台计算机连接到 Internet。可以在同步之间在两台计算机上执行开发。

I have read the help pages for git-bundle, which seems like the best tool, but I am not really sure how a good workflow could be set up.

我已经阅读了git-bundle的帮助页面，这似乎是最好的工具，但我不确定如何设置一个好的工作流程。

Can you give me some advice or pointers?

你能给我一些建议或指点吗？

回答by Cascabel

Bundles!

捆绑！

The workflow with git bundle is going to be essentially the same as any other workflow. This may not seem like terribly helpful advice, but here it is: use whatever workflow you would normally use, and replace "push/pull" with "carry a bundle here to there on a flash drive, then pull".

使用 git bundle 的工作流程将与任何其他工作流程基本相同。这似乎不是非常有用的建议，但它是：使用您通常使用的任何工作流程，并将“推/拉”替换为“在闪存驱动器上从这里到那里进行捆绑，然后拉”。

The man page actually has a pretty good walkthrough for getting going with this, although it's more of a one-way example. For the sake of completeness, here's a slightly modified version of it, showing how to move information both ways:

手册页实际上有一个很好的演练来开始使用这个，尽管它更像是一个单向示例。为了完整起见，这里有一个稍微修改过的版本，展示了如何双向移动信息：

# on hostA, the initial home of the repo
hostA$ git bundle create hostA.bundle --branches --tags

# transfer the bundle to hostB, and continue:
hostB$ git clone /path/to/hostA.bundle my-repo
# you now have a clone, complete with remote branches and tags
# just to make it a little more obvious, rename the remote:
hostB$ git remote rename origin hostA

# make some commits on hostB; time to transfer back to hostA
# use the known master branch of hostA as a basis
hostB$ git bundle create hostB.bundle ^hostA/master --branches --tags

# copy the bundle back over to hostA and continue:
hostA$ git remote add hostB /path/to/hostB.bundle
# fetch all the refs from the remote (creating remote branches like hostB/master)
hostA$ git fetch hostB
# pull from hostB's master, for example
hostA$ git pull

# make some commits on hostA; time to transfer to hostB
# again, use the known master branch as a basis
hostA$ git bundle create hostA.bundle ^hostB/master --branches --tags
# copy the bundle to hostB, **replacing** the original bundle
# update all the refs
hostB$ git fetch hostA

# and so on and so on

The key thing to notice is that you can add a bundle as a remote, and interact with it just as you would with any other remote. To update that remote, just drop in a new bundle, replacing the previous one.

要注意的关键是您可以添加一个包作为遥控器，并像与任何其他遥控器一样与之交互。要更新那个遥控器，只需放入一个新的包，替换之前的包。

I've also taken a slightly different approach to picking a basis. The man page uses tags, always kept up to date with the last refs which were transferred to the other host. I've simply used the remote branches, which will refer to the last refs transferred fromthe other host. It's a little bit inefficient; you'll end up bundling more than you need to, since it's one step behind. But flash drives are big, bundles are small, and using the refs you already have instead of having to take an extra step and be careful about tags saves a lot of effort.

我还采取了一种略有不同的方法来选择基础。手册页使用标签，始终与传输到另一台主机的最后参考保持同步。我只是使用了远程分支，它将引用从其他主机传输的最后一个引用。这有点低效；你最终会比你需要的更多地捆绑，因为它落后了一步。但是闪存驱动器很大，捆绑包很小，并且使用您已有的参考而不需要采取额外的步骤并注意标签可以节省大量精力。

The one thing that makes bundles a bit of trouble is that you can't push to them, and you can't "rebase" them. If you want the bundle based on a new basis, you have to recreate it. If you want new commits in it, you have to recreate it. This hassle gives rise to my next suggestion...

使捆绑包有点麻烦的一件事是您无法推送到它们，并且您无法“重新设置”它们。如果您想要基于新基础的捆绑包，则必须重新创建它。如果您想在其中进行新的提交，则必须重新创建它。这个麻烦引起了我的下一个建议......

Repo on a thumb drive

拇指驱动器上的回购

Honestly, unless your repo is really big, this might be just as easy. Put a bare clone on a thumb drive, and you can push to and pull from it from both computers. Treat it like your network connection. Need to transfer to the central repo? Plug it in!

老实说，除非你的 repo 真的很大，否则这可能同样容易。将裸克隆放在拇指驱动器上，您可以从两台计算机推入和拉出。像对待网络连接一样对待它。需要转移到中央回购？插上电源！

回答by Adam

@Jefromi answer was great - 10x better than the git docs, which go on at length about incomprehensible requirements and actions.

@Jefromi 的回答很棒 - 比 git 文档好 10 倍，后者详细介绍了难以理解的要求和操作。

It's still a bit complicated, so here's the simplest case synching once (in my case: FROM: an offline laptop with broken wifi card, TO: a desktop with net access). Based on @Jefromi's answer, this seems to work fine:

它仍然有点复杂，所以这里是最简单的情况同步一次（在我的情况下：FROM：带有损坏的 wifi 卡的离线笔记本电脑，TO：具有网络访问权限的台式机）。根据@Jefromi 的回答，这似乎工作正常：

AHEAD = machine that is ahead by some number of commits. BEHIND = machine you want to copy the commits to

AHEAD = 领先于一定数量提交的机器。BEHIND = 要将提交复制到的机器

1. AHEAD: git-bundle create myBundleName.bundle --branches --tags

BOTH: copy myBundleName.bundle (using email, USB, whatever)

两者：复制 myBundleName.bundle（使用电子邮件、USB 等）

BEHIND: (place the file myBundName.bundle anywhere you want outsidethe project folder)

后面：（将文件 myBundName.bundle 放在项目文件夹之外的任何您想要的位置）

2. BEHIND: cd [the project folder]
3. BEHIND: git pull [path to the bundle file]/myBundleName.bundle master

So long as you include the branch-name on the end (by default, if you're not using branches, "master"), this seems to work fine, and doesn't replace any of the internal references on BEHIND - so you can still synch to/from the origin master.

只要您在末尾包含分支名称（默认情况下，如果您不使用分支，则为“master”），这似乎可以正常工作，并且不会替换 BEHIND 上的任何内部引用 - 所以您仍然可以与原始主服务器同步。

i.e. if BEHIND has internet access, it's still safe to do:

即如果 BEHIND 可以访问互联网，则仍然可以安全地执行以下操作：

(OPTIONAL) 4. BEHIND: git push

...and it'll update the main repository, as if your changes had been done locally, as normal, on BEHIND.

...它会更新主存储库，就好像您的更改已在本地完成，正常情况下，在 BEHIND 上。