Quay hoặc chỉnh sửa một số cam kết trước khi thực hiện git-svn dcommit?

Question

Tôi đang làm việc trên một dự án trong kho lưu trữ subversion với chính sách đăng ký nghiêm ngặt bao gồm: Mọi cam kết vào thân cây phải được nhà phát triển khác xem xét và điều này phải được đề cập trong thông báo cam kết.

Khi làm việc với git-svn Tôi đang thực hiện nhiều lần đăng ký git gia tăng chưa được xem xét. Thông điệp cam kết của họ phản ánh điều này.

Cách tốt nhất để sử dụng git-svn nhưng làm theo quy tắc cho kho svn là gì? Tôi có nên bỏ tất cả các cam kết thành một cam kết svn duy nhất? Tôi có thể viết lại thông điệp cam kết cho mỗi bản sửa đổi với thông tin của người đánh giá không? Tôi có thể "tự" di chuyển từng thay đổi riêng lẻ đến nhánh chính của git và sửa đổi thông báo cam kết của mỗi trước khi thực hiện một lệnh git-svn dcommit không?

Answer 1

Bạn tương tác có thể rebase chi nhánh địa phương của bạn chống lại các chi nhánh theo dõi Subversion mà cung cấp cho bạn một cơ hội để dẹp và sửa đổi các cam kết.

Lần sau khi bạn đồng ý, dcommit sẽ phát lại lịch sử của bạn một lần cam kết tại một thời điểm và đây là những gì sẽ được cam kết với Subversion.

Giả định:

1. chi nhánh địa phương là chủ
2. Sư Phụ đang kiểm tra ra
3. chi nhánh theo dõi từ xa được đặt tên git-svn
4. git-svn được cập nhật

Phải làm gì:

$ git rebase -i git-svn 

Trình chỉnh sửa mặc định của bạn sẽ mở ra với danh sách các cam kết trong chính để khởi động lại với git-svn.Bạn có thể chọn, chỉnh sửa hoặc squash cam kết (Trộn và kết hợp nếu muốn).

Sau khi thực hiện lựa chọn của bạn, một tệp tạm thời khác sẽ mở hiển thị thông báo cam kết cho mỗi cam kết bạn đang viết lại. Đây là nơi bạn sửa đổi thông điệp cam kết.

Cẩn thận:

Bạn đang viết lại lịch sử kho lưu trữ, chú ý cẩn thận. Nó có thể là đáng thử nghiệm với hành vi này cho đến khi cảm thấy tự tin.

Answer 2

Có, bạn có thể viết lại thông báo cam kết. Có, bạn chỉ có thể bí mật tất cả trong một cam kết duy nhất. Điều này có thể phụ thuộc vào quá trình xem xét và số tiền bạn đang thực hiện cùng một lúc.

"Thủ công" di chuyển từng thay đổi đến nhánh chính sẽ không khác biệt so với việc viết lại thư cam kết ở một mức nào đó, nhưng nhiều nhánh phân nhánh và lựa chọn anh đào có thể có ích.

Nhìn chung, câu trả lời là "nó phụ thuộc" và "Git đủ linh hoạt để làm mọi thứ bạn cần".

Answer 3

Tôi làm việc trong chi nhánh trên git, sau đó thanh toán chính, git svn rebase và cuối cùng hợp nhất chi nhánh thành trang cái.

Tại thời điểm này, git svn dcommit sẽ đặt tất cả các cam kết tạm thời vào svn một tại một thời điểm với các thư gốc của chúng - không phải điều mong muốn! Nhưng nếu tôi sử dụng git commit --amend để thay đổi thông điệp cam kết hợp nhất từ ​​thông điệp hợp nhất chuẩn thành một cái gì đó phù hợp với chính sách của chúng tôi cho cam kết svn, thì dcommit sẽ gộp tất cả chúng lại với nhau dưới dạng thư mới. Thắng lợi.

Tôi thấy rằng điều này dường như không hoạt động nếu bản gốc không thay đổi trong suốt thời gian của chi nhánh - các cam kết chỉ được chuyển tiếp nhanh, không có thông báo "chi nhánh đã hợp nhất" - vì vậy tốt nhất là thêm cờ --no-ff tới git merge.

Tóm tắt:

git checkout branch 
<do work> 
git checkout master 
git svn rebase 
git merge --no-ff branch 
git commit --amend 
<policy-compliant commit message> 
git svn dcommit 

Answer 4

Điều này có thể là đáng thử, tôi là một newbie tương đối nhưng đây là những gì tôi đang làm bây giờ:

Tạo một bản sao của kho svn từ xa:

# clone svn repository 
git svn clone .... 

Tạo kho bình thường git (clone của clone):

# clone the clone :) 
git clone /path/to/original/clone 
git checkout -b working 

Bây giờ bạn có thể làm việc trong các bản sao thứ hai như thể đó là một kho git bình thường (về cơ bản nó là):

# commit changes, whatever you like 
git ci 
... 

Để đẩy những thay đổi của bạn trở lại kho SVN trung tâm quay trở lại bản sao đầu tiên và:

# pull and flatten changes 
git pull --squash /path/to/working/clone 

Tham số --squash nghĩa là tất cả các cam kết được kéo vào được sáp nhập vào một cam kết. Cam kết đó không được cam kết ngay lập tức để bạn có thể:

git ci 
git svn dcommit 

Bước cuối cùng sau đó đẩy mọi thứ dưới dạng một cam kết duy nhất.

Sửa-tôi sẽ không bình thường khuyên bạn sử dụng --squash trong những hoàn cảnh khác nhưng lưu ý rằng kho làm việc vẫn giữ được toàn bộ lịch sử đầy đủ (đó là miễn dịch với các squash) nhưng những gì bạn gửi ngược dòng được ép vào phạm sạch đơn đó là những gì cần thiết trong trường hợp này. Tôi tin rằng đó là một sự thỏa hiệp hợp lý.