Làm thế nào để sao lưu các chi nhánh tư nhân trong git

Question

Tôi có một chi nhánh địa phương cho công việc nhà phát triển hàng ngày trong git. công việc của tôi là:

1. Do tòi trên local_branch, cam kết
2. Fetch nguồn gốc/master
3. rebase local_branch để bắt kịp với công cụ mới từ nguồn gốc/master

Tất cả đều hoạt động tốt, tuy nhiên hầu hết các khuyến nghị tôi gặp phải nói rằng người ta không nên "đẩy" các nhánh tư nhân, mà việc rebase được thực hiện thường xuyên.

Vấn đề ở đây là trong trường hợp này chi nhánh địa phương không được sao lưu đến một máy chủ và cách duy nhất để lưu lại công việc là để hợp nhất lại cho chi nhánh "pushable" (tức là nguồn gốc/master)

gì sẽ là đề xuất của bạn về quy trình làm việc trong trường hợp này?

Cảm ơn!

CẬP NHẬT: Tôi nhận thấy rằng một trong những yêu cầu ban đầu tôi có (tránh sử dụng các tiện ích bên ngoài) là không cần thiết hạn chế.

Giải pháp hiện tại của tôi là lưu trữ tất cả các kho lưu trữ của tôi trong một thư mục được đồng bộ hóa trên đám mây - theo cách này tôi được sao lưu miễn phí.

Answer 1

tôi sử dụng tùy chọn --mirror và đẩy tới một kho lưu trữ sao lưu cá nhân:

Thêm nó như là một từ xa:

git remote add bak server:/path/to/backup/repo 

Thực hiện sao lưu:

git push --mirror bak 

này sẽ tự động làm cho kho lưu trữ sao lưu của bạn trông giống như một trong những hoạt động của bạn - chi nhánh sẽ được tạo ra, xóa, cập nhật (thậm chí bắt buộc/không nhanh) khi cần thiết. Bạn cũng có thể tạo bí danh cho điều này:

git config alias.bak "push --mirror bak" 

Sau đó, chỉ cần chạy "git bak" khi bạn muốn sao lưu. Bạn cũng có thể ném điều này vào một công việc cron.

Answer 2

Bạn có thể thiết lập một kho lưu trữ từ xa khác mà bạn đẩy tất cả các chi nhánh của mình đến không? Điều khác cần xem xét là chỉ sao lưu mọi thứ (quan trọng) trên máy cục bộ của bạn, bao gồm cả repo git.

Answer 3

Không có gì sai khi đẩy đến cùng nhánh mà bạn đang rebasing. Các biểu đồ này sẽ minh họa tại sao điều này hoạt động tốt:

Cho phép nói đây là biểu đồ cam kết trông như thế nào sau khi bạn đã phân nhánh local_branch và thực hiện một vài cam kết với nó (C và D). Ai đó đã thực hiện một cam kết (E) để có nguồn gốc/master kể từ khi bạn phân nhánh local_branch:

 
A -- B -- E [origin/master] 
     \ 
     \  
     \-- C -- D [local_branch] 

Sau đó, sau khi chạy "git rebase nguồn gốc/master", cam kết đồ thị sẽ trông giống như sơ đồ sau. "Nguồn gốc/master" vẫn như cũ, nhưng "local_branch" đã được rebased:

 
A -- B -- E [origin/master] 
      \ 
      \ 
      \-- C -- D [local_branch] 

Ở giai đoạn này, nếu bạn làm "git push gốc local_branch: thạc sĩ", sau đó nó sẽ gây ra một Fast-đơn giản phía trước. "origin/master" và "local_branch" sẽ giống hệt nhau:

 
A -- B -- E -- C -- D [origin/master],[local_branch] 

Bây giờ bạn được tự do làm nhiều việc hơn trên "local_branch". Cuối cùng, bạn có thể nhận được một cái gì đó như thế này:

 
A -- B -- E -- C -- D -- G -- I [origin/master] 
        \ 
         \ 
         \-- F -- H [local_branch] 

Chú ý điều này trông rất giống với đồ thị bắt đầu. Bạn có thể tiếp tục lặp lại quá trình này.

Bạn nên tránh chuyển sang một số chi tiết chi nhánh khác, một chi nhánh mà bạn không phải từ chối. Đó là nơi bạn sẽ gặp rắc rối (với nhánh khác, nó sẽ giống như lịch sử "local_branch's" của bạn đột nhiên được viết lại, sau khi bạn đã bị xóa khỏi "origin/master").

Answer 4

Here's what I do. Nhưng - đây không phải là riêng tư. Tôi làm điều này để tôi có thể cộng tác với bản thân mình (để nói). Nó cho phép tôi làm việc trên cùng một chi nhánh trên hai hoặc nhiều hộp. nếu những người khác có quyền truy cập vào repo được chia sẻ, họ có thể thấy công việc tôi đang làm trên chi nhánh. Tất nhiên, trên repo nhà của tôi, không ai khác có quyền truy cập, do đó, nó vẫn là tư nhân. Trên github, tất cả mọi người đều có thể nhìn thấy đồ của tôi. Giống như họ thực sự quan tâm. ;)

Answer 5

Một lựa chọn khác sẽ được đẩy "local_branch" vào "nguồn gốc" repo, nhưng để chi nhánh riêng của nó trong repo đó (không phải là "bậc thầy"), ví dụ:

git push origin local_branch:local_backup

Sau đó, khi bạn đã sẵn sàng tạo một bản sao lưu khác (và sau khi bạn đã thực hiện một số công việc và rebasing), chỉ cần xóa chi nhánh sao lưu khỏi repo gốc trước khi bạn đẩy nó ra lần nữa:

git push origin :local_backup < === xóa chi nhánh xuất xứ

git push origin local_branch:local_backup

Bằng cách này, bạn sẽ không gặp phải vấn đề khi nhấn "local_branch" sau khi nó đã được rebased từ "origin/master". Và nếu việc xóa các nhánh dự phòng khiến bạn lo lắng (cho đến khi sau khi bạn đã hoàn thành công việc của mình thành "master"), bạn luôn có thể tiếp tục chuyển sang nhánh mới với tên mới (ví dụ "local_backup1", "local_backup2 ", v.v.)

Answer 6

Không có gì sai khi đẩy các nhánh cá nhân. Nó thường được khuyến khích bởi vì mọi người có thể bắt đầu làm việc dựa trên chi nhánh của bạn, và khi bạn rebase, những thay đổi của họ được để lại trôi nổi.

Điều tôi làm là sử dụng tiền tố để biểu thị "đây là chi nhánh của tôi, tự sử dụng nó", như: fc-general-cleanup.

Answer 7

Thay vì dựa vào Dropbox để đồng bộ hóa tất cả các tập tin của một repo git, tôi thà sử dụng git bundle, trong đó sản xuất chỉ một tập tin (bao gồm tất cả các chi nhánh riêng của bạn), và đồng bộ hóa tập tin đó với DropBox .
Xem "Git with Dropbox"

Trong "Backup a Local Git Repository", Yars đề cập có lỗi đồng bộ với Dropbox.