Tuyên bố miễn trừ trách nhiệm: Tôi hiện đã kiểm tra điều này và có vẻ như nó hoạt động như mong đợi (tất nhiên là tôi đã hiểu bạn một cách chính xác). Tuy nhiên, vẫn còn rất nhiều thứ có thể sai. Tuyệt đối chỉ thử điều này trên một bản sao làm việc riêng biệt của kho lưu trữ của dự án của bạn, và đảm bảo kiểm tra mọi thứ trước khi đẩy nó vào bất cứ đâu. Giữ sao lưu toàn bộ thư mục của tiểu bang trước khi bạn làm điều này.
Vì vậy, tôi giả sử bạn có hai kho lưu trữ độc lập.Dự án ban đầu (GEPHI):
A---B---C---D---E
^HEAD of Gephi
Và dự án của bạn, mà phiên bản đầu tiên trông giống hệt với phiên bản cuối cùng của dự án ban đầu của:
E'---V---W---Y---...---Z
^HEAD of your project
(có thể với một số ngành, nhưng điều đó không thực sự quan trọng . ở đây)
Những gì bạn muốn có (nếu tôi hiểu đúng) là:
A---B---C---D---E---V---W---Y---...---Z
Bạn có thể thử những điều sau đây. Một lần nữa, hãy tự làm việc này, tách cây làm việc riêng và đảm bảo mọi thứ đều theo thứ tự trước khi đẩy nó vào bất kỳ kho lưu trữ trung tâm nào!
Trong thời gian ở thư mục của cây làm việc của riêng mình, lấy người đứng đầu và các đối tượng của kho GEPHI gốc:
git fetch /path/to/original/gephi
Nếu bạn chưa nhân bản kho GEPHI, bạn cũng có thể xác định github URL thay vì đường dẫn hệ thống tệp cục bộ.
này sẽ dẫn đến tình huống sau đây trong cây làm việc hiện tại của bạn:
A---B---C---D---E
^FETCH_HEAD
E'---V---W---Y---...---Z
^HEAD
Chúng tôi đã không thay đổi nhiều. Hiện nay, hai đầu cùng tồn tại một cách hòa bình và hoàn toàn độc lập với nhau, nhưng bây giờ bạn có quyền truy cập vào các đối tượng từ cả hai kho và có thể cố gắng kết hợp chúng.
Bây giờ chúng ta muốn loại bỏ E'(nó phải giống với E), và thay vào đó làm cho E phụ huynh của dự án của bạn đầu tiên cam kết, đó là V. Để làm điều này, bạn có thể sử dụng git filter-branch:
git filter-branch -f --parent-filter 'test $GIT_COMMIT = <V> && echo "-p <E>" || cat'
Thay thế <V> và <E> bằng băm cam kết của V và E tương ứng. Để tìm ra những điều đó, bạn có thể thực hiện git log để kiểm tra các cam kết của dự án và, vì chúng tôi đã tìm nạp chúng, git log FETCH_HEAD để kiểm tra các cam kết của Gephi.
này một cách hiệu quả sẽ kết nối trực tiếp đến V E.
Điều này thậm chí nên có tác dụng nếu nó chỉ ra rằng người đứng đầu (tức là cam kết mới nhất) của kho GEPHI gốc không được dự án của bạn những gì bạn dựa trên, ý nghĩa rằng đã có những cam kết mới trong Gephi mà bạn chưa (chưa?) được chăm sóc. Chỉ cần chắc chắn, một lần nữa để thay thế <E> bằng hàm băm của cam kết mà bạn đã dựa trên các thay đổi của mình, không phải là bằng đầu.
Ngược lại, hãy đảm bảo rằng bạn thay thế <V> bằng hàm băm của thay đổi đầu tiên bạn đã thực hiện. Có lẽ kho lưu trữ của bạn không chứa E 'giống hệt E, nhưng cam kết đầu tiên đã chứa các thay đổi đối với bản gốc. Sau đó, băm cam kết đầu tiên này sẽ là <V> của bạn, thay vì mã băm sau đó.
Để tóm tắt cả đoạn cuối cùng: lệnh trên cũng nên làm việc nếu tình hình của bạn trông như thế nào, ví dụ như này:
A---B---C---D---E---F---G---H---I
^ ^FETCH_HEAD
point where your project branched off
V---W---Y---...---Z
^ ^HEAD
first change based on E
Chỉ cần chắc chắn để sử dụng băm có ý nghĩa trong bối cảnh này cam kết.
Tôi vừa thử nghiệm điều này và có vẻ như hoạt động (vì vậy tôi đã cập nhật cảnh báo của mình lên trên). Tôi vẫn hoàn toàn khuyên bạn nên thử điều này trên một cây làm việc dùng một lần và để thực hiện sao lưu đầy đủ. Thật dễ dàng để có được câu lệnh 'filter-branch' sai, hoặc trộn các hash! –
Nếu dự án cục bộ có nhiều nhánh hoặc nếu có bất kỳ sự hợp nhất nào trong lịch sử, 'git rebase' không phải là công cụ phù hợp vì nó sẽ tuyến tính hóa lịch sử. Thay vào đó hãy sử dụng 'filter-branch'. –
Cảm ơn. Đó là những gì tôi đã có ban đầu, nhưng tôi nghĩ rằng rebase có cú pháp dễ dàng hơn. Tôi đã hoàn nguyên các thay đổi và bây giờ nó chỉ đề cập đến nhánh lọc. –