2013-04-03 25 views
5

Có một chi nhánh trên repo bên thứ 3 mà tôi muốn thêm làm thư mục phụ của repo của tôi. Tôi muốn có thể thực hiện thay đổi đối với mã của bên thứ ba đó, duy trì những thay đổi đó trong repo của tôi và vẫn có thể nhận được các bản cập nhật được thực hiện cho repo bên thứ ba. Về bản chất, tôi đang cố tạo một lớp phủ.Git subtree hợp nhất, nhưng giữ các thay đổi cục bộ?

Làm theo hướng dẫn here để sáp nhập subtree (mô tả chính xác những gì tôi đang cố gắng hoàn thành), tôi đã tạo một điều khiển từ xa trỏ đến repo bên thứ ba đó, tạo một chi nhánh địa phương tham chiếu đến nhánh xa mà tôi muốn, thực hiện một pull trên nhánh đó, và sử dụng read-tree để sao chép nội dung của nhánh nội bộ vào một thư mục con trong master.

Tôi đã cam kết và đẩy các thay đổi (tệp mới và chỉnh sửa cho các tệp hiện có) trong thư mục con này để làm chủ. Các thay đổi cũng đã được thực hiện đối với các tệp khác nhau trong nhánh thượng nguồn. Tôi đã có thể kéo các thay đổi xuống nhánh của tôi. Tuy nhiên, khi tôi cố hợp nhất như sau,

git merge --squash -s subtree --no-commit <my_branch> 

Thay đổi cục bộ của tôi bị ghi đè bởi các thay đổi ở phía trên. Các tệp mới tôi đã tạo sẽ bị xóa và những thay đổi tôi đã thực hiện cho các tệp hiện có bị mất.

Tôi có làm điều gì đó sai hoặc là hành vi mong đợi không? Làm cách nào để giữ các thay đổi của tôi và vẫn hợp nhất các thay đổi từ thượng nguồn?

+0

Tôi gặp vấn đề tương tự, bạn có tìm thấy giải pháp không? – gregseth

+0

@gregseth Tôi xin lỗi, nhưng không. May mắn thay tôi đã không cần phải giải quyết nó. Tôi nên chạy một lúc khác vào nó đôi khi và đưa ra câu trả lời ở đây một lắc tốt hơn. Vui lòng cho tôi biết nếu bạn tìm thấy giải pháp phù hợp với mình! – Naenyn

Trả lời

-1

Theo nguyên tắc chung, bạn muốn thực hiện các thao tác trên một cây làm việc sạch. Git sẽ hủy bỏ nếu nó sẽ cần ghi đè lên những thay đổi không cam kết.

Bạn có thể sử dụng git stash để tạm thời lưu trữ những thay đổi chưa được bổ sung đó, để bạn có thể thực hiện hợp nhất và git stash pop để áp dụng lại và xóa dấu sao.

+0

Các thay đổi cục bộ đã được cam kết và đẩy. Tôi không có gì để cất giấu. Bản cập nhật được ghi đè lên những thay đổi đó .. về cơ bản, thay thế mọi thứ bằng upstream bất kể trạng thái của nó là gì. Tôi cho rằng tôi nên sử dụng các từ ngữ khác nhau.Bởi "địa phương" ở đó, tôi có nghĩa là nguồn gốc của tôi/chủ như trái ngược với thượng nguồn. – Naenyn

+0

Bạn đang làm '-s ours' . Điều đó có nghĩa là nó chỉ chọn một mặt của lịch sử. Bạn mong chờ gì nữa? – Ikke

+0

Rất tiếc, lỗi của tôi, tôi đã dán nhầm thông tin. Tôi thực sự đang làm '-s subtree'. Tôi sẽ chỉnh sửa câu hỏi cho phù hợp. Trên một mặt lưu ý, '-s ours' sẽ hoàn toàn bỏ qua những thay đổi ngược dòng, điều ngược lại với những gì tôi đang trải qua. – Naenyn

1

Tôi không tin rằng đây là hành vi mong muốn, tuy nhiên tôi chỉ làm việc thông qua một vấn đề tương tự.

Trong trường hợp của tôi, hóa ra vấn đề là khi nhà phát triển khác ban đầu thêm cây con vào nhánh chính, anh ấy đã thêm nhiều subtrees cùng một lúc. Điều này có kết quả của việc thay đổi SHA của cam kết kết quả.

Do đó, khi tôi cố gắng thực hiện hợp nhất subtree, git không thể tìm thấy cha mẹ chung. Điều này có kết quả cuối cùng của git giả định rằng tất cả mọi thứ trong cây địa phương của tôi đã được dự định để predate mã từ repo ban đầu, và sau khi hoàn thành hợp nhất các thay đổi địa phương đã bị mất.

Tôi đã thực hiện việc này bằng cách thực hiện git log --oneline trong thư mục tiền tố của subtree và xác định cam kết đầu tiên vào repo cục bộ.

Sau đó,

git checkout -b <subtree>_merge <first commit SHA> 
git merge --squash -s subtree --no-commit <subtree_remote/ref> 
git checkout master 
git merge <subtree>_merge 

này nên để lại cho bạn với cùng một kết quả bạn mong chờ để nhìn thấy từ một cây con thành công hợp nhất từ ​​trên xuống.

+0

Vì mục đích rõ ràng, ' _merge' là tên của chi nhánh mới, vì vậy bất kể tên nào. '' là commit đầu tiên khi ban đầu bạn thêm nội dung subtree vào repo của bạn, commit SHA rằng 'git log --oneline' sẽ giúp bạn nhớ. Tuy nhiên, những gì tôi lo lắng là thủ tục này không "liên kết" repo chính với repo subtree ''. Cuối cùng, nó liên kết nó với nhánh mới được tạo "đã hợp nhất", là một sự kết hợp kỳ lạ của repo cũ của bạn tại '' với thư mục con subtree được đồng bộ hóa với từ xa, không có thay đổi cục bộ. – KrisWebDev

Các vấn đề liên quan