2012-09-29 29 views
72

Kịch bản:Git nói chi nhánh địa phương là đằng sau chi nhánh ở xa, nhưng nó không phải

  1. tôi thực hiện 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ố chi tiết
  6. cam kết lại
  7. cố gắng đẩy một lần nữa

Git đáp ứng:

cập nhật đã bị từ chối vì là đỉnh của chi nhánh hiện tại của bạn là đằng sau đối tác từ xa của nó. v.v.

Tôi là người duy nhất xâm nhập vào nhánh này - không ai khác đang chạm vào nó. Chi nhánh từ xa thực tế là phía sau chi nhánh địa phương. Tôi không cần phải kéo cả.

(Và nếu tôi kéo, Git báo cáo mâu thuẫn giữa hai, và buộc tôi để hợp nhất các chi nhánh vào bản thân)

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

Để được rõ ràng, tôi không phân nhánh ở bất cứ đâ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à một sự tiếp nối thẳng của B, không thành lập chi nhánh liên quan. Nhưng git nghĩ C là chi nhánh của A:

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

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

Nó không phải; đó là sự tiếp tục liên tục của B.

+1

Sản lượng của 'git remote -v' và 'git chương origin' từ xa (giả sử nguồn gốc là từ xa mà bạn đang gặp rắc rối với) có thể là hữu ích –

Trả lời

182

Bạn có thể đã viết lại lịch sử? Chi nhánh địa phương của bạn được phân tách từ một 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 được lỗi này đến từ đâu. Để khắc phục điều đó, chỉ cần chạy:

git push -f 

Các -f làm cho điều này một “đẩy buộc” và ghi đè chi nhánh trên máy chủ. Điều đó rất nguy hiểm khi bạn làm việc theo nhóm. Nhưng vì bạn đang ở một mình và chắc chắn rằng đị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 là trường hợp.

+12

Đó là nó. Ở bước 2, tôi đã thực hiện một "Sửa đổi Cam kết cuối cùng", sau đó bị đẩy, sau đó tấn công thêm một số, sau đó cố gắng đẩy một lần nữa. Tôi hiểu lầm cách mà Amend làm việc. Cảm ơn! –

+3

Đ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}'? – ChrisV

+3

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

4

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

git co master 
git pull 

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

git co develop 
git pull 

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

0

Để chẩn đoán, hãy theo dõi this answer.

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

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

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

0

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

Hãy thử điều này:

git pull --rebase <url> 

sau đó

git push -u origin master 
Các vấn đề liên quan