2013-08-27 40 views
25

Bối cảnh: Gần đây tôi đã hợp nhất một nhánh chủ đề khá lớn vào master. Một vài ngày sau, tôi phát hiện ra nhánh chủ đề này chứa các lỗi. Vì vậy, tôi git revert -m 1 <merge-commit> chỉnh sửa.rebase branched merged branch

Bài viết: Bây giờ tôi muốn kiểm tra nhánh chủ đề và rebase nó chống lại hiện tại master để tôi có thể 1) sửa lỗi và 2) (một lần nữa) hợp nhất nhánh cố định lên chủ. Tạo chi nhánh mới, fixedtopic là phần dễ dàng, nhưng mỗi khi tôi làm

git checkout fixedtopic 
git rebase master 

git quyết định rằng nó không phải là sẵn sàng để phát lại các cam kết cũ vì họ đã được sáp nhập vào master. Thay vào đó nó chỉ đơn giản là một rebase nhanh về phía trước.

Câu hỏi: Làm cách nào để buộc phát lại các cam kết lên fixedtopic bằng cách sử dụng rebase? Tôi có thể? Tôi không muốn sử dụng cherry-pick vì nó hơi cồng kềnh hơn một chút.

bổ sung:

  • git reset ing hợp nhất cam kết nó không phải là một lựa chọn, vì tôi đã đẩy thầy thượng nguồn.
  • Tôi không muốn tạo chi nhánh mới ngoài số master và hoàn nguyên quy trình hoàn nguyên của mình. Lý do cho điều này là tôi muốn viết lại một số lịch sử của nhánh chủ đề bằng cách sử dụng rebase tương tác.
  • Dưới đây là một ý chính github của kịch bản: https://gist.github.com/JensRantil/6352495 Lưu ý rằng tôi muốn e8df5ec và ee16464 được áp dụng trên master (hoặc chi nhánh dựa trên master).
+2

Đồng nghiệp và gần đây tôi đã gặp phải vấn đề chính xác này với chi nhánh tính năng. Giải pháp của chúng tôi ít nhiều giống như giải pháp được chấp nhận, nhưng chúng tôi đã chọn để đè bẹp tất cả các cam kết từ chi nhánh thành một cam kết duy nhất. Đó là chức năng tương đương để hoàn nguyên việc hoàn nguyên, điều này đơn giản hơn rất nhiều. Chỉ cần một lưu ý cho những người phải đối mặt với vấn đề này trong tương lai. – sirosen

Trả lời

9

Một cách để đạt được điều này là để tương tác rebase chi nhánh chủ đề và viết lại cam kết đầu tiên sau khi phân nhánh trong tổng thể (ví dụ: git rebase -i HEAD~10 nếu bạn có 10 cam kết trong nhánh). Điều này sẽ viết lại sha của tất cả các cam kết bên trong nhánh chủ đề. Vì vậy, bạn sẽ có thể rebase theo cách thông thường với git rebase master.

+1

Để giúp làm rõ: "viết lại cam kết đầu tiên" có nghĩa là thông điệp * cam kết * – jdunk

+0

bạn cũng có thể sử dụng --no- ff tùy chọn, nó làm điều tương tự. – theannouncer

+1

Tác vụ này (không còn?) Hoạt động. – Flimzy

1

Bạn cần sử dụng --onto để ngăn hình thức Git cố tự xác định các cam kết chưa được hợp nhất.

Ví dụ: (Với chi nhánh chủ đề kiểm tra ra):

git rebase --onto master <id-of-branch-point> 

Đối <id-of-branch-point> bạn muốn git merge-base của chi nhánh chủ đề của bạn và cam kết về chủ trước hợp nhất mà bạn quay trở.

Sửa

Đọc lại tình hình của bạn một lần nữa, nó thể là một tốt hơn nếu bạn nhanh chóng chuyển tiếp chi nhánh chủ điểm mà bạn quay trở việc hợp nhất, sau đó phục hồi các đảo chiều và sửa chủ đề chi nhánh từ điểm đó. Bằng cách này, bạn sẽ không nhận được một sự lặp lại của tất cả các cam kết trong nhánh chủ đề ban đầu nhưng với các id mới trong lịch sử cuối cùng của chủ. Dù bạn làm gì, bạn sẽ kết thúc với một lịch sử liên quan đến "làm, hoàn tác, làm lại", nhưng cách này có thể được coi là một lịch sử rõ ràng hơn.

+0

Charles, cảm ơn câu trả lời của bạn. Tôi vẫn không thể có được công việc này ngay cả với '--onto'. Tôi đã cập nhật câu hỏi của mình với Gistub Gist để có một ví dụ làm việc về tình huống tôi đang ở. – Ztyx

0

Điều gì có vẻ hiệu quả nhất là kiểm tra nhánh mới và sau đó kích hoạt lại nhánh đang hoạt động trước bằng cách hoàn nguyên hoàn nguyên.

Mọi thứ khác mà tôi đã thử quá phức tạp và/hoặc không hoạt động.

9

Tài liệu (git help rebase) gợi ý rằng "git rebase --force-rebase" chỉ thực hiện điều này - nhưng (Git 1.9.1) thì không. Tài liệu cũng cho thấy rằng "git rebase -i --no-ff" tương đương với lệnh đó - nhưng không phải là: nó hiện hoạt động.

Sau khi nhân bản ý chính của bạn, các lệnh:

git checkout topic 
    git rebase -i --no-ff --onto master 7b3af topic 

tạo ra kết quả mong muốn, với các phiên bản mới của "ba" và "thứ tư" cam kết trên đầu trang của thầy, và topic chỉ vào phiên bản mới của "thứ tư". Trong lệnh thứ hai, SHA 7b3af là cam kết "thứ hai", điểm mà topic được phân nhánh từ.

+1

Tại sao '--force-rebase' không hoạt động như quảng cáo ?! –