Tránh đẩy lịch sử cục bộ không mong muốn vào kho chính trong Bazaar hoặc Mercurial

Question

Tôi mới tham gia DVCS vì vậy có lẽ tôi hiểu nhầm một số khái niệm và thuật ngữ, nhưng đây là ý tưởng về những gì tôi đang cố gắng đạt được cố gắng tìm hiểu xem một trong hai Bazaar hoặc Mercurial có hỗ trợ điều này một cách đơn giản:

Có kho lưu trữ chính với mã được kiểm tra kỹ lưỡng. Nói rằng tôi sao chép (hoặc kéo hoặc chi nhánh hoặc bất kỳ thuật ngữ nào) từ đó vào một kho lưu trữ cục bộ, sau đó mỗi ngày khi tôi làm việc trên mã, tôi cam kết thay đổi cục bộ, đôi khi nhiều lần trong ngày.

Sau khi tôi đang thực hiện với tất cả thay đổi và thử nghiệm của tôi, tôi muốn nhận được chỉ (địa phương) phiên bản mới nhất cam kết của tất cả các tập tin đưa vào kho lưu trữ chính, mà không hàng chục phiên bản trung gian mà tôi cam kết tại địa phương trong gỡ lỗi và thử nghiệm đơn vị.

Từ những gì tôi đã đọc, rõ ràng toàn bộ lịch sử của các phiên bản nửa nướng này sẽ được phản ánh trong kho lưu trữ chính nếu tôi ấn vào nó. Một số bài viết trên internet dường như gợi ý rằng việc rebase có thể giải quyết vấn đề đó nếu nó được xử lý đúng, nhưng nó không rõ ràng nếu/làm thế nào có thể được thực hiện, vì nó có vẻ như rebase là nhiều hơn để tránh một nhánh nhánh/hợp nhất phân nhánh hơn để tránh cam kết của một tập hợp lớn các phiên bản trung gian.

Answer 1

Một số tùy chọn chợ.

1. Nếu bạn muốn loại bỏ hàng chục cam kết cục bộ, bạn thực sự đang vứt bỏ lịch sử. Một cách để thực hiện nó là với lệnh bzr uncommit. ví dụ.

   bzr uncommit -rbranch:https://url_to_mainrepo 
   

   (Vứt bỏ rivisions cho đến khi bạn nhận được để việc rà soát các repo chính. Đừng lo lắng nó sẽ hiển thị cho bạn những gì sẽ được thực hiện và xác nhận với bạn trước khi làm việc đó)

   Sau đó, bạn có thể làm một cam kết mới với tất cả những người khác sụp đổ thành một.

2. Bazaar thường ẩn các bản sửa đổi đã hợp nhất. Một cách để bạn cuộn lên các cam kết nhỏ của bạn thành một bản sửa đổi sáp nhập là giữ một nhánh/thanh toán cục bộ của repo chính. Sau đó, khi bạn đã sẵn sàng, bzr merge trong các thay đổi của bạn vào bản sao repo chính cục bộ của bạn và sau đó cam kết một bản sửa đổi đã hợp nhất.

   Bằng cách này bạn vẫn giữ tất cả lịch sử của mình nhưng tất cả các bản sửa đổi nhỏ được sắp xếp gọn gàng vào bản sửa đổi hợp nhất. Bạn vẫn có thể thấy lịch sử đó khi bạn muốn.

Dưới đây là ví dụ về làm thế nào để không thấy sửa đổi sáp nhập:

$ bzr log 
------------------------------------------------------------ 
revno: 2 [merge] 
message: 
    summary of the things I did 
------------------------------------------------------------ 
revno: 1 
message: 
    some change on the mainline 
------------------------------------------------------------ 
Use --include-merged or -n0 to see merged revisions. 

Dưới đây là ví dụ về cách để xem các phiên bản sáp nhập:

$ bzr log -n0 
------------------------------------------------------------ 
revno: 2 [merge] 
message: 
    summary of the things I did 
    ------------------------------------------------------------ 
    revno: 1.1.2 
    message: 
     my first step 
    ------------------------------------------------------------ 
    revno: 1.1.1 
    message: 
     my second step 
------------------------------------------------------------ 
revno: 1 
message: 
    some change on the mainline 

Answer 2

Các từ khóa mà bạn đang tìm kiếm là sụp đổ hoặc lần (Mercurial) hoặc bí (Git). Tôi sợ tôi không biết thuật ngữ thông thường là gì ở Bazaar.

Trong Mercurial bạn có thể sử dụng histedit extension (một phần mở rộng đi kèm kể từ Mercurial 2.3) để gấp một loạt các thay đổi thành một changeset duy nhất. Nó cung cấp một superset của các chức năng trong bên thứ ba collapse extension.

rebase extension (một tiện ích mở rộng chuẩn khác) có cùng chức năng với cờ --collapse. Bạn hoàn toàn đúng rằng việc rebasing thường được thực hiện để tránh những hợp nhất không cần thiết, nhưng bằng cách nào đó nó cũng đã được sử dụng cho collapsing (and editing) changesets in Git. Các histedit extension cho Mercurial được mô hình hóa sau khi commmand rebase tương tác trong Git.

Answer 3

Trong Bazaar, điều này được xử lý bằng cách một "bản sao" riêng biệt (tức là bzr branch URL) của repo chính tại địa phương và sau đó bạn tạo các chi nhánh tính năng cục bộ từ đó bạn thực hiện công việc của mình với nhiều lần commit. Khi bạn đã sẵn sàng chuyển công việc đó vào repo chính, bạn bzr merge nhánh tính năng vào nhánh chính. Điều đó để lại cho bạn một cây làm việc được sửa đổi trong nhánh chính mà bạn sau đó cam kết và đẩy đến repo chính thức của bạn. Cam kết này bao gồm lịch sử sửa đổi từ chi nhánh tính năng của bạn nhưng nó thường bị ẩn trong bzr log hoặc các chế độ xem lịch sử nhật ký khác.