在多台机器上使用Git

这听起来可能有点奇怪，但是我想知道一种以某种方式联网的多台机器在Git中工作的好方法。在我看来，我有两个选择，并且我可以看到双方的好处：

• 使用git本身进行共享，每台机器都有自己的存储库，您必须在它们之间进行获取。
  • 即使另一台计算机处于脱机状态，您也可以在其中任何一台计算机上工作。我认为这本身就很大。
• 使用在计算机之间通过网络共享的一个存储库。
  • 每次切换机器时都不需要执行git pull，因为您的代码始终是最新的。
  • 不必担心您忘记了从其他非托管计算机中推送代码的机会，因为您正在该计算机上处​​理文件共享，因此现在无法访问该代码。

我的直觉是，每个人通常都选择第一种选择。但是我看到的缺点是，您可能无法始终能够从其他计算机访问代码，而且我当然也不想每天结束时将所有WIP分支都推送到github。我也不想一直把计算机留在原处，这样我就可以直接从它们中获取信息。最后一点是，所有使多个分支保持最新状态的git命令都可能很乏味。

在这种情况下是否有第三个处理方法？也许有一些第三方工具可以帮助简化此过程？如果您定期处理这种情况，您有何建议？

我每天都会处理您提出的两种解决方案。要正确处理它们，有两个关键概念。

1. 使用主题分支。我相信生产历史应该是原始的。结果，我花费了大量时间使production分支的历史记录具有逻辑性，可复制性和可调试性。但是，当使用多台计算机时，有时需要提交正在进行的工作。使用主题分支。你可以pull和push来自不费吹灰之力两台机器的支路，并且当它准备合并成master或production 重订它来创建一个更易于维护的历史。
2. 除非您也要与其他用户共享，否则使用通过网络共享的一个存储库就可以了。我们使用脚本的共享存储库，创造性地命名该scripts存储库。起初，这似乎是个好主意，因为回购协议并不经常更改，但是随着时间的流逝，它变成了一场噩梦。覆盖彼此的工作很容易，并且最终您花费的空中交通控制时间与在仓库中进行工作时控制谁在部署存储库有关。

最好的解决方案是在每台计算机上保留一个本地存储库，并通过远程在它们之间共享主题分支。根据需要将正在进行的工作分配给这些分支。只要你愿意rebase他们拥有更通俗易懂的历史，它在实践中就非常有效。

如果您发现自己在一整天都在多个主题分支上工作，但又不想将每个分支单独推送到远程，git push <remote>则默认情况下会将所有匹配的分支推送到<remote>。此默认值将在更高版本的git中更改，但可以通过在配置文件中设置push.default或指定匹配项来覆盖refspec：

git push <remote> :

如果不是所有机器都一直处于启动状态，那就没有灵丹妙药：在关闭机器之前，您必须将更改推送到其他位置。我将其推送到专用服务器，但也可能是随身携带的保管箱或USB密钥。

是的，将多个分支推到一个中央位置可能会很乏味，但是编写脚本并不难。push.sh为此，我使用脚本，每次在计算机上完成工作后都运行该脚本。

我是从一个略有不同的方向来解决这个问题的（我使用的是水uri笔，但从哲学上讲，是相同的）。这不是我的主意，我只是用它就可以用于我的个人物品。

我在SkyDrive文件夹中创建了一个存储库克隆（它可以是Dropbox或您选择的另一个魔术同步工具），然后在两台计算机上配置了实例，以便在提交时自动推送到SkyDrive存储库。

当我切换盒子时，只需进行拉动和更新即可-从理论上讲，即使它在多个存储库中，您也将始终以线性方式工作。

这里的关键是SkyDrive存储库的存在主要是为了提供一种方法，以确保我可以在两台机器上访问或多或少的最新版本的代码-尽管它也可以在更多版本上正常工作-并且提供额外的备份。任何“完成”的内容都会推送到Kiln（如果我使用git并且我正确理解了游戏的玩法，那么这就是我进行基准调整的地方）。

我真的不想做的是在共享文件夹上运行...如果您使用的是DVCS，那么您也可以享受到这一好处。

两种选择中的第一种是答案。“ DVCS”中的“ D”暗含了这一点。每个用户都有自己的存储库本地实例，并且存储库之间以可管理的方式相互通信。

您可以选择第二种方法，但是问题是，只有一个存储库工作目录。因此，工作树一次只能处于一种状态-没有Joe在一个分支上工作，而Jane在另一个分支上工作。因此，开发人员可以覆盖彼此的更改，粉碎彼此的工作。为什么呢，就像根本没有版本控制！

有一个中间立场，网络驱动器上有一个裸存储库，而每个用户都可以签入和签出。这会将您的WIP工作（是的，您保留在本地）与您发布到存储库的工作分开。它不是“保存”，而是“发布”。您希望您的同事看到和使用的作品。