Git rebase - tiếp tục khiếu nại ngay cả khi tất cả các xung đột hợp nhất đã được giải quyết


115

Tôi đang phải đối mặt với một vấn đề mà tôi không biết làm thế nào để giải quyết.

Tôi đã thực hiện một cuộc tái cơ sở chống lại chủ từ chi nhánh của mình:

git rebase master

và gặp lỗi sau

 First, rewinding head to replay your work on top of it...
 Applying: checkstyled.
 Using index info to reconstruct a base tree...
 Falling back to patching base and 3-way merge...
 Auto-merging AssetsLoader.java
 CONFLICT (content): Merge conflict in AssetsLoader.java
 Failed to merge in the changes.
 Patch failed at 0001 checkstyled.

Vì vậy, tôi đã đi đến trình chỉnh sửa yêu thích của mình, khắc phục xung đột 1 dòng, lưu tệp và thực hiện trạng thái git và nhận được kết quả sau:

 # Not currently on any branch.
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #  modified:   PassengerContactHandler.java
 #
 # Unmerged paths:
 #   (use "git reset HEAD <file>..." to unstage)
 #   (use "git add/rm <file>..." as appropriate to mark resolution)
 #
 #  both modified:      AssetsLoader.java
 #

Tôi đã thực hiện thêm git AssetsLoader.java và trạng thái git và nhận được như sau:

 # Not currently on any branch.
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #  modified:   AssetsLoader.java
 #  modified:   PassengerContactHandler.java
 #

và khi tôi thực hiện git rebase - tiếp tục, tôi nhận được:

git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

Tôi biết tôi có thể bỏ qua bản vá và tiếp tục rebase, nhưng tôi không chắc liệu những thay đổi trong PassengerContactHandler.java có được đưa vào chi nhánh của tôi hay không.

vì vậy tôi không chắc, Tôi nên tiến hành như thế nào?

Chỉnh sửa: Có thể tệp có xung đột được giải quyết giống hệt như phiên bản gốc không?

Cảm ơn rất nhiều, Lucas

Chỉnh sửa, nó lại xảy ra với tôi:

Nó lại xảy ra với tôi,

(307ac0d...)|REBASE)$ git status
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   assets/world/level1/Level-1.xml
#   modified:   George.java
#   modified:   DefaultPassenger.java
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   mb-art/originalAssets/27dec/

((307ac0d ...) | REBASE) $ git rebase --continue

You must edit all merge conflicts and then
mark them as resolved using git add

git --version

git version 1.7.1

Đó là đầu ra đầy đủ của git status, phải không? Không thiếu phần bên dưới nó?
Cascabel

git-rebasekhông bao giờ được báo cáo rằng có những xung đột chưa được giải quyết nếu không có bất kỳ xung đột nào. Nếu bạn có thể quản lý để tái tạo sự cố trong một trường hợp thử nghiệm đơn giản hơn, thì việc gỡ lỗi sẽ dễ dàng hơn nhiều, tuy nhiên, nếu bạn không có git statusbáo cáo xung đột khi git rebase --continuexảy ra và phiên bản Git của bạn hiện tại, bạn có thể thử gửi email cho nhà phát triển Git danh sách gửi thư tại git@vger.kernel.org với nhiều thông tin chẩn đoán nhất có thể.
Cascabel

1
Nó lại xảy ra với tôi, (307ac0d ...) | REBASE) $ git status # Hiện không có trên bất kỳ chi nhánh nào. # Các thay đổi sẽ được cam kết: # (sử dụng "git reset HEAD <file> ..." để bỏ trang) # # đã sửa đổi: tài sản / thế giới / level1 / Cấp độ-1.xml # đã sửa đổi: George.java # đã sửa đổi: DefaultPassenger.java # # Tệp không theo dõi: # (sử dụng "git add <file> ..." để bao gồm những gì sẽ được cam kết) # # mb-art / originalAssets / 27dec /
Lucas

Tôi nghĩ bạn nên sử dụng GITKRAKEN, nó sẽ giúp bạn giải quyết xung đột
Nikhil Bhardwaj

Câu trả lời:


115

Điều này xảy ra vì khi khắc phục xung đột, bạn đã xóa tất cả mã trong bản vá đang được áp dụng cho nhánh bạn đang khôi phục. Sử dụng git rebase --skipđể tiếp tục.

Thêm một chút chi tiết:

Thông thường, khi khắc phục xung đột trong quá trình khôi phục, bạn sẽ chỉnh sửa tệp xung đột, giữ một số hoặc tất cả mã trong bản vá hiện đang được áp dụng cho nhánh mà bạn căn cứ lại. Sau khi sửa bản vá và làm

git add your/conflicted/file
git status

bạn sẽ nhận được một dòng (thường là màu xanh lá cây) hiển thị tệp đã sửa đổi

