Làm thế nào để bạn tổ chức nhiều kho lưu trữ git, sao cho tất cả chúng được sao lưu cùng nhau?

Question

Với SVN, tôi có một kho lưu trữ lớn duy nhất mà tôi đã lưu trên một máy chủ và được kiểm tra trên một vài máy. Đây là một hệ thống sao lưu khá tốt, và cho phép tôi dễ dàng làm việc trên bất kỳ máy nào. Tôi có thể kiểm tra một dự án cụ thể, cam kết và nó cập nhật dự án 'chủ', hoặc tôi có thể kiểm tra toàn bộ điều.

Bây giờ, tôi có một kho lưu trữ git, cho các dự án khác nhau, một vài trong số đó là trên github. Tôi cũng có kho SVN mà tôi đã đề cập, được nhập thông qua lệnh git-svn ..

Về cơ bản, tôi muốn có tất cả mã của mình (không chỉ các dự án, nhưng đoạn mã và đoạn mã ngẫu nhiên, một số thứ như CV, bài viết của tôi ' đã viết, các trang web tôi đã thực hiện và vv) trong một kho lưu trữ lớn, tôi có thể dễ dàng sao chép vào máy từ xa, hoặc thẻ nhớ/harddrives như sao lưu.

Vấn đề là, vì nó là kho lưu trữ riêng và git không cho phép kiểm tra thư mục cụ thể (tôi có thể chuyển sang github dưới dạng dự án riêng biệt, nhưng có thay đổi xuất hiện trong cả master-repo, và sub-repos)

I có thể sử dụng hệ thống con git submodule, nhưng nó không hoạt động như thế nào tôi muốn nó (submodules là con trỏ đến kho khác, và không thực sự chứa mã thực tế, vì vậy vô ích khi sao lưu)

Hiện tại tôi có thư mục git-repos (ví dụ: ~/code_projects/proj1/.git/~/code_projects/proj2/.git /) và sau khi thực hiện thay đổi đối với proj1, tôi thực hiện git push github, sau đó tôi sao chép các tệp vào ~/Documents/code/python/projects/proj1/và thực hiện một cam kết đơn lẻ (thay vì nhiều commit trong các repos riêng lẻ). Sau đó, hãy thực hiện git push backupdrive1, git push mymemorystick vv

Vì vậy, câu hỏi: Mã và dự án cá nhân của bạn có kho lưu trữ git như thế nào và giữ chúng được đồng bộ hóa và sao lưu?

Answer 1

Tôi sẽ mạnh khuyên bạn không nên đặt dữ liệu không liên quan trong kho lưu trữ Git nhất định. Chi phí của việc tạo kho mới là khá thấp , và đó là một tính năng mà làm cho nó có thể giữ các dòng khác nhau hoàn toàn riêng biệt.

Chiến đấu ý tưởng đó có nghĩa là kết thúc với lịch sử rối loạn không cần thiết, làm cho việc quản trị trở nên khó khăn hơn - và quan trọng hơn - công cụ "khảo cổ học" ít hữu ích hơn do kết quả pha loãng . Ngoài ra, như bạn đã đề cập, Git giả định rằng "đơn vị của nhân bản" là kho lưu trữ, và thực tế phải làm như vậy vì bản chất phân tán của nó là .

Một giải pháp là giữ mọi dự án/gói/v.v. như là của riêng trần kho của nó (ví dụ, không cây làm việc) theo một hệ thống phân cấp may mắn, như:

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

Khi một vài ước đã được thiết lập, nó trở nên tầm thường để áp dụng các hoạt động hành chính (sao lưu, đóng gói , xuất bản web) tới cấu trúc phân cấp hoàn chỉnh, phục vụ vai trò không hoàn toàn khác với kho "SVN" nguyên khối. Làm việc với các kho cũng trở nên hơi tương tự như quy trình công việc SVN, với việc bổ sung rằng một thể sử dụng cam kết, ngành địa phương:

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

Bạn có thể có nhiều điều khiển từ xa trong mỗi bản sao làm việc đối với sự dễ dàng của đồng bộ hóa giữa nhiều bên:

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

sau đó bạn có thể lấy/kéo từ mỗi "nguồn", làm việc và cam kết tại địa phương, và sau đó đẩy ("backup") để mỗi người trong các rem OTES khi bạn đã sẵn sàng với một cái gì đó tương tự (lưu ý làm thế nào mà đẩy cùng cam và lịch sử cho mỗi điều khiển từ xa!):

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

Cách dễ nhất để biến một kho làm việc hiện ~/dev/foo vào đó một kho lưu trữ trần có lẽ là:

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

mà chủ yếu là tương đương với một svn import --but không ném hiện có, lịch sử "địa phương" đi.

Lưu ý: submodules là một cơ chế để bao gồm chia sẻ liên quan dòng, vì vậy tôi thực sự sẽ không xem xét cho họ một công cụ thích hợp cho vấn đề bạn đang cố gắng để giải quyết.

Answer 2

, Tôi chưa thử lưu trữ git lồng nhau vì tôi chưa gặp phải tình huống mà tôi cần. Như tôi đã đọc trên #git channel git dường như bị nhầm lẫn bằng cách lồng các kho lưu trữ, tức là bạn đang cố gắng git-init bên trong một kho lưu trữ git. Cách duy nhất để quản lý cấu trúc git lồng nhau là sử dụng git-submodule hoặc tiện ích repo của Android.

Đối với trách nhiệm sao lưu bạn mô tả tôi nói ủy quyền nó ... Đối với tôi, tôi thường đặt kho "gốc" cho từng dự án tại một ổ đĩa mạng tại nơi làm việc được sao lưu thường xuyên bởi IT- techs bằng chiến lược sao lưu của họ lựa chọn. Nó đơn giản và tôi không phải lo lắng về nó. ;)

