2009-04-21 18 views
5

Có thể tạo một nhánh không nhìn thấy được trong git hoặc mercurial mà tôi có thể dùng làm bản sao lưu không? Ví dụ như vào cuối ngày tôi có công việc chưa hoàn thành (thậm chí có thể bị bỏ sót với lỗi cú pháp) nhưng tôi muốn nó được sao lưu trong kho lưu trữ trực tuyến, mà không làm phiền người khác về sự lộn xộn còn lại.riêng của mercurial/git branch để sao lưu?

Trả lời

0

Đó không thực sự là mục đích của SCM. Có lẽ một cái gì đó như rsync để tải nó lên một máy chủ sẽ là một ý tưởng tốt hơn?

1

Với tính siêu việt, khi hợp nhất, bạn hợp nhất tất cả các thay đổi của mình, bao gồm cả các cam kết đó "chỉ để lưu công việc chưa hoàn thành". Nếu bạn không muốn họ kết thúc trong cây thì không cam kết.

Đối với git, theo như tôi biết, hành vi mặc định là giống nhau và chỉnh sửa lịch sử cam kết để xóa chúng cũng gây phiền toái.

Vì vậy, như được đề xuất, rsync trông giống như một tùy chọn tốt hơn.

+1

Đây là lý do tại sao phát triển trong một chi nhánh cá nhân là phổ biến/phổ biến và phần lớn những gì tạo nên VCS phân phối tuyệt vời. Trước khi bạn cam kết, bạn có thể thay đổi nhánh sản xuất, rebase hoặc hợp nhất cách bạn muốn nó được nhìn thấy, và sau đó chỉ đẩy những thay đổi bạn muốn.Rsync là một lựa chọn tồi để xử lý câu hỏi. –

2

Bạn có thể thực hiện điều này nếu bạn có hai máy nhái từ xa của các kho lưu trữ:

stable 
unstable 

Push to không ổn định (sao lưu của bạn) cho đến khi bạn đã hoàn tất một tính năng. Khi tính năng này kết thúc, hãy đẩy nhánh này ổn định. Lót, rửa sạch, lặp lại.

1

Phiên bản TortoiseHg mới nhất cho phép bạn shelve your changes.

Tóm lại:

thay đổi hoãn có thể chất loại bỏ từ thư mục làm việc cho đến khi bạn unshelve họ. Điều này có nghĩa là bạn có thể xây dựng dự án của mình và chạy thử nghiệm trên đó trong khi các thay đổi về giá đã hết. Điều này an toàn hơn việc chọn các thay đổi lúc xây dựng kể từ khi bạn có thể kiểm tra cho dù thay đổi được cam kết là hợp lệ.

Kệ thay đổi cũng hữu ích cho loại bỏ việc đã hoàn thành một phần để chắc chắn rằng nó không can thiệp vào gỡ lỗi các thay đổi khác mà bạn đang định.

3

Git cho phép bạn sao chép kho lưu trữ của mình rất dễ dàng;

Giả sử bạn có repo từ xa được gọi là 'sao lưu', ví dụ:,

git remote add --mirror backup server.com:/home/koen/backup_repo.git 

Sau đó, sao lưu dễ dàng như

git push backup 

Một vài lưu ý:

  • nếu bạn không sử dụng --mirror khi thêm repo từ xa, sau đó sử dụng --mirror tại của bạn lệnh đẩy
  • repo từ xa phải là kho "trống" (vì bạn đang đẩy vào đó)
  • thanh toán các git pushgit remote giúp đỡ về --mirror
7

