a

Câu hỏi Cách giải quyết xung đột hợp nhất trong Git


Có cách nào tốt để giải thích làm thế nào để giải quyết xung đột hợp nhất trong Git?


4134
2017-10-02 11:31


gốc


Bài đăng trên blog sau đây dường như đưa ra một ví dụ rất tốt về cách xử lý xung đột hợp nhất với Git để giúp bạn đi đúng hướng. Xử lý và tránh xung đột trong Git - mwilliams
Bạn có thể định cấu hình công cụ hợp nhất (kdiff3) jebaird.com/2013/07/08/…) và sau đó sử dụng git mergetool. Khi bạn làm việc trong các nhóm phát triển lớn, bạn sẽ luôn gặp phải xung đột hợp nhất. - Grady G Cooper
Đừng quên rằng bạn có thể giảm thiểu hầu hết các xung đột hợp nhất bằng cách thường xuyên hợp nhất hạ lưu! - Ant P
Cũng thấy git-tower.com/learn/git/ebook/command-line/tools-services/… - Pacerier
Đây có vẻ là một hướng dẫn chi tiết - githubtraining.com/fix-merge-conflict-git-using-sourcetree - Rajavanya Subramaniyan


Các câu trả lời:


Thử: git mergetool

Nó mở ra một giao diện đồ họa giúp bạn thực hiện từng xung đột và bạn có thể chọn cách hợp nhất. Đôi khi nó đòi hỏi một chút chỉnh sửa tay sau đó, nhưng thường nó là đủ của chính nó. Nó là tốt hơn nhiều so với làm toàn bộ điều bằng tay chắc chắn.

Theo nhận xét của @JoshGlover:

Lệnh này không nhất thiết phải mở GUI trừ khi bạn cài đặt nó. Đang chạy git mergetool cho tôi kết quả vimdiff đang được sử dụng. Bạn có thể cài đặt một trong các công cụ sau để sử dụng thay vào đó: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.

Dưới đây là các thủ tục mẫu để sử dụng vimdiff để giải quyết xung đột hợp nhất. Dựa trên liên kết này

Bước 1: Chạy các lệnh sau trong terminal của bạn

git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false

Điều này sẽ đặt vimdiff làm công cụ hợp nhất mặc định.

Bước 2: Chạy lệnh sau trong terminal

git mergetool

Bước 3: Bạn sẽ thấy màn hình vimdiff ở định dạng sau

  +----------------------+
  |       |      |       |
  |LOCAL  |BASE  |REMOTE |
  |       |      |       |
  +----------------------+
  |      MERGED          |
  |                      |
  +----------------------+

4 lượt xem này là

LOCAL - đây là tệp từ nhánh hiện tại

BASE - tổ tiên chung, tập tin trông như thế nào trước cả hai thay đổi

REMOTE - tệp bạn đang hợp nhất vào chi nhánh của bạn

MERGED - kết quả hợp nhất, đây là những gì được lưu trong repo

Bạn có thể điều hướng giữa các chế độ xem này bằng cách sử dụng ctrl+w. Bạn có thể trực tiếp tiếp cận chế độ xem MERGED bằng ctrl+w theo dõi bởi j.

Thông tin thêm về điều hướng vimdiff đây và đây

Bước 4. Bạn có thể chỉnh sửa chế độ xem MERGED theo cách sau

Nếu bạn muốn nhận các thay đổi từ REMOTE

:diffg RE  

Nếu bạn muốn nhận các thay đổi từ BASE

:diffg BA  

Nếu bạn muốn nhận các thay đổi từ LOCAL

:diffg LO 

Bước 5. Lưu, thoát, cam kết và dọn dẹp

:wqa lưu và thoát khỏi vi

git commit -m "message"

git clean Xóa các tệp thừa (ví dụ: * .orig) được tạo bằng công cụ khác.


2425
2017-10-02 17:50