Answer 3

tôi muốn thêm vào Damien's answer nơi ông đề nghị:

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

Bạn có thể thiết lập một từ xa đặc biệt để đẩy tất cả các điều khiển từ xa thực cá nhân với 1 lệnh; Tôi tìm thấy nó ở http://marc.info/?l=git&m=116231242118202&w=2:

Vì vậy cho "git push" (nơi nó làm cho tinh thần để đẩy các ngành cùng nhiều lần), bạn thực sự có thể làm những gì tôi làm:

• .git/config chứa:

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

• và bây giờ git push all master sẽ đẩy "bậc thầy" chi nhánh để cả
  những kho từ xa.

Bạn cũng có thể tiết kiệm cho mình cách gõ URL gấp đôi bằng contruction:

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

Answer 4

Tôi cũng tò mò về cách đề nghị để xử lý này và sẽ mô tả các thiết lập hiện tại mà tôi sử dụng (với SVN). Tôi đã cơ bản tạo ra một kho chứa một hệ thống phân cấp hệ thống tập tin mini bao gồm cả thư mục bin và lib riêng của nó. Có kịch bản trong thư mục gốc của cây này sẽ thiết lập môi trường của bạn để thêm các bin, lib, vv ... các thư mục khác vào các biến môi trường thích hợp. Vì vậy, thư mục gốc về cơ bản trông giống như:

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

Bây giờ bên trong/bin và/lib có nhiều dự án và thư viện tương ứng của chúng. Tôi biết đây không phải là một dự án tiêu chuẩn, nhưng rất dễ dàng cho một người khác trong nhóm của tôi kiểm tra repo, chạy tập lệnh 'setup_env.bash' và có phiên bản cập nhật nhất của tất cả các dự án cục bộ trong kiểm tra. Họ không phải lo lắng về việc cài đặt/cập nhật/usr/bin hoặc/usr/lib và nó giữ nó đơn giản để có nhiều checkouts và một môi trường rất địa phương cho mỗi kiểm tra. Ai đó cũng có thể rm toàn bộ kho lưu trữ và không phải lo lắng về việc gỡ cài đặt bất kỳ chương trình nào.

Điều này có hiệu quả đối với chúng tôi và tôi không chắc chắn liệu chúng tôi có thay đổi hay không. Vấn đề với điều này là có rất nhiều dự án trong kho lưu trữ lớn này. Có một cách tiêu chuẩn git/Hg/bzr của việc tạo ra một môi trường như thế này và phá vỡ các dự án vào kho riêng của họ?

Answer 5

Có một phương pháp khác để có repo git lồng nhau, nhưng nó không giải quyết được vấn đề bạn đang gặp phải. Tuy nhiên, đối với những người khác đang tìm kiếm giải pháp tôi đã có:

Ở cấp cao nhất, chỉ cần ẩn thư mục trong .gitignore chứa repo git lồng nhau. Điều này làm cho nó dễ dàng để có hai riêng biệt (nhưng lồng nhau!) Git repos.

Answer 6

gì về việc sử dụng mr để quản lý nhiều Repos Git của bạn cùng một lúc:

Các mr (1) lệnh có thể kiểm, cập nhật, hoặc thực hiện các hành động khác trên một tập của kho như thể họ là một kết hợp mặt nạ. Nó hỗ trợ bất kỳ sự kết hợp nào của subversion, git, cvs, mercurial, bzr, darcs, cvs, vcsh, kho hóa thạch và xác thực, và hỗ trợ cho hệ thống kiểm soát sửa đổi khác có thể dễ dàng được thêm vào. [...]

Cấu hình này có thể định cấu hình cực kỳ thông qua quá trình tạo shell đơn giản. Một số ví dụ thứ nó có thể làm bao gồm:

[...]

• Khi cập nhật một kho git, kéo từ hai upstreams khác nhau và hợp nhất hai với nhau.
• Chạy nhiều bản cập nhật kho lưu trữ song song, đẩy nhanh quá trình cập nhật.
• Hãy nhớ các hành động không thành công do máy tính xách tay đang ngoại tuyến, vì vậy chúng có thể được thử lại khi trực tuyến trở lại.