你如何组织多个git存储库，以便它们都被备份在一起？ [英] How do you organise multiple git repositories, so that all of them are backed up together?

问题描述

使用SVN，我在服务器上保存了一个大型存储库，并在几台机器上检出。这是一个非常好的备份系统，可以让我轻松地在任何机器上工作。我可以签出一个特定的项目，提交并更新'master'项目，或者我可以签出整个项目。

现在，我有一堆git存储库，为各种项目，其中几个在github上。我也有我提到的SVN仓库，通过git-svn命令导入。

基本上，我喜欢拥有我所有的代码（不仅包括项目，还包括随机片段和脚本，一些像我的简历，我写的文章，我制作的网站等等）放在一个大的存储库中，我可以很容易地克隆到远程机器上，或者记忆棒/硬盘上作为备份。
$ b

问题是，因为它是一个私有存储库，并且git不允许检出某个特定的文件夹（我可以将它作为一个单独的项目推送到github中，但是这两个变更都出现在两个master-repo和sub-repos）

我可以使用git子模块系统，但它并不按照我想要的它也是如此（子模块是指向其他存储库的指针，并没有真正包含实际的代码，所以对于备份没有用处）。

目前我有一个git-repos文件夹（例如，〜/ code_projects / proj1 / .git /〜/ code_projects / proj2 / .git /），并在更改后到proj1我做了 git push github ，然后我将这些文件复制到〜/ Documents / code / python / projects / proj1 /中，然后做一次提交（而不是众多的提交在个人回购中）。然后执行 git push backupdrive1 ， git push mymemorystick etc

所以，问题是：你的个人代码和项目如何与git仓库保持同步和备份？ 解决方案

我会强烈建议不要将无关的数据放在给定的
Git存储库中。创建新存储库的开销是
低，这是一个功能，可以使
不同的血统完全分开。

对抗这个想法意味着结束不必要的纠结历史，
让行政管理变得更加困难， -
更重要 - 考古学工具的用处不大，因为所产生的
稀释。另外，正如你所提到的，Git假设
克隆单位是存储库，实际上必须这样做，因为它的分布式性质是
。

一个解决方案是保持每个项目/包/等。作为它自己的 bare
存储库（即没有工作树）在一个神圣的层次结构中，
就像：

  /repos/a.git 
 /repos/b.git 
 /repos/c.git 
  

一旦建立了一些约定，对
应用管理操作（备份，打包，网络发布）变为
完整层次结构变得微不足道，其作用与
单一SVN存储库不完全不同。使用这些存储库也使得
与SVN工作流有些类似，另外一个
可以使用本地提交和分支：

  svn checkout  - > git clone 
 svn update  - > git pull 
 svn commit  - > git push 
  

您可以在每个工作克隆中使用多个远程控制台，以便轻松实现
同步在多方之间：

  $ cd〜/ dev 
 $ git clone /repos/foo.git＃or the一个来自github，... 
 $ cd foo 
 $ git remote add github ... 
 $ git remote add memorystick ... 
  

然后，您可以从每个来源获取/拉取，在本地工作并提交
，然后将（备份）推送到每个这些遥控器当你
准备好类似的东西时（注意如何将相同的提交
和历史给每个遥控器！）：

  $用于远程github记忆棒;做git push $ remote;完成
  

打开现有工作库的最简单方法〜/ dev / foo
到这样一个裸存储库可能是：

  $ cd〜/ dev 
 $ git clone --bare foo /repos/foo.git 
 $ mv foo foo.old 
 $ git clone /repos/foo.git 
  

它大多相当于 svn import - 但不会抛出
存在，本地历史。

注意：子模块是一种包含共享相关
的机制血统，所以我确实不会认为它们是一个适合您
的问题，您正试图解决这个问题。

With SVN, I had a single big repository I kept on a server, and checked-out on a few machines. This was a pretty good backup system, and allowed me easily work on any of the machines. I could checkout a specific project, commit and it updated the 'master' project, or I could checkout the entire thing.

Now, I have a bunch of git repositories, for various projects, several of which are on github. I also have the SVN repository I mentioned, imported via the git-svn command..

Basically, I like having all my code (not just projects, but random snippets and scripts, some things like my CV, articles I've written, websites I've made and so on) in one big repository I can easily clone onto remote machines, or memory-sticks/harddrives as backup.

The problem is, since it's a private repository, and git doesn't allow checking out of a specific folder (that I could push to github as a separate project, but have the changes appear in both the master-repo, and the sub-repos)

I could use the git submodule system, but it doesn't act how I want it too (submodules are pointers to other repositories, and don't really contain the actual code, so it's useless for backup)

Currently I have a folder of git-repos (for example, ~/code_projects/proj1/.git/ ~/code_projects/proj2/.git/), and after doing changes to proj1 I do git push github, then I copy the files into ~/Documents/code/python/projects/proj1/ and do a single commit (instead of the numerous ones in the individual repos). Then do git push backupdrive1, git push mymemorystick etc

So, the question: How do your personal code and projects with git repositories, and keep them synced and backed-up?

解决方案

I would strongly advise against putting unrelated data in a given Git repository. The overhead of creating new repositories is quite low, and that is a feature that makes it possible to keep different lineages completely separate.

Fighting that idea means ending up with unnecessarily tangled history, which renders administration more difficult and--more importantly--"archeology" tools less useful because of the resulting dilution. Also, as you mentioned, Git assumes that the "unit of cloning" is the repository, and practically has to do so because of its distributed nature.

One solution is to keep every project/package/etc. as its own bare repository (i.e., without working tree) under a blessed hierarchy, like:

/repos/a.git
/repos/b.git
/repos/c.git

Once a few conventions have been established, it becomes trivial to apply administrative operations (backup, packing, web publishing) to the complete hierarchy, which serves a role not entirely dissimilar to "monolithic" SVN repositories. Working with these repositories also becomes somewhat similar to SVN workflows, with the addition that one can use local commits and branches:

svn checkout   --> git clone
svn update     --> git pull
svn commit     --> git push

You can have multiple remotes in each working clone, for the ease of synchronizing between the multiple parties:

$ cd ~/dev
$ git clone /repos/foo.git       # or the one from github, ...
$ cd foo
$ git remote add github ...
$ git remote add memorystick ...

You can then fetch/pull from each of the "sources", work and commit locally, and then push ("backup") to each of these remotes when you are ready with something like (note how that pushes the same commits and history to each of the remotes!):

$ for remote in origin github memorystick; do git push $remote; done

The easiest way to turn an existing working repository ~/dev/foo into such a bare repository is probably:

$ cd ~/dev
$ git clone --bare foo /repos/foo.git
$ mv foo foo.old
$ git clone /repos/foo.git

which is mostly equivalent to a svn import--but does not throw the existing, "local" history away.

Note: submodules are a mechanism to include shared related lineages, so I indeed wouldn't consider them an appropriate tool for the problem you are trying to solve.

这篇关于你如何组织多个git存储库，以便它们都被备份在一起？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！