FYI bạn có thể sử dụng git mergetool -y để lưu một vài lần nhấn phím nếu bạn đang hợp nhất nhiều tệp cùng một lúc. - davr
Vâng, nó không nhất thiết phải mở một GUI trừ khi bạn cài đặt nó. Đang chạy git mergetool cho tôi kết quả vimdiff đang được sử dụng. Bạn có thể cài đặt một trong các công cụ sau để sử dụng thay vào đó: meld opendiff kdiff3 tkdiff xxdiff tortoisemerge gvimdiff diffuse ecmerge p4merge araxis vimdiff emerge. - Josh Glover
Tốt Josh. Trên ubuntu tôi đã có may mắn nhất với meld, màn hình hợp nhất ba cách của nó không phải là xấu. Trên OSX git chọn một mặc định tốt đẹp. - Peter Burns
Điều này đã mở KDiff3. Mà tôi hoàn toàn không có đầu mối làm thế nào để sử dụng. - David Murdoch
Tôi không hiểu tại sao câu trả lời này nhận được rất nhiều upvotes, nó không thực sự rất hữu ích vì nó chỉ chứa một lệnh này và hoàn toàn không có lời giải thích làm thế nào để sử dụng nó. Như những người khác nói, nó đã mở một vimdiff và ngay cả khi tôi biết cách sử dụng vim (chuyển cửa sổ ít nhất hoặc đóng chúng) Tôi thậm chí không biết những gì mỗi cửa sổ đại diện cho cả cách so sánh hoặc chấp nhận các thay đổi. Nó là tốt đẹp để biết có một lệnh như vậy, nhưng không có lời giải thích về cách sử dụng nó hoặc cài đặt các công cụ thứ 3, đó là câu trả lời vô ích - Petr


Đây là trường hợp sử dụng có thể xảy ra, từ trên cùng:

Bạn sẽ kéo một số thay đổi, nhưng oops, bạn không cập nhật:

git fetch origin
git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Updating a030c3a..ee25213
error: Entry 'filename.c' not uptodate. Cannot merge.

Vì vậy, bạn được cập nhật và thử lại, nhưng có xung đột:

git add filename.c
git commit -m "made some wild and crazy changes"
git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Auto-merging filename.c
CONFLICT (content): Merge conflict in filename.c
Automatic merge failed; fix conflicts and then commit the result.

Vì vậy, bạn quyết định xem xét các thay đổi:

git mergetool

Ôi, ôi, thượng nguồn của tôi đã thay đổi một số thứ, nhưng chỉ để sử dụng những thay đổi của tôi ... không ... thay đổi của họ ...

git checkout --ours filename.c
git checkout --theirs filename.c
git add filename.c
git commit -m "using theirs"

Và sau đó chúng tôi thử một lần cuối cùng

git pull origin master

From ssh://gitosis@example.com:22/projectname
 * branch            master     -> FETCH_HEAD
Already up-to-date.

Ta-da!


1610
2017-08-04 17:04



Điều này cực kỳ hữu ích vì tôi có rất nhiều lỗi kết hợp với tệp nhị phân (nội dung nghệ thuật) và việc hợp nhất các tệp đó dường như luôn thất bại, vì vậy tôi cần phải ghi đè tệp đó bằng tệp mới luôn và không "hợp nhất" - petrocket
Cẩn thận! Ý nghĩa của --ours và --theirs được đảo ngược. --ours == điều khiển từ xa. --theirs == local. Xem git merge --help - mmell
Trong trường hợp của tôi, tôi xác nhận rằng --theirs = remote repository, --ours = kho lưu trữ cục bộ của riêng tôi. Nó trái ngược với các bình luận @mmell. - Aryo
@mmell Chỉ trên một rebase, rõ ràng. Xem this question - Navin
Các bạn, "của chúng ta" và "của họ" liên quan đến việc bạn có đang hợp nhất hay rebasing hay không. Nếu bạn hợp nhấtthì "của chúng tôi" nghĩa là nhánh bạn đang hợp nhất và "của họ" là chi nhánh bạn đang hợp nhất. Khi bạn rebasing, sau đó "của chúng tôi" có nghĩa là các cam kết bạn đang rebasing lên, trong khi "của họ" đề cập đến các cam kết mà bạn muốn rebase.


Tôi thấy các công cụ hợp nhất hiếm khi giúp tôi hiểu được xung đột hoặc độ phân giải. Tôi thường thành công hơn khi nhìn vào các điểm đánh dấu xung đột trong một trình soạn thảo văn bản và sử dụng git log làm bổ sung.

Dưới đây là một vài lời khuyên:

Mẹo một

Điều tốt nhất tôi đã tìm thấy là sử dụng kiểu xung đột hợp nhất "diff3":