đã sửa đổi: của bạn / xung đột / tệp

git rebase --continue sẽ hoạt động tốt trong trường hợp này.

Tuy nhiên, đôi khi, khi giải quyết xung đột, bạn xóa mọi thứ trong bản vá mới của mình, chỉ giữ lại mã từ nhánh bạn đã khôi phục. Bây giờ khi bạn thêm tệp, tệp sẽ giống hệt như tệp bạn đã cố gắng căn cứ lại. trạng thái git sẽ không hiển thị dòng màu xanh lục hiển thị các tệp đã sửa đổi. Bây giờ, nếu bạn làm

git rebase --continue

git sẽ phàn nàn với

Không có thay đổi - bạn đã quên sử dụng 'git add'?

Những gì git thực sự muốn bạn làm trong tình huống này là sử dụng

git rebase --skip

để bỏ qua bản vá. Trước đây tôi chưa bao giờ làm điều này, vì tôi luôn không chắc chắn điều gì sẽ thực sự bị bỏ qua nếu tôi làm vậy, tôi không rõ "bỏ qua bản vá này" thực sự nghĩa là gì. Nhưng nếu bạn không có đường màu xanh lá cây với

đã sửa đổi: của bạn / xung đột / tệp

sau khi chỉnh sửa tệp bị xung đột, thêm nó và thực hiện trạng thái git, thì bạn có thể chắc chắn rằng mình đã xóa toàn bộ bản vá và thay vào đó bạn có thể sử dụng

git rebase --skip

để tiếp tục.

Bài đăng ban đầu cho biết điều này đôi khi hoạt động:

git add -A
git rebase --continue
# works magically?

... nhưng đừng dựa vào điều này (và đảm bảo không thêm các tệp còn sót lại trong các thư mục kho lưu trữ của bạn)


1
Tôi dường như có cùng một vấn đề và cùng một giải pháp, cũng có vẻ kỳ diệu!
bspink

Tôi cũng gặp phải vấn đề tương tự, có vẻ như nếu bạn đã cấu trúc lại trong nhánh đã tái cấu trúc và thêm các tệp mới, sau đó quá trình giải quyết hợp nhất thực hiện các thay đổi đối với các tệp mới đó, bạn cần phải thêm lại chúng một cách rõ ràng.
Ibrahim

Đừng làm điều này trừ khi bạn muốn theo dõi tất cả các tệp rác trong kho lưu trữ của mình.
Jed Lynch

git add ...thực sự khó chịu khi nhập sau khi thay đổi một đống tệp với các đường dẫn dài. Có một git add --all-the-files-i-changedtôi có thể chạy trước đây git rebase continue?
jozxyqk

3
Hãy cẩn thận khi sử dụng lệnh git rebase --skip, bạn có thể mất công việc của mình (các tệp đã chỉnh sửa)
Youness Marhrani


8

Tôi nhận được cảnh báo này khi tôi có các tệp chưa được phân chia. Đảm bảo rằng bạn không có bất kỳ tệp nào chưa được phân trang. Nếu bạn không muốn các tệp chưa được phân giai đoạn thay đổi, hãy hủy các thay đổi với

git rm <filename>  

2
Rất đơn giản, nó có thể là một nhận xét; rất hữu ích, nó phải là một câu trả lời. Cảm ơn!
Lucas Lima

4

Hãy thử chạy điều này trong dòng lệnh của bạn:

$ git mergetool

Sẽ đưa ra một trình chỉnh sửa tương tác cho phép bạn giải quyết các xung đột. Dễ dàng hơn so với việc cố gắng thực hiện theo cách thủ công và git cũng sẽ nhận ra khi bạn thực hiện hợp nhất. Cũng sẽ tránh các tình huống mà bạn không hoàn toàn hợp nhất một cách tình cờ có thể xảy ra khi bạn cố gắng làm điều đó theo cách thủ công.


Chỉ cần nghĩ rằng nó có thể dễ dàng hơn và cũng sẽ cho phép bạn tránh những tình huống như thế này trong tương lai.
Batkins

1
Bạn đã cứu buổi tối của tôi. Mặc dù đó là một công cụ đơn giản, nhưng tôi sẽ không bao giờ có thể tìm ra cách giải quyết xung đột của mình nếu không có công cụ này.
eonil

4

Sau khi khắc phục xung đột, hãy đảm bảo (các) tệp đã thay đổi được thêm vào tệp theo giai đoạn của bạn. Điều này giải quyết các vấn đề đối với tôi.


Điều này đã làm các mẹo cho tôi. Tôi đã kiểm tra Sourcetree sau khi nhận được thông báo được mô tả trong OP, và ngay lập tức thấy hai tệp được đề cập trong cửa sổ lệnh ở đó là không được đánh dấu. Sắp xếp các tệp, chạy "git rebase --continue" và tôi đã trở lại đúng hướng.
Mass Dot Net

