Một đồng nghiệp của tôi vừa gặp trường hợp này. Trong trường hợp của anh ta, có những cam kết trong cái đầu tách rời - họ làm việc trong R-Studio - và công cụ đã cảnh báo họ rằng họ có thể tạo nhánh bằng tham chiếu SHA này và đó ... nhưng vì tùy chọn duy nhất là "Đóng" --tât nhiên!! đó là một hộp thông tin-- họ đã đóng cuộc đối thoại và mất thông tin mãi mãi ...
Nhờ refloglệnh, chúng tôi có thể thấy rằng các thay đổi không bị mất. Nhưng trong trường hợp của chúng tôi, git branchnó không hoạt động như mong đợi ... hoặc một cái gì đó đến git pullđã làm nó rối tung lên. Chúng tôi phải chỉnh sửa các thay đổi từ bản ghi lại đến nhánh mới được tạo:
git cherry-pick 0b823d42..3cce27fc
đã đặt tất cả các cam kết mà chúng tôi muốn vào chi nhánh. Sau đó, chúng tôi có thể hợp nhất chi nhánh vào developmà không có vấn đề gì.
Chỉ trong trường hợp điều này là thông tin cho bất kỳ ai, chúng tôi đã xác định các cam kết trên đầu riêng biệt trong reflogbằng cách xem xét các cam kết ở giữa được đánh dấu bằng "thanh toán" (xác định sự chuyển dịch nhánh):
e09f183b HEAD@{3}: pull: Fast-forward
b5bf3e1d HEAD@{4}: checkout: moving from lost_changes to develop
b5bf3e1d HEAD@{5}: checkout: moving from 3cce27fca50177a288df0252f02edd5da5ee64fd to lost_changes
3cce27fc HEAD@{6}: commit: add statistics
417a99a4 HEAD@{7}: commit: add test
0b823d42 HEAD@{8}: commit: new utility class
d9ea8a63 HEAD@{9}: checkout: moving from develop to d9ea8a635d4c2349fcb05b3339a6d7fad5ae2a09
b5bf3e1d HEAD@{10}: pull: Fast-forward
Những người chúng ta muốn là HEAD@{8}để HEAD@{6}(cả bao gồm). Vì vậy, chúng tôi nhận được chúng bằng cách:
git cherry-pick 0b823d42..3cce27fc
Sau đó, việc giải quyết hợp nhất thông thường và cam kết cuối cùng đã để lại cho chúng tôi chi nhánh lost_changes lưu trữ công việc đầu tách rời mà chúng tôi nghĩ đã mất. Lần này, việc hợp nhất nó vào phát triển đã diễn ra nhanh chóng.
