Khi nào bạn sẽ sử dụng các chiến lược hợp nhất git khác nhau?

Từ trang man trên git-merge, có một số chiến lược hợp nhất bạn có thể sử dụng.

• giải quyết - Điều này chỉ có thể giải quyết hai đầu (tức là nhánh hiện tại và nhánh khác mà bạn đã kéo từ đó) bằng thuật toán hợp nhất 3 chiều. Nó cố gắng cẩn thận phát hiện sự mơ hồ hợp nhất chéo và được coi là nói chung an toàn và nhanh chóng.

• đệ quy - Điều này chỉ có thể giải quyết hai đầu bằng thuật toán hợp nhất 3 chiều. Khi có nhiều hơn một tổ tiên chung có thể được sử dụng để hợp nhất 3 chiều, nó sẽ tạo ra một cây hợp nhất của tổ tiên chung và sử dụng đó làm cây tham chiếu cho hợp nhất 3 chiều. Điều này đã được báo cáo dẫn đến ít xung đột hợp nhất hơn mà không gây ra sự hợp nhất sai bởi các thử nghiệm được thực hiện trên các cam kết hợp nhất thực tế được lấy từ lịch sử phát triển nhân Linux 2.6. Ngoài ra, điều này có thể phát hiện và xử lý các hợp nhất liên quan đến đổi tên. Đây là chiến lược hợp nhất mặc định khi kéo hoặc sáp nhập một nhánh.

• bạch tuộc - Điều này giải quyết nhiều hơn trường hợp hai đầu, nhưng từ chối thực hiện hợp nhất phức tạp cần giải quyết thủ công. Nó chủ yếu có nghĩa là được sử dụng để bó các đầu chi nhánh chủ đề lại với nhau. Đây là chiến lược hợp nhất mặc định khi kéo hoặc hợp nhất nhiều chi nhánh.

• của chúng tôi - Điều này giải quyết bất kỳ số lượng đầu, nhưng kết quả của sự hợp nhất luôn luôn là đầu chi nhánh hiện tại. Nó có nghĩa là được sử dụng để thay thế lịch sử phát triển cũ của các nhánh bên.

• cây con - Đây là một chiến lược đệ quy sửa đổi. Khi hợp nhất cây A và B, nếu B tương ứng với cây con của A, B trước tiên được điều chỉnh để phù hợp với cấu trúc cây của A, thay vì đọc các cây ở cùng cấp độ. Điều chỉnh này cũng được thực hiện cho cây tổ tiên chung.

Khi nào tôi nên chỉ định một cái gì đó khác với mặc định? Những kịch bản nào là tốt nhất cho?

Tôi không quen với việc giải quyết, nhưng tôi đã sử dụng những người khác:

Đệ quy

Đệ quy là mặc định cho các hợp nhất không chuyển tiếp nhanh. Chúng ta đều quen thuộc với điều đó.

Bạch tuộc

Tôi đã sử dụng bạch tuộc khi tôi có một số cây cần được sáp nhập. Bạn thấy điều này trong các dự án lớn hơn, nơi nhiều chi nhánh đã có sự phát triển độc lập và tất cả đã sẵn sàng để cùng nhau thành một đầu.

Một nhánh bạch tuộc hợp nhất nhiều đầu trong một lần cam kết miễn là nó có thể làm điều đó một cách sạch sẽ.

Để minh họa, hãy tưởng tượng bạn có một dự án có một chủ, và sau đó ba nhánh để hợp nhất (gọi chúng là a, b và c).

Một loạt các sự hợp nhất đệ quy sẽ trông như thế này (lưu ý rằng sự hợp nhất đầu tiên là một sự chuyển tiếp nhanh, vì tôi đã không ép buộc đệ quy):

Tuy nhiên, một sự hợp nhất bạch tuộc sẽ trông như thế này:

commit ae632e99ba0ccd0e9e06d09e8647659220d043b9
Merge: f51262e... c9ce629... aa0f25d...

