여러 git 저장소를 어떻게 구성하여 모두 함께 백업합니까?

여러 git 저장소를 어떻게 구성하여 모두 함께 백업합니까?

---

SVN을 사용하면 서버에 보관하고 몇 대의 컴퓨터에서 체크 아웃 한 하나의 큰 저장소가있었습니다. 이것은 꽤 좋은 백업 시스템이었고 어떤 기계에서든 쉽게 작업 할 수있었습니다. 특정 프로젝트를 체크 아웃하고 커밋하고 '마스터'프로젝트를 업데이트하거나 전체를 체크 아웃 할 수 있습니다.

이제 다양한 프로젝트에 대한 git 저장소가 여러 개 있으며 그중 일부는 github에 있습니다. 또한 git-svn 명령을 통해 가져온 SVN 저장소도 있습니다.

기본적으로 저는 모든 코드 (프로젝트뿐만 아니라 임의의 스 니펫 및 스크립트, 내 이력서, 내가 작성한 기사, 내가 만든 웹 사이트 등)를 하나의 큰 저장소에 담아 원격으로 쉽게 복제 할 수 있습니다. 컴퓨터 또는 메모리 스틱 / 하드 드라이브를 백업으로 사용합니다.

문제는 그것이 개인 저장소이기 때문에 git은 특정 폴더에서 체크 아웃을 허용하지 않는다는 것입니다 (별도의 프로젝트로 github에 푸시 할 수는 있지만 변경 사항은 master-repo와 sub- repos)

내가 할 수 망할 놈의 서브 모듈 시스템을 사용하지만 (이것은 백업 쓸모 그래서, 서브 모듈은 다른 저장소에 대한 포인터, 정말 실제 코드를 포함하지 않는) 내가 너무 방법을 작동하지 않습니다

현재 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등

그래서 질문 : git 저장소를 사용하여 개인 코드와 프로젝트를 어떻게 동기화하고 백업합니까?

---

나는 것이다 강력하게 주어진 Git 저장소에 관련이없는 데이터를 퍼팅에 대해 조언한다. 새로운 리포지토리를 생성하는 오버 헤드는 매우 적으며, 이는 서로 다른 계보를 완전히 분리 할 수 있는 기능 입니다.

그 아이디어에 맞서 싸우는 것은 불필요하게 얽힌 역사로 끝나는 것을 의미하며, 이는 관리를 더 어렵게 만들고, 더 중요한 것은 결과 희석으로 인해 "고고학"도구의 ​​유용성이 떨어집니다. 또한 앞서 언급했듯이 Git은 "복제 단위"가 저장소라고 가정하고 분산 특성 때문에 실제로 그렇게해야합니다.

한 가지 해결책은 모든 프로젝트 / 패키지 / 등을 유지하는 것입니다. 그 자체로 베어 처럼, 축복받은 계층에서 (나무 작업없이 즉,) 저장소 :

/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 one from github, ...
$ cd foo
$ git remote add github ...
$ git remote add memorystick ...

그런 다음 각 "소스"에서 가져 오거나 가져 와서 로컬에서 작업하고 커밋 한 다음 다음과 같은 작업이 준비되면 각 원격 장치로 푸시 ( "백업") 할 수 있습니다 ( 동일한 커밋 및 히스토리를 각각의 리모컨!) :

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

기존 작업 저장소 ~/dev/foo를 베어 저장소로 바꾸는 가장 쉬운 방법은 다음 과 같습니다.

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

이는 대부분 a와 동일 svn import하지만 기존의 "로컬"히스토리를 버리지는 않습니다.

참고 : 하위 모듈 은 공유 된 관련 계보 를 포함하는 메커니즘 이므로 실제로 해결하려는 문제에 적합한 도구라고 생각하지 않습니다.

---

그가 추천 하는 Damien의 답변 에 추가하고 싶습니다 .

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

You can set up a special remote to push to all the individual real remotes with 1 command; I found it at http://marc.info/?l=git&m=116231242118202&w=2:

So for "git push" (where it makes sense to push the same branches multiple times), you can actually do what I do:

• .git/config contains:

  [remote "all"]
  url = master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
  url = login.osdl.org:linux-2.6.git
  

• and now git push all master will push the "master" branch to both
  of those remote repositories.

You can also save yourself typing the URLs twice by using the contruction:

[url "<actual url base>"]
    insteadOf = <other url base>

---

I also am curious about suggested ways to handle this and will describe the current setup that I use (with SVN). I have basically created a repository that contains a mini-filesystem hierarchy including its own bin and lib dirs. There is script in the root of this tree that will setup your environment to add these bin, lib, etc... other dirs to the proper environment variables. So the root directory essentially looks like:

./bin/            # prepended to $PATH
./lib/            # prepended to $LD_LIBRARY_PATH
./lib/python/     # prepended to $PYTHONPATH
./setup_env.bash  # sets up the environment

Now inside /bin and /lib there are the multiple projects and and their corresponding libraries. I know this isn't a standard project, but it is very easy for someone else in my group to checkout the repo, run the 'setup_env.bash' script and have the most up to date versions of all of the projects locally in their checkout. They don't have to worry about installing/updating /usr/bin or /usr/lib and it keeps it simple to have multiple checkouts and a very localized environment per checkout. Someone can also just rm the entire repository and not worry about uninstalling any programs.

This is working fine for us, and I'm not sure if we'll change it. The problem with this is that there are many projects in this one big repository. Is there a git/Hg/bzr standard way of creating an environment like this and breaking out the projects into their own repositories?

---

,I haven't tried nesting git repositories yet because I haven't run into a situation where I need to. As I've read on the #git channel git seems to get confused by nesting the repositories, i.e. you're trying to git-init inside a git repository. The only way to manage a nested git structure is to either use git-submodule or Android's repo utility.

As for that backup responsibility you're describing I say delegate it... For me I usually put the "origin" repository for each project at a network drive at work that is backed up regularly by the IT-techs by their backup strategy of choice. It is simple and I don't have to worry about it. ;)

---

What about using mr for managing your multiple Git repos at once:

The mr(1) command can checkout, update, or perform other actions on a set of repositories as if they were one combined respository. It supports any combination of subversion, git, cvs, mercurial, bzr, darcs, cvs, vcsh, fossil and veracity repositories, and support for other revision control systems can easily be added. [...]

It is extremely configurable via simple shell scripting. Some examples of things it can do include:

[...]

• When updating a git repository, pull from two different upstreams and merge the two together.
• Run several repository updates in parallel, greatly speeding up the update process.
• Remember actions that failed due to a laptop being offline, so they can be retried when it comes back online.

---

There is another method for having nested git repos, but it doesn't solve the problem you're after. Still, for others who are looking for the solution I was:

In the top level git repo just hide the folder in .gitignore containing the nested git repo. This makes it easy to have two separate (but nested!) git repos.

참고URL : https://stackoverflow.com/questions/36862/how-do-you-organise-multiple-git-repositories-so-that-all-of-them-are-backed-up