git config merge.conflictstyle diff3

Điều này tạo ra các điểm đánh dấu xung đột như sau:

<<<<<<<
Changes made on the branch that is being merged into. In most cases,
this is the branch that I have currently checked out (i.e. HEAD).
|||||||
The common ancestor version.
=======
Changes made on the branch that is being merged in. This is often a 
feature/topic branch.
>>>>>>>

Phần giữa là tổ tiên chung trông như thế nào. Điều này rất hữu ích vì bạn có thể so sánh nó với các phiên bản trên cùng và dưới cùng để hiểu rõ hơn về những gì đã được thay đổi trên mỗi nhánh, cung cấp cho bạn ý tưởng tốt hơn về mục đích của mỗi thay đổi.

Nếu xung đột chỉ là một vài dòng, điều này thường làm cho cuộc xung đột rất rõ ràng. (Biết cách sửa chữa xung đột là rất khác nhau, bạn cần phải biết những gì người khác đang làm việc. Nếu bạn bối rối, tốt nhất nên gọi người đó vào phòng của bạn để họ có thể nhìn thấy những gì bạn đang tìm kiếm tại.)

Nếu xung đột dài hơn, sau đó tôi sẽ cắt và dán từng phần trong ba phần vào ba tệp riêng biệt, chẳng hạn như "của tôi", "phổ biến" và "của chúng".

Sau đó, tôi có thể chạy các lệnh sau để xem hai khối khác nhau gây ra xung đột:

diff common mine
diff common theirs

Điều này không giống như sử dụng công cụ hợp nhất, vì công cụ hợp nhất sẽ bao gồm tất cả các khối khác biệt không xung đột. Tôi thấy điều đó khiến tôi mất tập trung.

Mẹo hai

Một người nào đó đã đề cập đến điều này, nhưng hiểu được ý định đằng sau mỗi hunk khác thường rất hữu ích cho sự hiểu biết một cuộc xung đột đến từ đâu và làm thế nào để xử lý nó.

git log --merge -p <name of file>

Điều này cho thấy tất cả các cam kết chạm vào tập tin đó giữa tổ tiên chung và hai đầu bạn đang hợp nhất. (Vì vậy, nó không bao gồm các cam kết đã tồn tại trong cả hai chi nhánh trước khi sáp nhập.) Điều này giúp bạn bỏ qua các khối khác rõ ràng không phải là một yếu tố trong xung đột hiện tại của bạn.

Mẹo ba

Xác minh thay đổi của bạn bằng các công cụ tự động.

Nếu bạn có các kiểm tra tự động, hãy chạy chúng. Nếu bạn có một lint, chạy đi. Nếu đó là một dự án có thể xây dựng, hãy xây dựng nó trước khi bạn cam kết, v.v. Trong mọi trường hợp, bạn cần thực hiện một chút thử nghiệm để đảm bảo rằng các thay đổi của bạn không làm hỏng bất cứ điều gì. (Heck, ngay cả một hợp nhất mà không có xung đột có thể phá vỡ mã làm việc.)

Mẹo Bốn

Lên kế hoạch trước; giao tiếp với đồng nghiệp.

Lập kế hoạch trước và nhận thức được những gì người khác đang làm việc có thể giúp ngăn chặn xung đột hợp nhất và / hoặc giúp giải quyết chúng sớm hơn - trong khi chi tiết vẫn còn mới trong đầu.

Ví dụ: nếu bạn biết rằng bạn và một người khác đều đang làm việc trên các phép tái cấu trúc khác nhau, cả hai đều ảnh hưởng đến cùng một tập hợp, bạn nên nói chuyện với nhau trước và hiểu rõ hơn về các loại thay đổi mà mỗi bạn chế tạo. Bạn có thể tiết kiệm thời gian và công sức đáng kể nếu bạn thực hiện các thay đổi theo kế hoạch của mình một cách thẳng thắn thay vì song song.

Đối với các phép tái cấu trúc chính cắt ngang qua một dải mã lớn, bạn nên cân nhắc làm việc một cách nghiêm túc: mọi người ngừng làm việc trên vùng mã đó trong khi một người thực hiện việc tái cấu trúc hoàn chỉnh.