Của chúng tôi

Của chúng tôi == Tôi muốn kéo vào một cái đầu khác, nhưng vứt bỏ tất cả những thay đổi mà người đứng đầu giới thiệu.

Điều này giữ cho lịch sử của một chi nhánh mà không có bất kỳ tác động của chi nhánh.

(Đọc: Nó thậm chí không xem xét các thay đổi giữa các nhánh đó. Các nhánh chỉ được hợp nhất và không có gì được thực hiện cho các tệp. Nếu bạn muốn hợp nhất trong nhánh khác và mỗi khi có câu hỏi "phiên bản tệp của chúng tôi hoặc của chúng phiên bản "bạn có thể sử dụng git merge -X ours)

Subtree

Subtree rất hữu ích khi bạn muốn hợp nhất trong một dự án khác vào một thư mục con của dự án hiện tại của bạn. Hữu ích khi bạn có một thư viện mà bạn không muốn đưa vào như một mô hình con.

Trên thực tế, hai chiến lược duy nhất bạn muốn chọn là của chúng tôi nếu bạn muốn từ bỏ các thay đổi do chi nhánh mang lại, nhưng giữ chi nhánh trong lịch sử và phụ thuộc nếu bạn hợp nhất dự án độc lập vào thư mục con của siêu dự án (như 'git-gui' trong ' kho git ').

hợp nhất bạch tuộc được sử dụng tự động khi hợp nhất nhiều hơn hai nhánh. giải quyết ở đây chủ yếu là vì lý do lịch sử, và khi bạn bị ảnh hưởng bởi các trường hợp góc chiến lược hợp nhất đệ quy .

Chiến lược hợp nhất "Giải quyết" và "Đệ quy"

Đệ quy là chiến lược hai đầu mặc định hiện tại, nhưng sau khi tìm kiếm, cuối cùng tôi đã tìm thấy một số thông tin về chiến lược hợp nhất "giải quyết".

Lấy từ cuốn sách O'Reilly Kiểm soát phiên bản với Git ( Amazon ) (diễn giải):

Ban đầu, "giải quyết" là chiến lược mặc định cho việc sáp nhập Git.

Trong các tình huống hợp nhất chéo, khi có nhiều hơn một cơ sở hợp nhất có thể, chiến lược giải quyết hoạt động như thế này: chọn một trong những cơ sở hợp nhất có thể và hy vọng điều tốt nhất. Điều này thực sự không tệ như âm thanh. Nó thường chỉ ra rằng người dùng đã làm việc trên các phần khác nhau của mã. Trong trường hợp đó, Git phát hiện ra rằng nó đang kết hợp lại một số thay đổi đã có và bỏ qua các thay đổi trùng lặp, tránh xung đột. Hoặc, nếu đây là những thay đổi nhỏ gây ra xung đột, ít nhất là xung đột sẽ dễ dàng cho nhà phát triển xử lý ..

Tôi đã hợp nhất thành công các cây bằng cách sử dụng "giải quyết" thất bại với chiến lược đệ quy mặc định. Tôi đã nhận được fatal: git write-tree failed to write a treelỗi, và nhờ bài đăng trên blog này ( gương ) tôi đã thử "giải quyết", nó đã hoạt động. Tôi vẫn không chắc chắn chính xác tại sao ... nhưng tôi nghĩ rằng đó là do tôi đã thay đổi trùng lặp ở cả hai cây và giải quyết "bỏ qua" chúng đúng cách.

Như các câu trả lời ở trên không hiển thị tất cả các chi tiết chiến lược. Ví dụ, một số câu trả lời là mất tích các chi tiết về việc nhập khẩu resolvetùy chọn và recursivecó nhiều lựa chọn phụ như ours, theirs, patience, renormalizevv

Do đó, tôi khuyên bạn nên truy cập gittài liệu chính thức giải thích tất cả các tính năng có thể có:

https://git-scm.com/docs/merge-str Strategies