`git svn rebase` vs` git rebase trunk`

Question

Tôi đang làm việc trên một dự án sử dụng subversion cho kho lưu trữ của họ. Bởi vì tôi cần phải thực hiện một số thay đổi mà không thể được gửi đến máy chủ svn, tôi bắt đầu sử dụng git svn để tôi có thể thực hiện đăng ký cục bộ. Thiết lập của tôi trông giống như sau:

Chi nhánh: thân cây (theo dõi svn trunk), chính (gần giống với svn) và chủ đề.

*------------------ trunk 
\ 
    *-----------*--------- master 
       \ 
       *-------- topic 

Workflow:

[on branch master] 
$ git svn fetch 
$ git svn rebase 
$ git checkout -b topic 
$ git rebase master 
[hack hack hack] 
$ git commit -a 
[once upstream is ready for my changes] 
$ git svn fetch 
$ git checkout master 
$ git svn rebase 
$ git checkout topic 
$ git rebase master 
$ git svn dcommit 
$ git checkout master 
$ git svn rebase 
$ git branch -d topic 

Giả sử rằng không ai cam kết svn giữa git svn fetch và git svn rebase, là git svn rebase chạy trên tổng thể về cơ bản giống như git rebase trunk chạy trên bậc thầy?

Có quy trình làm việc hợp lý hơn để sử dụng không? Có vẻ như có rất nhiều chi nhánh đang thay đổi và việc khởi động lại đang diễn ra. Tôi hiểu rằng tôi muốn có thể làm lại công việc của mình trên đầu trang của bất cứ điều gì trong svn, nhưng có vẻ như tôi đang làm nhiều công việc sửa chữa hơn là cần thiết.

Answer 1

Note, từ git svn, như chi tiết trong "Why is the meaning of “ours” and “theirs” reversed with git-svn":

git svn rebase 

này fetches sửa đổi từ phụ huynh SVN của các HEAD hiện tại và rebases dòng điện (không bị giam để SVN) làm việc chống lại nó.

Vì vậy, bạn không cần git svn fetch trước git checkout master và git svn rebase, đặc biệt nếu bạn chỉ theo dõi trunk (mẹ của master) của bạn.

---

điểm Thứ hai, git svn dcommit sẽ tạo ra các phiên bản trong SVN cho mỗi mới cam kết trên master, nhưng công việc của bạn không hiển thị bất kỳ mới cam kết trên master, chỉ có trên topic (mà không bao giờ sáp nhập vào master)

---

các OP Sean McMillan nhận xét:

Theo các tài liệu, git svn dcommit mà không có một branc h được chỉ định đẩy các cam kết trên HEAD hiện tại, không chỉ trên master. Vì vậy, tôi cam kết với SVN từ chi nhánh của tôi, sau đó dựa vào một số git svn rebase trên master để mang lại các cam kết từ SVN. Tôi từ bỏ chi nhánh topic sau khi tôi đã dcommited. Đây không phải là kosher?

Ông chi tiết rằng:

tôi không thể đưa họ đến SVN ... được nêu ra. Upstream muốn "đóng băng" thân cây cho một bản phát hành, trong khi đó, tôi đang làm việc về chức năng cho bản phát hành tiếp theo.

Nhưng câu hỏi cuối cùng là, "là git rebase trunk master giống như git svn rebase trên nhánh chính?" Nếu có, thì tôi không cần phải liên tục thay đổi nhánh của mình, chỉ để rebase chi nhánh chính của tôi chống lại SVN. Nhưng nếu không, và có một loại ma thuật xảy ra khi tôi git svn rebase, tôi muốn biết.

Để mà tôi trả lời:

Một git svn fetch theo sau là một git rebase trunk master sẽ tương đương với một git svn rebase.