Nếu bạn không thể làm việc serially (do áp lực thời gian, có thể), sau đó giao tiếp về xung đột hợp nhất dự kiến ​​ít nhất sẽ giúp bạn giải quyết vấn đề sớm hơn trong khi các chi tiết vẫn còn tươi trong tâm trí. Ví dụ: nếu đồng nghiệp đang thực hiện một loạt các cam kết gây rối trong suốt thời gian một tuần, bạn có thể chọn hợp nhất / rebase trên chi nhánh đồng nghiệp đó một lần hoặc hai lần mỗi ngày trong tuần đó. Bằng cách đó, nếu bạn tìm thấy xung đột hợp nhất / rebase, bạn có thể giải quyết chúng nhanh hơn nếu bạn chờ một vài tuần để kết hợp mọi thứ lại với nhau thành một khối lớn.

Mẹo năm

Nếu bạn không chắc chắn về việc hợp nhất, đừng ép buộc.

Việc hợp nhất có thể cảm thấy áp đảo, đặc biệt là khi có rất nhiều tệp xung đột và các điểm đánh dấu xung đột bao gồm hàng trăm dòng. Thông thường, khi ước tính các dự án phần mềm, chúng ta không bao gồm đủ thời gian cho các vật dụng trên không như xử lý một hợp nhất gnarly, vì vậy nó cảm thấy giống như một kéo thực sự để dành vài giờ mổ xẻ từng xung đột.

Về lâu dài, lập kế hoạch trước và nhận thức được những gì người khác đang làm là những công cụ tốt nhất để dự đoán xung đột hợp nhất và chuẩn bị cho mình để giải quyết chúng một cách chính xác trong thời gian ít hơn.


685
2017-09-28 21:08



Tùy chọn diff3 là một tính năng tuyệt vời để có với sự hợp nhất. GUI duy nhất tôi đã xem qua cho thấy nó là của Perforce p4merge, có thể được cài đặt và sử dụng riêng biệt với các công cụ khác của Perforce (mà tôi chưa sử dụng, nhưng đã nghe khiếu nại). - alxndr
Đây là hướng dẫn tốt nhất mà tôi đã tìm thấy trên Internet về "cách khắc phục xung đột hợp nhất" của bạn! - Venkat Sudheer Reddy Aedama
Câu trả lời này là câu trả lời xứng đáng; không phải hai trường hợp trên bị ngập với phiếu bầu; - DJphy
Sau khi một nỗ lực rebase dẫn đến xung đột hợp nhất: đầu ra $ git log --merge -p build.xml: gây tử vong: --merge không có MERGE_HEAD? - Ed Randall
nếu tôi có thay đổi trên một tệp từ branch1 và xóa tệp đó trong branch2. Làm cách nào tôi có thể giải quyết xung đột hợp nhất đó? Có cách nào sử dụng git nơi tôi có thể hợp nhất chúng bằng cách giữ các thay đổi của một chi nhánh không? - Honey


  1. Xác định tệp nào xung đột (Git sẽ cho bạn biết điều này).

  2. Mở mỗi tệp và kiểm tra các khác biệt; Git phân định chúng. Hy vọng rằng nó sẽ được rõ ràng mà phiên bản của từng khối để giữ. Bạn có thể cần phải thảo luận với các nhà phát triển đồng nghiệp đã cam kết mã.

  3. Khi bạn đã giải quyết xung đột trong một tệp git add the_file.

  4. Khi bạn đã giải quyết xong tất cả các xung đột, làm git rebase --continue hoặc bất kỳ lệnh nào Git nói phải làm gì khi bạn hoàn thành.


321
2017-10-02 12:41



