Nhánh từ xa từ git-svn khá giống với từ xa Git thông thường. Vì vậy, trong kho lưu trữ cục bộ của bạn, bạn có thể có bản sao git-svn của bạn và đẩy các thay đổi ra GitHub. Git không quan tâm. Nếu bạn tạo bản sao git-svn của bạn và đẩy các thay đổi chính xác tương tự ra GitHub, bạn sẽ có một bản sao không chính thức của kho lưu trữ Google Code. Phần còn lại là vanilla Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin [email protected]:example/example.git
git push origin master
Bây giờ bạn có điều này, đôi khi bạn sẽ phải đồng bộ hóa kho lưu trữ Subversion với Git. Nó sẽ giống như thế:
git svn rebase
git push
Trong gitk hoặc bất cứ điều gì, điều này sẽ giống như thế này:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
Và khi bạn chạy git svn rebase, bạn sẽ có điều này:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Vì vậy, bây giờ chạy git push sẽ đẩy những cam kết đó ra GitHub, chi nhánh [điều khiển từ xa/nguồn gốc/chính] tại đó. Và bạn sẽ quay lại kịch bản trong sơ đồ nghệ thuật ASCII đầu tiên.
Vấn đề bây giờ là, cách bạn thực hiện các thay đổi của mình trong hỗn hợp? Ý tưởng là, bạn không bao giờ cam kết vào cùng một nhánh mà bạn đang git-svn-rebase-ing và git-push. Bạn cần một nhánh riêng cho các thay đổi của bạn. Nếu không, bạn sẽ kết thúc việc rebasing các thay đổi của bạn trên đầu trang của Subversion những cái mà có thể làm bất cứ ai làm nhái kho Git của bạn. Theo tôi? OK, vì vậy bạn tạo một chi nhánh, hãy gọi nó là "tính năng". Và bạn thực hiện một cam kết và đẩy nó ra để GitHub đến các chi nhánh tính năng. Gitk của bạn sẽ trông giống như sau:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Ở đây bạn có các tính năng của bạn phân nhánh một vài cam kết trước chi nhánh Google Code, phải không? Vậy điều gì xảy ra khi bạn muốn kết hợp nội dung mới từ Google Code? Bạn muốn chạy git svn rebase đầu tiên và có được điều này:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o/
|/
o[remotes/origin/master]
|
o
Nếu bạn git push chủ ra, bạn có thể tưởng tượng [điều khiển từ xa/gốc/master] là tại cùng một điểm như là bậc thầy. Nhưng chi nhánh tính năng của bạn không có thay đổi. Các lựa chọn của bạn bây giờ là hợp nhất chính vào các tính năng hoặc các tính năng rebase.Hợp nhất sẽ trông giống như thế này
git checkout features
git merge master
o [features]
/|
/o [remotes/origin/features]
[master] o |
| o
o/
|/
o
|
o
Sau đó, bạn đẩy tính năng ra GitHub. Tôi đã để lại các điều khiển từ xa cho chủ để tiết kiệm không gian, chúng sẽ ở cùng một điểm như [chính].
Cách tiếp cận rebase hơi ác hơn - bạn phải push bằng - force vì push của bạn sẽ không phải là sự hợp nhất nhanh (bạn sẽ kéo chi nhánh tính năng từ một người đã nhân bản nó). Nó không thực sự được coi là OK để làm điều này, nhưng không ai có thể ngăn cản bạn nếu bạn được xác định. Nó làm cho một số điều dễ dàng hơn, chẳng hạn như khi các bản vá được chấp nhận ngược dòng ở dạng hơi được làm lại. Nó muốn tiết kiệm có để mess về với các cuộc xung đột, bạn chỉ có thể rebase --skip các bản vá upstreamed. Dù sao, một rebase sẽ như thế này:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o/
|/
o
|
o
Và sau đó bạn sẽ phải git push --force đó. Bạn có thể thấy lý do tại sao bạn cần ép buộc, lịch sử có một chủ nghĩa cũ lớn từ [điều khiển từ xa/nguồn gốc/tính năng] tới +1 hiện tại mới được rebase [tính năng].
Tất cả đều hoạt động, nhưng rất nhiều nỗ lực. Nếu bạn định trở thành người đóng góp thường xuyên, việc đặt cược tốt nhất là làm việc như thế này một lúc, gửi một số bản vá ngược dòng và xem bạn có thể truy cập vào Subversion hay không. Không có điều đó, có lẽ không đẩy những thay đổi của bạn ra GitHub. Giữ chúng ở địa phương và cố gắng để chúng được chấp nhận ngược dòng.
Cảm ơn các hướng dẫn tuyệt vời. ('git' noob here.) Câu hỏi nhanh. Tôi đã làm điều này chống lại một repo SVN lớn và nó đã phát ra ~ 141 megabyte. Tôi đã đẩy nó vào github và sau đó nhân bản nó trở lại, và nó lên đến 130 megabyte. Tôi chạy 'git gc' trên cả hai. Điều gì có thể giải thích cho sự khác biệt? – mpontillo
... đã tìm ra. Tôi cần 'git push origin --mirror'. – mpontillo
Làm việc giống như một sự quyến rũ, bây giờ tôi chỉ cần nói với các devs googlecode gốc để sử dụng github với tôi: D – electblake