Hợp nhất kho lưu trữ git trong thư mục con

Question 1

Tôi muốn hợp nhất một kho lưu trữ git từ xa trong kho lưu trữ git đang làm việc của mình dưới dạng một thư mục con của nó. Tôi muốn kho lưu trữ kết quả chứa lịch sử đã hợp nhất của hai kho lưu trữ và mỗi tệp của kho lưu trữ được hợp nhất sẽ giữ lại lịch sử của nó như trong kho lưu trữ từ xa. Tôi đã thử sử dụng chiến lược cây con như đã đề cập trong Cách sử dụng chiến lược hợp nhất cây con , nhưng sau khi làm theo quy trình đó, mặc dù kho lưu trữ kết quả thực sự chứa lịch sử hợp nhất của hai kho lưu trữ, các tệp riêng lẻ đến từ kho lưu trữ từ xa đã không giữ lại lịch sử của chúng (`git log 'trên bất kỳ mục nào trong số họ chỉ hiển thị thông báo" Chi nhánh đã hợp nhất ... ").

Ngoài ra, tôi không muốn sử dụng mô-đun con vì tôi không muốn hai kho lưu trữ git kết hợp riêng biệt nữa.

Có thể hợp nhất một kho lưu trữ git từ xa vào một kho lưu trữ khác dưới dạng một thư mục con với các tệp riêng lẻ đến từ kho lưu trữ từ xa có lưu giữ lịch sử của chúng không?

Cảm ơn rất nhiều sự giúp đỡ nào.

CHỈNH SỬA: Tôi hiện đang thử một giải pháp sử dụng git filter-branch để viết lại lịch sử kho lưu trữ đã hợp nhất. Nó dường như hoạt động, nhưng tôi cần phải kiểm tra nó một số nữa. Tôi sẽ trở lại để báo cáo về những phát hiện của tôi.

CHỈNH SỬA 2: Với hy vọng làm cho bản thân rõ ràng hơn, tôi đưa ra các lệnh chính xác mà tôi đã sử dụng với chiến lược cây con của git, dẫn đến mất lịch sử rõ ràng của các tệp của kho lưu trữ từ xa. Đặt A là git repo mà tôi hiện đang làm việc và B là git repo mà tôi muốn kết hợp vào A như một thư mục con của nó. Nó đã làm như sau:

git remote add -f B <url-of-B>
git merge -s ours --no-commit B/master
git read-tree --prefix=subdir/Iwant/to/put/B/in/ -u B/master
git commit -m "Merge B as subdirectory in subdir/Iwant/to/put/B/in."

Sau các lệnh này và đi vào thư mục subir / Iwant / to / put / B / in, tôi thấy tất cả các tệp của B, nhưng git logtrên bất kỳ tệp nào trong số đó chỉ hiển thị thông báo cam kết "Hợp nhất B làm thư mục con trong subir / Iwant / to / put /Thùng rác." Lịch sử tệp của họ như ở B đã bị mất.

Những gì có vẻ hoạt động (vì tôi là người mới bắt đầu sử dụng git, tôi có thể sai) là những điều sau:

git remote add -f B <url-of-B>
git checkout -b B_branch B/master  # make a local branch following B's master
git filter-branch --index-filter \ 
   'git ls-files -s | sed "s-\t\"*-&subdir/Iwant/to/put/B/in/-" |
        GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
                git update-index --index-info &&
        mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD 
git checkout master
git merge B_branch

Lệnh trên cho nhánh bộ lọc được lấy từ git help filter-branch, trong đó tôi chỉ thay đổi đường dẫn phụ.

Question 2

Sau khi nhận được lời giải thích đầy đủ hơn về những gì đang xảy ra, tôi nghĩ rằng tôi hiểu nó và trong mọi trường hợp, tôi có một giải pháp khác. Cụ thể, tôi tin rằng những gì đang xảy ra là phát hiện đổi tên đang bị đánh lừa bởi hợp nhất cây con với --prefix. Đây là trường hợp thử nghiệm của tôi:

mkdir -p z/a z/b
cd z/a
git init
echo A>A
git add A
git commit -m A
echo AA>>A
git commit -a -m AA
cd ../b
git init
echo B>B
git add B
git commit -m B
echo BB>>B
git commit -a -m BB
cd ../a
git remote add -f B ../b
git merge -s ours --no-commit B/master
git read-tree --prefix=bdir -u B/master
git commit -m "subtree merge B into bdir"
cd bdir
echo BBB>>B
git commit -a -m BBB

Chúng tôi tạo thư mục git a và b với một số cam kết mỗi thư mục. Chúng tôi thực hiện hợp nhất cây con và sau đó chúng tôi thực hiện cam kết cuối cùng trong cây con mới.

Chạy gitk(theo z / a) cho thấy lịch sử có xuất hiện, chúng ta có thể xem. Đang chạy git logcho thấy rằng lịch sử xuất hiện. Tuy nhiên, việc xem xét một tệp cụ thể có một vấn đề: git log bdir/B

Chà, có một mẹo mà chúng ta có thể chơi. Chúng ta có thể xem lịch sử đổi tên trước của một tệp cụ thể bằng cách sử dụng --follow. git log --follow -- B. Điều này là tốt nhưng không tuyệt vời vì nó không liên kết được lịch sử của việc hợp nhất trước với sau hợp nhất.

Tôi đã thử chơi với -M và -C, nhưng tôi không thể làm cho nó theo một tệp cụ thể.

Vì vậy, giải pháp, tôi cảm thấy, là nói với git về việc đổi tên sẽ diễn ra như một phần của hợp nhất cây con. Thật không may, git-read-tree khá kén chọn hợp nhất cây con nên chúng tôi phải làm việc thông qua một thư mục tạm thời, nhưng điều đó có thể biến mất trước khi chúng tôi cam kết. Sau đó, chúng ta có thể xem toàn bộ lịch sử.

Trước tiên, hãy tạo một kho lưu trữ "A" và thực hiện một số cam kết:

mkdir -p z/a z/b
cd z/a
git init
echo A>A
git add A
git commit -m A
echo AA>>A
git commit -a -m AA

Thứ hai, tạo một kho lưu trữ "B" và thực hiện một số cam kết:

cd ../b
git init
echo B>B
git add B
git commit -m B
echo BB>>B
git commit -a -m BB

Và mẹo để thực hiện điều này : buộc Git nhận ra tên đổi bằng cách tạo một thư mục con và chuyển nội dung vào đó.

mkdir bdir
git mv B bdir
git commit -a -m bdir-rename

Quay lại kho lưu trữ "A" và tìm nạp và hợp nhất nội dung của "B":

cd ../a
git remote add -f B ../b
git merge -s ours --no-commit B/master
# According to Alex Brown and pjvandehaar, newer versions of git need --allow-unrelated-histories
# git merge -s ours --allow-unrelated-histories --no-commit B/master
git read-tree --prefix= -u B/master
git commit -m "subtree merge B into bdir"

Để cho thấy rằng chúng hiện đã được hợp nhất:

cd bdir
echo BBB>>B
git commit -a -m BBB

Để chứng minh toàn bộ lịch sử được lưu giữ trong một chuỗi kết nối:

git log --follow B

Chúng tôi nhận được lịch sử sau khi thực hiện việc này, nhưng vấn đề là nếu bạn thực sự giữ repo "b" cũ xung quanh và thỉnh thoảng hợp nhất từ đó (giả sử nó thực sự là repo được duy trì riêng biệt của bên thứ ba) thì bạn đang gặp rắc rối vì bên thứ ba đó sẽ không thực hiện đổi tên. Bạn phải cố gắng kết hợp các thay đổi mới vào phiên bản b của bạn với tên đổi lại và tôi e rằng điều đó sẽ không suôn sẻ. Nhưng nếu b bỏ đi, bạn thắng.

Question 3

git-subtreelà một tập lệnh được thiết kế cho chính xác trường hợp sử dụng này nhằm hợp nhất nhiều kho lưu trữ thành một trong khi vẫn bảo toàn lịch sử (và / hoặc tách lịch sử của các cây con, mặc dù điều đó dường như không liên quan đến câu hỏi này). Nó được phân phối như một phần của cây git kể từ bản phát hành 1.7.11 .

Để hợp nhất một kho lưu trữ <repo>tại bản sửa đổi <rev>dưới dạng thư mục con <prefix>, hãy sử dụng git subtree addnhư sau:

git subtree add -P <prefix> <repo> <rev>

git-subtree triển khai chiến lược hợp nhất cây con theo cách thân thiện hơn với người dùng.

Các nhược điểm là trong lịch sử sáp nhập các tập tin là không tiền tố (không phải trong một thư mục con). Giả sử bạn hợp nhất kho lưu trữ avào b. Kết quả là git log a/f1sẽ hiển thị cho bạn tất cả các thay đổi (nếu có) ngoại trừ những thay đổi trong lịch sử đã hợp nhất. Bạn có thể làm:

git log --follow -- f1

nhưng điều đó sẽ không hiển thị các thay đổi khác sau đó trong lịch sử hợp nhất.

Nói cách khác, nếu bạn không thay đổi acác tệp trong kho lưu trữ b, thì bạn cần chỉ định --followvà một đường dẫn chưa được định sẵn. Nếu bạn thay đổi chúng trong cả hai kho, thì bạn có 2 lệnh, không lệnh nào hiển thị tất cả các thay đổi.

Thêm về nó ở đây .

Question 4

Tôi muốn

giữ lịch sử tuyến tính mà không có hợp nhất rõ ràng và
làm cho nó trông giống như các tệp của kho lưu trữ đã hợp nhất luôn tồn tại trong thư mục con và do một tác dụng phụ làm cho nó git log -- filehoạt động mà không cần --follow.

Bước 1 : Viết lại lịch sử trong kho lưu trữ nguồn để làm cho nó trông giống như tất cả các tệp luôn tồn tại bên dưới thư mục con.

Tạo một nhánh tạm thời cho lịch sử được viết lại.

git checkout -b tmp_subdir

Sau đó, sử dụng git filter-branchnhư được mô tả trong Làm cách nào để viết lại lịch sử để tất cả các tệp, ngoại trừ những tệp tôi đã di chuyển, đều nằm trong một thư mục con? :

git filter-branch --prune-empty --tree-filter '
if [ ! -e foo/bar ]; then
    mkdir -p foo/bar
    git ls-tree --name-only $GIT_COMMIT | xargs -I files mv files foo/bar
fi'

Bước 2 : Chuyển sang kho mục tiêu. Thêm kho lưu trữ nguồn làm từ xa trong kho lưu trữ đích và tìm nạp nội dung của nó.

git remote add sourcerepo .../path/to/sourcerepo
git fetch sourcerepo

Bước 3 : Sử dụng merge --ontođể thêm các cam kết của kho lưu trữ nguồn được viết lại trên đầu của kho lưu trữ mục tiêu.

git rebase --preserve-merges --onto master --root sourcerepo/tmp_subdir

Bạn có thể kiểm tra nhật ký để thấy rằng điều này thực sự mang lại cho bạn những gì bạn muốn.

git log --stat

Bước 4 : Sau khi rebase, bạn đang ở trạng thái "HEAD tách rời". Bạn có thể tua nhanh cái chủ sang cái đầu mới.

git checkout -b tmp_merged
git checkout master
git merge tmp_merged
git branch -d tmp_merged

Bước 5 : Cuối cùng một số dọn dẹp: Xóa điều khiển từ xa tạm thời.

git remote rm sourcerepo

Question 5

Nếu bạn thực sự muốn ghép mọi thứ lại với nhau, hãy tìm cách ghép. Bạn cũng nên sử dụng git rebase --preserve-merges --onto. Ngoài ra còn có một tùy chọn để giữ ngày tác giả cho thông tin người cam kết.

Question 6

Tôi tìm thấy giải pháp sau đây khả thi đối với tôi. Đầu tiên, tôi đi vào dự án B, tạo một nhánh mới, trong đó tất cả các tệp sẽ được chuyển đến thư mục con mới. Sau đó, tôi đẩy nhánh mới này về nguồn gốc. Tiếp theo, tôi đi đến dự án A, thêm và tìm nạp điều khiển từ xa của B, sau đó tôi kiểm tra nhánh đã chuyển, tôi quay lại chế độ chính và hợp nhất:

# in local copy of project B
git checkout -b prepare_move
mkdir subdir
git mv <files_to_move> subdir/
git commit -m 'move files to subdir'
git push origin prepare_move

# in local copy of project A
git remote add -f B_origin <remote-url>
git checkout -b from_B B_origin/prepare_move
git checkout master
git merge from_B

Nếu tôi vào thư mục phụ subdir, tôi có thể sử dụng git log --followvà vẫn có lịch sử.

Tôi không phải là một chuyên gia về git, vì vậy tôi không thể bình luận liệu đây có phải là một giải pháp đặc biệt tốt hay nó có những lưu ý hay không, nhưng cho đến nay có vẻ như tất cả đều ổn.

Question 7

Bạn đã thử thêm kho lưu trữ bổ sung dưới dạng mô-đun con git chưa? Nó sẽ không hợp nhất lịch sử với kho chứa, trên thực tế, nó sẽ là một kho lưu trữ độc lập.

Tôi đề cập đến nó, bởi vì bạn chưa.

Question 8

Giả sử bạn muốn hợp nhất kho lưu trữ avào b(tôi cho rằng chúng nằm cùng với nhau):

cd a
git filter-repo --to-subdirectory-filter a
cd ..
cd b
git remote add a ../a
git fetch a
git merge --allow-unrelated-histories a/master
git remote remove a

Đối với điều này bạn không cần git-filter-repocài đặt ( filter-branchđược khuyến khích ).

Ví dụ về việc hợp nhất 2 kho lưu trữ lớn, đặt một trong số chúng vào thư mục con: https://gist.github.com/x-yuri/9890ab1079cf4357d6f269d073fd9731

Thêm về nó ở đây .