@Justin Hãy nghĩ về Git như theo dõi Nội dung thay vì theo dõi tệp. Sau đó, thật dễ dàng để thấy rằng nội dung bạn đã cập nhật không phải trong kho và cần phải được thêm vào. Cách suy nghĩ này cũng giải thích tại sao Git không theo dõi các thư mục trống: Mặc dù chúng là các tệp kỹ thuật, không có bất kỳ nội dung nào để theo dõi. - Gareth
có nội dung, xung đột xảy ra vì có 2 phiên bản nội dung. Do đó "git add" không đúng. Và nó không hoạt động (git add, git commit) nếu bạn muốn cam kết chỉ có một tệp sau khi xung đột được giải quyết ("chết người: không thể thực hiện cam kết một phần trong quá trình hợp nhất.") - Dainius
Có, về mặt kỹ thuật, điều này trả lời câu hỏi mà được hỏi, nhưng không phải là một câu trả lời có thể sử dụng, theo ý kiến ​​của tôi, xin lỗi. Cái gì điểm làm một nhánh giống như một nhánh khác? Tất nhiên hợp nhất sẽ có xung đột .. - Thufir
Thulfir: ai nói gì về việc làm một nhánh giống như một nhánh khác? Có các kịch bản khác nhau mà bạn cần hợp nhất mà không cần "tạo một nhánh giống nhau". Một là khi bạn đã hoàn thành với một chi nhánh phát triển và muốn kết hợp các thay đổi của nó vào nhánh chính; sau này, chi nhánh phát triển có thể bị xóa. Một thứ khác là khi bạn muốn rebase nhánh phát triển của mình, để giảm bớt sự hợp nhất cuối cùng vào master. - Teemu Leisti
@JustinGrant git add các tệp giai đoạn trong chỉ mục; nó có không phải thêm bất kỳ thứ gì vào kho lưu trữ. git commit thêm những thứ vào kho lưu trữ. Việc sử dụng này có ý nghĩa cho việc hợp nhất - việc hợp nhất tự động điều chỉnh tất cả các thay đổi có thể được hợp nhất tự động; bạn có trách nhiệm hợp nhất các thay đổi còn lại và thêm các thay đổi đó vào chỉ mục khi bạn hoàn thành. - Mark E. Haase


Xem câu trả lời trong câu hỏi Stack Overflow Hủy hợp nhất trong Git, đặc biệt Câu trả lời của Charles Bailey cho thấy cách xem các phiên bản khác nhau của tệp có vấn đề, ví dụ:

# Common base version of the file.
git show :1:some_file.cpp

# 'Ours' version of the file.
git show :2:some_file.cpp

# 'Theirs' version of the file.
git show :3:some_file.cpp

97
2017-10-03 15:15



Ngoài ra, hãy kiểm tra tùy chọn "-m" để "git checkout -m" - nó cho phép bạn trích xuất các con ruồi khác nhau trở lại vào không gian làm việc của bạn - qneill
Điều này đã cứu tôi. Nhìn vào mỗi tập tin riêng biệt cho phép tôi nhớ những gì tôi đã đi cho mỗi chi nhánh. Sau đó, tôi có thể đưa ra quyết định để lựa chọn. - Rohmer


Hợp nhất các xung đột xảy ra khi các thay đổi được thực hiện cho một tệp cùng một lúc. Đây là cách giải quyết nó.

git CLI

Dưới đây là các bước đơn giản cần làm khi bạn vào trạng thái xung đột:

  1. Lưu ý danh sách các tệp bị xung đột với: git status (Dưới Unmerged paths phần).
  2. Giải quyết các xung đột riêng biệt cho từng tệp theo một trong các cách tiếp cận sau:

    • Sử dụng GUI để giải quyết xung đột: git mergetool (cách dễ nhất).

    • Để chấp nhận phiên bản từ xa / phiên bản khác, hãy sử dụng: git checkout --theirs path/file. Điều này sẽ từ chối bất kỳ thay đổi cục bộ nào bạn đã thực hiện đối với tệp đó.

    • Để chấp nhận phiên bản địa phương / của chúng tôi, hãy sử dụng: git checkout --ours path/file

      Tuy nhiên bạn phải cẩn thận, vì những thay đổi từ xa mà xung đột đã được thực hiện vì một lý do nào đó.

      Liên quan: Ý nghĩa chính xác của "của chúng ta" và "của họ" trong git là gì?

    • Chỉnh sửa các tệp bị xung đột theo cách thủ công và tìm khối mã giữa <<<<</>>>>> sau đó chọn phiên bản từ phía trên hoặc bên dưới =====. Xem: Xung đột được trình bày như thế nào.

    • Xung đột đường dẫn và tên tệp có thể được giải quyết bằng git add/git rm.

  3. Cuối cùng, xem lại các tệp đã sẵn sàng cho cam kết sử dụng: git status.

    Nếu bạn vẫn còn bất kỳ tệp nào trong Unmerged pathsvà bạn đã giải quyết xung đột theo cách thủ công, sau đó cho Git biết rằng bạn đã giải quyết nó bằng cách: git add path/file.

  4. Nếu tất cả các xung đột đã được giải quyết thành công, hãy cam kết các thay đổi bằng cách: git commit -a và đẩy tới điều khiển từ xa như bình thường.