3

Bạn đã bỏ lỡ xung đột hợp nhất trong AssetsLoader.java. Mở nó lên và tìm kiếm các điểm đánh dấu xung đột (">>>>", "====", "<<<<<") và sau đó thêm git một lần nữa. Thực hiện 'git diff --staged' nếu bạn gặp khó khăn trong việc tìm kiếm nó.


3
Tôi đã thực hiện grep trên tất cả các tệp được theo dõi và không có dấu hiệu xung đột nào.
Lucas

git diff --stagedtiết lộ điều gì hữu ích không? Điều này cho biết những thay đổi nào bạn sắp thực hiện để giải quyết (các) xung đột hợp nhất tại thời điểm này trong rebase. Sẽ có thông báo "rất tiếc, đó không phải là điều tôi dự định làm để giải quyết vấn đề này" trong một trong các tệp.
Ether

4
Git không tìm kiếm các điểm đánh dấu xung đột hợp nhất khi bạn cố gắng tiếp tục. Nó chỉ kiểm tra xem chỉ mục ở trạng thái sạch. Nếu bạn đã dàn dựng một tệp mà vẫn có các điểm đánh dấu xung đột trong đó, bạn cho biết rằng bạn muốn cam kết với chúng trong đó. Nó có thể luôn luôn là một sai lầm, nhưng nó sẽ cho phép bạn làm điều đó.
Cascabel

@Ether đây hoàn toàn không phải là lý do. Bạn có thể tạo git addmột tệp ngay cả khi có các điểm đánh dấu xung đột trong đó. Rốt cuộc, những tệp như vậy có thể hoàn toàn hợp pháp!
fge

@Jefromi: a ha, hay biết! Tôi luôn cho rằng các điểm đánh dấu đã được kiểm tra, và người ta sẽ cần - buộc vượt qua nó nếu cố ý.
Ether

3

Tôi vừa gặp sự cố này, và mặc dù tôi nghĩ có thể có một vài nguyên nhân, nhưng đây là ...

Tôi đã có một hook git pre-commit đã từ chối các commit trong một số điều kiện nhất định. Điều này tốt khi cam kết theo cách thủ công, vì nó sẽ hiển thị đầu ra của hook và tôi có thể sửa nó hoặc chọn bỏ qua nó bằng commit --no-verify.

Có vẻ như vấn đề là khi khôi phục, rebase --continue cũng sẽ gọi hook (để thực hiện lần thay đổi cuối cùng). Nhưng rebase sẽ không hiển thị đầu ra hook, nó sẽ chỉ thấy rằng nó không thành công và sau đó đưa ra một lỗi ít cụ thể hơn nói rằng 'Bạn phải chỉnh sửa tất cả các xung đột hợp nhất và sau đó đánh dấu chúng là đã được giải quyết bằng cách sử dụng git add'

Để khắc phục, hãy thực hiện tất cả các thay đổi của bạn và thay vì thực hiện 'git rebase --continue', hãy thử 'git commit'. Nếu bạn đang gặp phải vấn đề móc nối tương tự, thì bạn nên xem lý do tại sao nó không thành công.

Điều thú vị là trong khi git rebase không hiển thị đầu ra từ git hook, nó chấp nhận --no-verify để bỏ qua hook.


1
Tôi đã có một vấn đề tương tự. Không có gì khác ở đây phù hợp với tôi, nhưng chỉ cần thực hiện 'git commit' và sau đó hủy bỏ dường như sẽ giải quyết một cách kỳ diệu bất kỳ sự khác biệt nào ở đó và sau đó tôi có thể 'git rebase --continue' thành công.
Patrickvacek

Chỉ đối với hồ sơ, vì tôi đã phải vật lộn với vấn đề tương tự gần đây, git rebasechấp nhận --no-verifytùy chọn. Tuy nhiên, nó chỉ bỏ qua pre-rebasehook, nhưng tùy chọn này không được áp dụng cho các lần gọi tiếp theo tới git commit.
pkrysiak

Chứa một điểm hợp lệ (cam kết thay đổi) nhưng quá dài dòng cho một câu trả lời tốt.
Jack Miller,

1

Tôi chỉ vấp vào vấn đề. Tôi sẽ không git rebase --skipgit statushiển thị rõ ràng các sửa đổi bị đình trệ, mà tôi muốn giữ lại. Mặc dù tôi có một số tệp bổ sung đến bất ngờ. Tôi đã giải quyết với

git checkout .

để xóa các sửa đổi không được gắn thẻ, sau đó git rebase --continueđã thành công.


1

Khi bạn đã sửa các thay đổi của mình, bạn có thể quên chạy 'git add -A'

git add -A
git rebase --continue
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.