2012-09-11 22 views
9

Tôi đang sử dụng Git để theo dõi một số mã MATLAB. Một ví dụ đồ chơi minh họa tốt nhất vấn đề. Dự án cho đến nay trông như thế này.Tích hợp các thay đổi thụt lề và nội dung trong Git trong quá trình hợp nhất: Các phương pháp hay nhất?

C 
/
A-- 
    \ 
    B 

Nội dung của A là x=5

Chúng tôi làm cam kết C, nơi dòng được thay đổi để x=6

Sau đó chúng tôi thực hiện cam kết B, nơi mà nội dung của chúng tôi trở nên như sau

if flag==1 
    x=5 
end 

Nếu chúng tôi cố gắng hợp nhất với mục tiêu của dự án trông giống như

C 
/\ 
A-- D 
    \/
    B 

với kết quả hợp nhất trong D, chúng tôi sẽ nhận được một xung đột, bởi vì dòng chính đã được thay đổi trong cả hai (thụt lề được thêm vào B, 5 thay đổi thành 6 trong C).

Có cách nào tốt nhất để tích hợp các thay đổi thụt đầu dòng từ một chi nhánh và thay đổi nội dung từ một chi nhánh khác, để có được kết quả hợp nhất không?

Tôi đã đọc về một chiến lược trong https://stackoverflow.com/a/5262473/288545 và trong khi đó sẽ tránh xung đột, nó sẽ loại bỏ thụt lề có lợi cho thay đổi nội dung (đó là cải tiến nhưng vẫn khó đọc mã hơn).

Tôi cho rằng tôi chỉ có thể hút nó và không thay đổi thụt dòng khi viết mã của mình. Điều này làm cho nó ít có thể đọc được, nhưng không phải là một vấn đề lớn trong MATLAB. Tuy nhiên, trong python, thụt đầu dòng thực sự quan trọng, vậy làm thế nào để các folks python đối phó với nó? Điều này trở nên xấu hơn nhiều nếu có các khối mã lớn mà sau này chúng ta thay đổi nằm bên trong các cấu trúc điều khiển, do đó, sự khác biệt chạm vào nhiều dòng và làm cho việc hợp nhất xung đột với một cơn đau đầu lớn.

Có chiến lược hợp nhất nào sẽ xử lý các thay đổi khoảng cách và thay đổi nội dung riêng biệt, sau đó tích hợp chúng không? Tôi muốn kết quả của việc hợp nhất là

if flag==1 
    x=6 
end 
+0

Trong python, chúng tôi hướng mọi người đến 'PEP 8' cho họ biết để thụt lề mã của họ với 4 dấu cách. Sau đó, vì tất cả chúng ta đều viết mã với 4 dấu không gian, chúng ta không phải lo lắng về việc thay đổi thụt lề nữa ... ;-) – mgilson

+5

@mgilson Vấn đề vẫn phát sinh nếu bạn có mã ban đầu độc lập (unindented), và sau đó bạn nhúng nó vào một cấu trúc điều khiển, vì vậy nó phải được thụt vào. Thậm chí nếu bạn hoàn hảo chỉ làm 4 khoảng trắng, bạn vẫn sẽ nhận được xung đột hợp nhất, bởi vì một chi nhánh giới thiệu 4 không gian mới và nhánh kia giới thiệu thay đổi nội dung. –

+0

Nhận xét của tôi chủ yếu là nói đùa. Bạn đang phải tất nhiên. Tuy nhiên, trong trường hợp đó, nó cũng không phải là thụt đầu dòng. Bạn sẽ có xung đột hợp nhất bất cứ khi nào có bất kỳ thay đổi không tương thích nào cho cùng một khối mã. Đó là lý do tại sao git buộc bạn phải đối phó với những thay đổi không tương thích này và kết hợp chúng bằng tay ... tất nhiên, có rất nhiều công cụ bạn có thể thử để làm cho điều này ít đau đớn hơn với 'git mergetool' ... – mgilson

Trả lời

3

Chìa khóa để giải quyết vấn đề của bạn là xử lý các khoảng trắng và viết lại hàm là cam kết riêng biệt.

Là người tích hợp nhiều nhánh, tôi có thể thành thật nói hai điều khó chịu nhất cho các nhà tích hợp là: 1) lập trình viên thích định dạng lại các tệp mà họ không viết hoặc chức năng họ không viết lại và 2 IDEs định dạng lại toàn bộ tệp đơn giản bằng cách mở và lưu chúng. Chắc chắn các tệp có thể đọc được nhiều hơn trong cả hai trường hợp, nhưng nó hoàn toàn đánh bại điểm kiểm soát phiên bản: Các cam kết phải được kích thước, xây dựng và xem xét một cách thông minh. Thứ tự của họ nên có ý nghĩa. Bồn rửa nhà bếp cam kết làm cho lịch sử vô dụng, và lịch sử nên là gì, nhưng hữu ích.

Triết lý này ngụ ý "Không đổ các thay đổi khoảng trắng trong các cam kết mà chúng không thuộc về." Nếu bạn đang viết lại hàm đã chạm, chắc chắn, hãy cải thiện khoảng cách. Nếu không, hãy để nó vào cam kết của chính nó và đảm bảo rằng những người khác làm việc trên tệp đó biết các thay đổi khoảng trắng đang đến. Điều đó sẽ giúp bạn tiết kiệm thời gian tích hợp.

Ngoài ra, bạn có thể tránh các lỗi không gian ngẫu nhiên (dấu cách, dấu cách sau dấu cách và các thứ tương tự) bằng móc trước cổ phiếu của git.Thực hiện lệnh này trong kho lưu trữ của bạn để thiết lập nó:

mv .git/hooks/pre-commit.sample .git/hooks/pre-commit 

Nó nhiều hơn hoặc ít hơn các vấn đề git diff --check, cũng là vô cùng hữu ích cho việc phát hiện các loại vấn đề.

3

Một số công cụ khác biệt tốt hơn các công cụ khác. Tôi sử dụng KDiff3 và thiết lập để được gọi tự động bằng cách sử dụng git mergetool. Nó vẫn không hoàn hảo, nhưng nó thường có thể phát hiện sự kết hợp của các loại bạn mô tả và tự động tạo ra một hợp nhất hợp lý.

Các vấn đề liên quan