Độ phân giải xung đột hợp nhất của git có hiệu quả hơn các SCM và công cụ hợp nhất khác không?

Question

Độ phân giải xung đột hợp nhất của gitvốn có là hiệu quả hơn các SCM khác (CVS, Subversion, v.v.) và cũng có các công cụ hợp nhất độc lập không? Nếu vậy, tại sao?

Làm rõ: tại đây Tôi quan tâm nhiều hơn đến thuật toán - có khác biệt gì so với phương thức diff3 đơn giản không?
Một số công cụ yêu cầu thông minh hơn (ví dụ: Guiffy), có đáng để cắm một công cụ như một công cụ hợp nhất git không? Git có thông minh hơn trong việc tìm ra các đoạn văn bản được di chuyển trong hoặc trên các tệp không? (thay vì báo cáo xung đột ồn ào .. Tôi có một ấn tượng mơ hồ về điều đó từ bài nói chuyện của Linus).

Thông tin cơ bản: đã thực hiện một sự hợp nhất lớn bằng cách sử dụng git-svn dẫn đến một nửa xung đột so với tôi nhận được với đồng bằng svn merge (lần đầu tiên hợp nhất không theo dõi) .. vì vậy tôi muốn hiểu lý do.

---

Tương tự Qs/Vì xung quanh nhưng chúng có nhiều hơn về bức tranh lớn về quy trình và cách kết hợp phù hợp với điều đó một cách tự nhiên hơn. Cuối cùng, git được 'tối ưu hóa cho hòa trộn' (như trái ngược với chỉ phân nhánh), nó thực sự có nghĩa là:

1. ít thủ công xung đột - thuật toán tự động có độ phân giải tốt hơn (. Ví dụ như đổi tên được xử lý độc đáo)
2. hoạt động an toàn hơn - tự động có độ phân giải lá hơn/chỉ xung đột thực và cảnh báo ít sai
3. nhanh hơn hoạt động - nói rằng, do sự nạc & nghĩa mô hình đối tượng
4. tốt hơn công cụ - mà làm cho kinh nghiệm ít đau đớn, ví dụ: theo dõi DAG dựa trên hợp nhất, mergetool, truy vấn lịch sử/visualization, stash, rebase, vv ...
5. cái gì khác
6. một sự kết hợp của các bên trên

? Bây giờ, tôi chủ yếu quan tâm đến 1 & 2.

Answer 1

tôi rất thích được chứng minh là sai về câu trả lời này, nhưng ... đến từ cực chẳng đả ... khu vực này của git là một chút nước kém phát triển.

1. Tự động hợp nhất trong git không tồn tại. Phiên bản mới nhất có hỗ trợ cơ bản để thực hiện hợp nhất bằng cách sử dụng thay đổi của bạn hoặc thay đổi của họ nhưng đó là nó. Về cơ bản, nếu bạn chỉnh sửa một phần của tệp và người khác chỉnh sửa cùng một phần của tệp ... bạn sẽ tự mình giải quyết xong. Các định dạng diff3 có sẵn (3-cách hợp nhất) nhưng tôi tin rằng một định dạng khác biệt thống nhất là tiêu chuẩn. Tôi thực sự sử dụng araxis như công cụ hợp nhất và có nó thiết lập để sử dụng 3 cách hợp nhất khi chạy "git mergetool". Đến từ lực lượng mặc dù ... Tôi cảm thấy như git là cách phía sau trong lĩnh vực này.

2. N/A

Cập nhật RE: bình luận của

tôi đã không đào đủ sâu vào chính xác những gì git nghĩ là một cuộc xung đột và chính xác những gì p4 nghĩ là một cuộc xung đột nhưng đây là những gì tôi đã trải qua cả hai.

• Git không bỏ qua khoảng trắng khi hợp nhất ... mặc dù có nói về điều này trong tương lai cho git. p4 có thể làm điều này ngay bây giờ. Không bỏ qua không gian màu trắng là một nỗi đau lớn trừ khi mọi người trong nhóm đồng ý sử dụng dấu cách hoặc tab và nếu bạn muốn thay đổi tập tin ... (ví dụ: thêm nút xml quanh các nút khác) .
• Tôi cảm thấy như khi tôi bắt gặp xung đột hợp nhất trong một tệp ... các phần mà git nói đang xung đột khi sử dụng định dạng khác biệt thống nhất của nó là lớn hơn. Khi nó chỉ là một phần của một dòng được thay đổi, nó sẽ đánh dấu các phần lớn hơn khi được sửa đổi và bạn cần phải tìm kiếm trực quan các thay đổi giữa hai khu vực của đầu ra khác biệt thống nhất. Bạn có thể loại xung quanh này bằng cách sử dụng một mergetool mặc dù. p4 có thể tự động giải quyết xung đột ngay cả khi chỉnh sửa cùng một dòng.
• Nếu bạn đang hợp nhất các nhánh chủ đề dài tồn tại thì bạn đang ở trong một điều trị thực sự. Nếu không bật lại (được tắt theo mặc định) git sẽ quên rằng bạn đã hợp nhất tệp đó xung đột một tuần trước và sẽ yêu cầu bạn hợp nhất lại. p4 thực hiện điều này một cách dễ dàng

Câu trả lời của tôi ở đây có chút chủ quan ... nhưng tôi rất tiếc việc hợp nhất mà tôi có với lực lượng.

Answer 2

Bên cạnh đó, đây more recent thread (2012) chi tiết khái niệm "tự động có độ phân giải" với Git:

Định nghĩa của tôi để "tự động quyết tâm":
"Trong khi hợp nhất, các tập tin cây làm việc được cập nhật để phản ánh kết quả của việc hợp nhất ... Khi cả hai bên đã thay đổi các vùng khác nhau của cùng một tệp, git chọn cả hai bên một cách tự động và để bạn đảm bảo rằng bạn xem lại các kết quả hợp nhất đó cho đúng sau khi git đã thực hiện hợp nhất cam kết. "

IOW, "tự động giải quyết" có nghĩa là cả hai bên (của chúng tôi và của họ) đã thực hiện thay đổi cho file(a) từ phiên bản tổ tiên chung của file(a) và git đã chọn cả hai mặt mà không tăng xung đột.
(Lý do tôi đưa ra cụm từ "tự động giải quyết" là do trong cụm từ "Tự động hợp nhất", cụm từ "Tự động hợp nhất" cũng có thể chỉ ra rằng một bên (họ) đã thay đổi file(a) từ tổ tiên chung và git đó . chỉ là "nhanh chóng chuyển tiếp" file(a) họ trên đầu trang của chung tổ tiên file(a))

Junio C Hamano tăng trong câu trả lời một điểm quan trọng:

• biết git là ngu ngốc và errs ở bên an toàn, punting bất cứ điều gì từ xa phức tạp;
• biết rằng các xung đột văn bản xảy ra trong cùng một tệp có cùng rủi ro có xung đột ngữ nghĩa trên các tệp khác nhau, vì vậy hãy chọn ra "chạm vào cùng một tệp nhưng không xung đột" bất kỳ đặc biệt nào là vô nghĩa, nhưng trong cả hai trường hợp, cơ hội có xung đột như vậy là đủ nhỏ để hoàn thành việc hợp nhất (và các lần hợp nhất khác) trước và sau đó kiểm tra kết quả tổng thể là sử dụng thời gian hiệu quả hơn, bởi vì bạn phải đánh dấu kết quả ít nhất một lần trước khi đẩy nó ra.