Theo mặc định git clonegit fetch/merge chỉ refs tải trong refs/heads/*. Vì vậy, bất cứ điều gì bạn đẩy đến một nơi khác sẽ không được tải xuống bởi người khác (trừ khi họ yêu cầu một cách rõ ràng hoặc làm điều gì đó như git clone --mirror). Vì vậy, ví dụ: bạn có thể làm:

git push origin HEAD:refs/koen/my_work 

để đẩy cam kết hiện tại của bạn. Sử dụng rằng refspec hoàn tất, bạn cũng có thể kéo nó từ thanh toán khác:

git pull origin refs/koen/my_work 

Để tự động đẩy HEAD, bạn có thể làm một cái gì đó giống như

[remote "origin"] 
    url = [email protected]:pieter/gitx.git 
    push = : 
     push = refs/heads/*:refs/koen/* 

rằng sẽ đẩy tất cả các chi nhánh của mình để điều khiển từ xa mà không làm phiền ai khác. Nó cũng sẽ giữ hành vi đẩy mặc định mà bạn đã quen. Nếu bạn không muốn điều đó, hãy xóa dòng push = :.

1

Tôi nghĩ điều này phụ thuộc nhiều hơn vào cách kho lưu trữ của bạn được hiển thị và bạn có quyền nào. Về nguyên tắc, bạn chỉ cần một nhánh tạm thời để sử dụng như một "khu vực tiết kiệm" mà bạn đẩy vào repo trung tâm --- Tôi nghĩ bạn đã biết điều đó. Có cách tổng quát để gắn cờ một chi nhánh là "không hiển thị" không? Tôi không tin như vậy, mặc dù bạn có thể thử nghiệm với đẩy đầu địa phương của bạn ref đến kỳ quặc tên refs ở đầu bên kia, ví dụ:

git push central refs/heads/master:refs/remotes/tmp/master 

này sẽ cố gắng để tạo ra "refs/điều khiển từ xa/tmp/master" , đó là một tên hiệu lực hợp lệ nhưng không phải là cái thường được coi là một nhánh. Ví dụ, gitweb sẽ hiển thị một ref như vậy nếu nó xuất hiện trong lịch sử của một trong các nhánh dưới refs/heads/nhưng sẽ không hiển thị danh sách tất cả các ref từ xa.

Ngoài ra, chỉ cần cắn đạn và đẩy đến một chi nhánh có thể nhìn thấy được gọi là "có lẽ-chia-use-tại-bạn-tình trạng nguy hiểm";)

0

Mở dự án nhanh nhẹn, chúng tôi sử dụng nhiều chi nhánh. Chi nhánh mặc định giống như một "thân cây". Mỗi khi tôi bắt đầu một tính năng, tôi phân nhánh và phát triển ở đó. Tôi cam kết, đẩy, đi đến một nơi khác, kéo, cam kết, đẩy. Chi nhánh mặc định vẫn không được chạm vào và mọi người khác không bẻ khóa nhánh của tôi. Khi tôi hoàn thành, tôi hợp nhất chi nhánh vào mặc định.

1

Với Git, bạn thường có riêng kho lưu trữ, không trần nghĩa là nó có thư mục hoạt động. Bạn tạo các cam kết mới ở đó, áp dụng các bản vá lỗi, kéo/lấy từ các kho lưu trữ khác. Kho lưu trữ này được lưu trữ trên máy riêng của bạn.

Sau đó, bạn có công khai kho lưu trữ, có nghĩa là không có kho lưu trữ làm việc. Bạn đẩy vào kho lưu trữ công cộng này (ví dụ: có thể được lưu trữ trên một trong các trang web lưu trữ git như repo.or.cz, GitHub hoặc Gitorious) từ kho lưu trữ riêng tư của bạn khi công việc của bạn ổn định. Bạn có thể đẩy chỉ tập hợp con của các chi nhánh từ kho phát triển tư nhân của bạn cho công kho xuất bản này (ví dụ Git duy trì, Junio ​​C Hamano, không đẩy các ngành chức năng thành công git.git repositoris). Kho lưu trữ công cộng này là nơi những người khác tìm nạp. Việc chia tách này có lợi thế là bạn có thể sửa các cam kết (ví dụ bằng cách sử dụng "git commit --amend") mà không được đẩy vào kho công cộng, và viết lại các phần của lịch sử chỉ xuất hiện trong kho lưu trữ phát triển riêng tư.

1

Trong khi điều này không phải là tư nhân (bất cứ ai trong công ty của bạn có thể nhận được với họ, chỉ cần không theo mặc định, vì vậy nó không gây phiền nhiễu), đây là những gì tôi làm:

Trong ~/.gitconfig

 
[alias] 
    backup = !git push -v origin +refs/heads/*:refs/wip/`git config --get user.email`/* 

Vì vậy, theo cách đó, bạn có thể bất cứ lúc nào trên repo của bạn chạy địa phương:

git backup 

Tất cả các chi nhánh địa phương của bạn (dưới refs/đầu anyway) sẽ được đẩy lên "nguồn gốc" repo dưới refs/wip/your_email/name không gian, vô điều kiện (giống như push -f).

Khi bạn đã sẵn sàng để chuyển sang nguồn gốc/chủ, nếu bạn đã sử dụng để sao lưu công việc của mình, quá trình đẩy sẽ rất nhanh, vì hầu hết (tất cả) đối tượng SHA1 đã sẵn sàng tại máy chủ gốc.

Lưu ý rằng tùy từng thời điểm bạn sẽ muốn xóa các bản sao lưu, để repo gốc có thể thu gom rác. Xem:

 
git ls-remote origin refs/wip/`git config --get user.email`/* 

Điều đó sẽ cung cấp cho bạn danh sách các chi nhánh bạn đã đẩy để sao lưu, để bạn có thể biết/tự động làm gì.

3

Mọi thứ bạn đẩy vào kho lưu trữ được chia sẻ sẽ được phổ biến/có sẵn. Hai tùy chọn đơn giản của bạn là:

  • Tạo kho lưu trữ thứ hai của bạn tại một vị trí riêng biệt và đẩy chi nhánh phát triển của bạn vào cuối mỗi ngày. Bạn sẽ không đẩy nhánh phát triển của bạn đến nhánh ổn định mà mọi người khác sử dụng.

  • Tùy chọn thứ hai không liên quan đến việc lưu trữ toàn bộ thứ hai, nhưng sẽ thực hiện nhiều công việc hơn nữa vào cuối ngày, là xuất bản vá cho công việc của bạn. Phương pháp vá email git chuẩn sẽ dẫn đến tất cả các cam kết của bạn được duy trì trong trường hợp bạn muốn sao lưu mẫu đó. Nén bản vá và tải lên một nơi nào đó.

Các vấn đề liên quan