Git cho biết chi nhánh cục bộ nằm sau chi nhánh từ xa, nhưng không phải


82

Tình huống:

  1. Tôi tạo một chi nhánh mới
  2. hack vào nó
  3. cam kết nó
  4. đẩy nó
  5. hack vào nó một số nữa
  6. cam kết một lần nữa
  7. cố gắng đẩy một lần nữa

Git trả lời:

Các bản cập nhật đã bị từ chối vì phần ngọn của chi nhánh hiện tại của bạn nằm sau phần đối tác từ xa của nó. Vân vân.

Tôi là người duy nhất hack vào nhánh này - không ai khác chạm vào nó. Chi nhánh từ xa thực sự nằm sau chi nhánh cục bộ. Tôi không cần phải kéo chút nào.

(Và nếu tôi kéo, Git báo cáo xung đột giữa cả hai và buộc tôi phải hợp nhất nhánh vào chính nó)

Tại sao điều này (có thể) xảy ra? Và làm thế nào tôi có thể chẩn đoán / sửa chữa nó?

Để rõ ràng, tôi không phân nhánh ở đâu và không ai khác đang làm việc trên nó:

Remote: Commit A -------- Commit B  

Local:  Commit A -------- Commit B -------- Commit C  

C là đoạn thẳng tiếp nối B, không phân nhánh. Nhưng git cho rằng C là một nhánh của A:

Remote: Commit A -------- Commit B  

                  ------- Commit C  
                /  
Local:  Commit A -------- Commit B  

Nó không thể; nó là sự tiếp nối thẳng của B.


1
Đầu ra của git remote -vgit show remote origin(giả sử nguồn gốc là từ xa mà bạn đang gặp rắc rối với) có thể hữu ích
Ben Graham

Câu trả lời:


196

Bạn có thể đã viết lại lịch sử nào đó? Chi nhánh cục bộ của bạn khác với chi nhánh trên máy chủ. Chạy lệnh này để hiểu rõ hơn về những gì đã xảy ra:

gitk HEAD @{u}

Tôi thực sự khuyên bạn nên cố gắng hiểu lỗi này đến từ đâu. Để khắc phục, chỉ cần chạy:

git push -f

Điều -fnày làm cho điều này trở thành một "thúc đẩy bắt buộc" và ghi đè nhánh trên máy chủ. Điều đó rất nguy hiểm khi bạn đang làm việc theo nhóm. Nhưng vì bạn đang ở một mình và chắc chắn rằng trạng thái địa phương của bạn là chính xác, điều này sẽ ổn. Bạn có nguy cơ mất lịch sử cam kết nếu không phải như vậy.


13
Điều đó là vậy đó. Ở bước 2, tôi đã thực hiện "Sửa đổi cam kết cuối cùng", sau đó đẩy, sau đó tấn công thêm một số nữa, rồi cố đẩy lại. Tôi đã hiểu sai cách thức hoạt động của Amend. Cảm ơn!
Tim Janke

4
Điều này có vẻ thực sự hữu ích - nhưng ai đó có thể giải thích cú pháp 'HEAD @ {u}' không?
ChrisV

5
Cả hai HEAD@{u}tham chiếu đến cam kết. Họ cho gitk biết, những nhánh nào sẽ hiển thị. HEADđề cập đến nhánh hiện đã kiểm tra, @{u}viết tắt của HEAD@{u}, đại diện cho nhánh ngược dòng của nhánh hiện đã kiểm tra. Vì vậy, ví dụ. master, đó là thường origin/master.
Chronial

Có cùng một kịch bản - phải thực hiện quét lại và hợp nhất các xung đột. Sử dụng gitkđã giúp rất nhiều!
brichins

Sẽ xảy ra với tôi nếu tôi thực hiện nhiều cam kết đơn giản tại địa phương (không phải bổ sung) và cố gắng thúc đẩy. Tôi biết không ai khác đang thay đổi mọi thứ trên github. Gitk thực sự hiển thị như điều khiển từ xa khác với cục bộ, mặc dù nó được mong đợi, nó sẽ hiển thị cục bộ như một phiên bản mới hơn điều khiển từ xa chứ không phải điều khiển từ xa dưới dạng ngã ba (trông như vậy, tôi không biết nhiều gitk để nói)
Aquarius Power

5

Giải pháp rất đơn giản và hiệu quả đối với tôi.

Thử đi :

git pull --rebase <url>

sau đó

git push -u origin master

4

Điều này đã xảy ra với tôi khi tôi đang cố gắng đẩy nhánh phát triển (tôi đang sử dụng luồng git). Ai đó đã đẩy cập nhật để làm chủ. để sửa nó, tôi đã làm:

git co master
git pull

Mà đã tìm nạp những thay đổi đó. Sau đó,

git co develop
git pull

Mà không làm gì cả. Tôi nghĩ rằng nhánh phát triển đã được đẩy mặc dù có thông báo lỗi. Mọi thứ đều được cập nhật và không có lỗi.


0

Để chẩn đoán nó, hãy làm theo câu trả lời sau .

Nhưng để khắc phục nó, biết bạn là người duy nhất thay đổi nó, hãy làm:
1 - sao lưu dự án của bạn (tôi chỉ làm các tệp trên thư mục git, ./src)
2 -git pull
3 - khôi phục bản sao lưu của bạn qua nhiều tệp "lộn xộn" ( với các chỉ báo hợp nhất)

Tôi đã thử git pull -s recursive -X ours nhưng không hoạt động theo cách tôi muốn, nó có thể là một lựa chọn tho, nhưng hãy sao lưu trước !!!

Đảm bảo rằng không có sự khác biệt / thay đổi (tại git gui). Đây là trường hợp của tôi, không có gì để hợp nhất cả, nhưng github tiếp tục nói rằng tôi nên hợp nhất ...

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.