Xem thêm: Giải quyết xung đột hợp nhất từ ​​dòng lệnh tại GitHub

DiffMerge

Tôi đã sử dụng thành công DiffMerge có thể so sánh trực quan và hợp nhất các tệp trên Windows, macOS và Linux / Unix.

Nó đồ họa có thể hiển thị những thay đổi giữa 3 tập tin và nó cho phép tự động hợp nhất (khi an toàn để làm như vậy) và toàn quyền kiểm soát chỉnh sửa các tập tin kết quả.

DiffMerge

Nguồn hình ảnh: DiffMerge (Ảnh chụp màn hình Linux)

Đơn giản chỉ cần tải về nó và chạy trong repo như:

git mergetool -t diffmerge .

hệ điều hành Mac

Trên macOS, bạn có thể cài đặt qua:

brew install caskroom/cask/brew-cask
brew cask install diffmerge

Và có lẽ (nếu không được cung cấp), bạn cần trình bao bọc đơn giản sau được đặt trong PATH của bạn (ví dụ: /usr/bin):

#!/bin/sh
DIFFMERGE_PATH=/Applications/DiffMerge.app
DIFFMERGE_EXE=${DIFFMERGE_PATH}/Contents/MacOS/DiffMerge
exec ${DIFFMERGE_EXE} --nosplash "$@"

Sau đó, bạn có thể sử dụng các phím tắt sau:

  • - -Alt- -Lên/Xuống để chuyển đến các thay đổi trước đó / tiếp theo.
  • - -Alt- -Trái/Đúng chấp nhận thay đổi từ trái sang phải

Hoặc bạn có thể sử dụng opendiff (một phần của Công cụ Xcode) cho phép bạn kết hợp hai tệp hoặc thư mục với nhau để tạo một tệp hoặc thư mục thứ ba.


88
2017-08-05 14:29





Nếu bạn đang thực hiện các cam kết nhỏ thường xuyên, hãy bắt đầu bằng cách xem xét các nhận xét cam kết với git log --merge. Sau đó git diff sẽ cho bạn thấy những xung đột.

Đối với các xung đột liên quan đến nhiều hơn một vài dòng, sẽ dễ dàng hơn để xem những gì đang xảy ra trong một công cụ GUI bên ngoài. Tôi thích opendiff - Git cũng hỗ trợ vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, emerge ra khỏi hộp và bạn có thể cài đặt những người khác: git config merge.tool "your.tool" sẽ thiết lập công cụ bạn đã chọn và sau đó git mergetool sau khi hợp nhất không thành công sẽ cho bạn thấy sự khác biệt trong ngữ cảnh.

Mỗi khi bạn chỉnh sửa tệp để giải quyết xung đột, git add filename sẽ cập nhật chỉ mục và khác biệt của bạn sẽ không còn hiển thị nữa. Khi tất cả các xung đột được xử lý và các tệp của chúng đã bị git add-ed, git commit sẽ hoàn thành hợp nhất của bạn.


73
2017-10-02 16:11



Sử dụng "git add" là thủ thuật thực sự ở đây. Bạn thậm chí có thể không muốn cam kết (có thể bạn muốn stash), nhưng bạn phải làm "git add" để hoàn tất việc hợp nhất. Tôi nghĩ rằng mergetool không bổ sung cho bạn (mặc dù nó không có trong manpage), nhưng nếu bạn thực hiện hợp nhất theo cách thủ công, bạn cần sử dụng "git add" để hoàn thành nó (ngay cả khi bạn không muốn commit). - nobar


Xem Xung đột được trình bày như thế nào hoặc, trong Git, git merge tài liệu để hiểu những gì các dấu mốc xung đột hợp nhất.

Ngoài ra, Cách giải quyết xung đột phần giải thích cách giải quyết xung đột:

Sau khi nhìn thấy xung đột, bạn có thể làm hai việc:

  • Quyết định không hợp nhất. Bạn chỉ cần xóa sạch tệp chỉ mục cho HEAD cam kết đảo ngược 2. và để làm sạch các thay đổi cây làm việc được thực hiện bởi 2. và 3 .; git merge --abort có thể được sử dụng cho việc này.

  • Giải quyết xung đột. Git sẽ đánh dấu mâu thuẫn trong cây làm việc. Chỉnh sửa các tệp thành hình dạng và git add chúng vào chỉ mục. Sử dụng git commit để niêm phong thỏa thuận.

Bạn có thể làm việc thông qua xung đột với một số công cụ:

  • Sử dụng một mergetool. git mergetool để khởi động một bộ đồ họa đồ họa sẽ làm việc cho bạn thông qua việc hợp nhất.

  • Nhìn vào sự khác biệt. git diff sẽ hiển thị khác biệt ba chiều, làm nổi bật những thay đổi từ cả hai HEAD và MERGE_HEAD phiên bản.

  • Nhìn vào sự khác biệt từ mỗi nhánh. git log --merge -p <path> sẽ hiển thị các khác biệt đầu tiên cho HEAD phiên bản và sau đó là MERGE_HEAD phiên bản.

  • Nhìn vào bản gốc. git show :1:filename cho thấy tổ tiên chung, git show :2:filename cho thấy HEAD phiên bản và git show :3:filename cho thấy MERGE_HEAD phiên bản.

Bạn cũng có thể đọc về các điểm đánh dấu xung đột hợp nhất và cách giải quyết chúng trong Pro Git phần sách Xung đột hợp nhất cơ bản.


43
2017-07-14 18:34





Dành cho Emacs người dùng muốn giải quyết xung đột hợp nhất bán thủ công:

git diff --name-status --diff-filter=U

hiển thị tất cả các tệp yêu cầu giải quyết xung đột.

Mở từng tệp một, hoặc tất cả cùng một lúc bằng cách:

emacs $(git diff --name-only --diff-filter=U)

Khi truy cập bộ đệm yêu cầu chỉnh sửa trong Emacs, hãy nhập

ALT+x vc-resolve-conflicts

Điều này sẽ mở ba bộ đệm (của tôi, của họ, và bộ đệm đầu ra). Điều hướng bằng cách nhấn 'n' (vùng tiếp theo), 'p' (vùng dự kiến). Nhấn 'a' và 'b' để sao chép vùng của tôi hoặc vùng của họ vào bộ đệm đầu ra tương ứng. Và / hoặc chỉnh sửa bộ đệm đầu ra trực tiếp.

Khi hoàn thành: Nhấn 'q'. Emacs hỏi bạn có muốn lưu bộ đệm này không: yes. Sau khi hoàn thành một bộ đệm đánh dấu nó như là giải quyết bằng cách chạy từ teriminal:

git add FILENAME

Khi hoàn thành với tất cả các loại bộ đệm

git commit

để hoàn thành việc hợp nhất.


36
2018-02-22 23:04





Vui lòng làm theo các bước sau để khắc phục xung đột hợp nhất trong Git:

  1. Kiểm tra trạng thái Git: trạng thái git

  2. Nhận bản vá: git fetch (kiểm tra bản vá đúng từ cam kết Git của bạn)

  3. Kiểm tra một chi nhánh địa phương (temp1 trong ví dụ của tôi ở đây): git checkout -b temp1

  4. Kéo nội dung gần đây từ trang cái: git pull --rebase origin master

  5. Khởi động bộ công cụ và kiểm tra các xung đột và sửa chúng ... và kiểm tra các thay đổi trong nhánh từ xa với nhánh hiện tại của bạn: git mergetool

  6. Kiểm tra lại trạng thái:   trạng thái git

  7. Xóa các tập tin không mong muốn cục bộ được tạo bởi mergetool, thường là mergetool tạo thêm tập tin với phần mở rộng * .orig. Vui lòng xóa tệp đó vì đó chỉ là bản sao và sửa các thay đổi cục bộ và thêm phiên bản tệp chính xác của bạn. git add #your_changed_correct_files

  8. Kiểm tra lại trạng thái: trạng thái git

  9. Cam kết các thay đổi đối với cùng một id cam kết (điều này tránh một tập bản vá riêng biệt mới): git commit --amend

  10. Đẩy tới nhánh chính: git push (đến kho lưu trữ Git của bạn)


28
2018-04-16 07:02