Nhiều thư mục làm việc với Git?

Tôi không chắc đây có phải là thứ được Git hỗ trợ hay không, nhưng trên lý thuyết có vẻ như nó sẽ hoạt động với tôi.

Quy trình làm việc của tôi thường liên quan đến việc tôi chỉnh sửa các tệp trong nhiều nhánh cùng một lúc. Nói cách khác, tôi thường muốn mở một vài tệp trong một nhánh là trong khi tôi chỉnh sửa nội dung của tệp khác trong nhánh khác.

Giải pháp điển hình của tôi cho vấn đề này là thực hiện hai lần thanh toán, nhưng thật xấu hổ khi tôi không thể chia sẻ các chi nhánh và giới thiệu giữa chúng. Những gì tôi muốn là chỉ có hai thư mục làm việc được quản lý bởi cùng một thư mục .git.

Tôi biết về các giải pháp nhân bản git cục bộ (mặc định, là các đối tượng chia sẻ liên kết cứng và tùy chọn - chia sẻ, thiết lập một kho đối tượng thay thế với repo gốc), nhưng các giải pháp này chỉ cắt giảm việc sử dụng không gian đĩa và đặc biệt là trong trường hợp - chia sẻ, dường như đầy nguy hiểm.

Có cách nào để sử dụng một thư mục .git và có hai thư mục hoạt động được hỗ trợ không? Hoặc Git được mã hóa cứng để chỉ có một thư mục làm việc được kiểm tra bất cứ lúc nào?

Git 2.5 đề xuất kể từ tháng 7 năm 2015 thay thế cho contrib/workdir/git-new-workdir: git worktree

Xem cam kết 68a2e6a của Junio ​​C Hamano ( gitster) .

Các phiên bản lưu ý đề cập đến :

Một sự thay thế cho contrib/workdir/git-new-workdirđiều đó không dựa vào các liên kết tượng trưng và làm cho việc chia sẻ các đối tượng và giới thiệu an toàn hơn bằng cách làm cho người vay và người vay biết về nhau.

Xem cam kết 799767cc9 (Git 2.5rc2)

Điều đó có nghĩa là bây giờ bạn có thể làm mộtgit worktree add <path> [<branch>]

Tạo <path>và kiểm tra <branch>vào nó. Thư mục làm việc mới được liên kết với kho lưu trữ hiện tại, chia sẻ mọi thứ trừ các tệp cụ thể của thư mục làm việc như HEAD, index, v.v. Phần git worktreenày thêm:

Kho git có thể hỗ trợ nhiều cây làm việc , cho phép bạn kiểm tra nhiều nhánh cùng một lúc.
Với git worktree add, một cây làm việc mới được liên kết với kho lưu trữ.

Cây làm việc mới này được gọi là "cây làm việc được liên kết" trái ngược với "cây làm việc chính" được chuẩn bị bởi " git init" hoặc " git clone" .
Kho lưu trữ có một cây làm việc chính (nếu đó không phải là kho lưu trữ trần) và không hoặc nhiều cây làm việc được liên kết.

chi tiết:

Mỗi cây làm việc được liên kết có một thư mục con riêng trong thư mục của kho lưu trữ $GIT_DIR/worktrees.
Tên của thư mục con riêng thường là tên cơ sở của đường dẫn của cây làm việc được liên kết, có thể được thêm vào một số để làm cho nó là duy nhất.
Ví dụ: khi $GIT_DIR=/path/main/.gitlệnh git worktree add /path/other/test-next nexttạo:

• cây làm việc được liên kết trong /path/other/test-nextvà
• cũng tạo một $GIT_DIR/worktrees/test-nextthư mục (hoặc $GIT_DIR/worktrees/test-next1nếu test-nextđã được thực hiện).

Trong một cây làm việc được liên kết:

• $GIT_DIRđược đặt để trỏ đến thư mục riêng này (ví dụ /path/main/.git/worktrees/test-nexttrong ví dụ) và
• $GIT_COMMON_DIRđược đặt để quay trở lại cây làm việc chính $GIT_DIR(ví dụ /path/main/.git).

Các cài đặt này được thực hiện trong một .gittệp nằm ở thư mục trên cùng của cây làm việc được liên kết.

Khi bạn hoàn thành với một cây làm việc được liên kết, bạn có thể chỉ cần xóa nó.
Các tệp quản trị của cây làm việc trong kho lưu trữ cuối cùng sẽ tự động bị xóa (xem gc.pruneworktreesexpiretrong git config) hoặc bạn có thể chạy git worktree prunetrong cây chính hoặc bất kỳ cây làm việc được liên kết nào để dọn sạch mọi tệp quản trị cũ.

Cảnh báo: vẫn còn một phần git worktree"BUG" để nhận biết.

Sự hỗ trợ cho các mô hình con là không đầy đủ .
KHÔNG nên thực hiện nhiều kiểm tra của một siêu dự án.

Lưu ý: với git 2.7rc1 (tháng 11 năm 2015), bạn có thể liệt kê bảng công việc của mình.
Xem cam kết bb9c03b , cam kết 92718b7 , cam 5.193.490 , cam kết 1ceb7f9 , cam kết 1ceb7f9 , cam 5.193.490 , cam kết 1ceb7f9 , cam kết 1ceb7f9 (ngày 08 Tháng 10 2015), cam kết 92718b7 , cam 5.193.490 , cam kết 1ceb7f9 , cam kết 1ceb7f9 (ngày 08 Tháng 10 2015), cam kết 5.193.490 , cam kết 1ceb7f9 (ngày 08 tháng 10 năm 2015), cam kết 1ceb7f9 (ngày 08 tháng 10 năm 2015) và cam kết ac6c561(02 tháng 10 năm 2015) bởi Michael Rappazzo ( rappazzo) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết a46dcfb , ngày 26 tháng 10 năm 2015)}

worktree: thêm listlệnh ''

' git worktree list' lặp đi lặp lại thông qua danh sách bàn làm việc và đưa ra chi tiết của bàn làm việc bao gồm đường dẫn đến bàn làm việc, bản sửa đổi và chi nhánh hiện đang được kiểm tra và nếu cây công việc trống.

$ git worktree list
/path/to/bare-source            (bare)
/path/to/linked-worktree        abcd1234 [master]
/path/to/other-linked-worktree  1234abc  (detached HEAD)

Ngoài ra còn có tùy chọn định dạng sứ có sẵn.

Các định dạng sứ có một dòng trên mỗi thuộc tính.

• Các thuộc tính được liệt kê với một nhãn và giá trị được phân tách bằng một khoảng trắng.
• Các thuộc tính Boolean (như 'trần' và 'tách rời') chỉ được liệt kê dưới dạng nhãn và chỉ xuất hiện khi và chỉ khi giá trị là đúng.
• Một dòng trống cho biết sự kết thúc của một bàn làm việc

Ví dụ:

$ git worktree list --porcelain

worktree /path/to/bare-source
bare

worktree /path/to/linked-worktree
HEAD abcd1234abcd1234abcd1234abcd1234abcd1234
branch refs/heads/master

worktree /path/to/other-linked-worktree
HEAD 1234abc1234abc1234abc1234abc1234abc1234a
detached

Lưu ý: nếu bạn di chuyển thư mục worktree, bạn cần cập nhật thủ cônggitdir tệp.

Xem cam kết 618244e (ngày 22 tháng 1 năm 2016) và cam kết d4cddd6 (ngày 18 tháng 1 năm 2016) của Nguyễn Thái Ngọc Duy ( pclouds) .
Được giúp đỡ: Eric Sunshine ( sunshineco) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết d0a1cbc , ngày 10 tháng 2 năm 2016)}

Tài liệu mới trong git 2.8 (tháng 3 năm 2016) sẽ bao gồm:

Nếu bạn di chuyển cây làm việc được liên kết, bạn cần cập nhật gitdirtệp '' trong thư mục của mục nhập.
Ví dụ: nếu một cây làm việc được liên kết được chuyển đến /newpath/test-nextvà .gittệp của nó trỏ tới /path/main/.git/worktrees/test-next, thì hãy cập nhật /path/main/.git/worktrees/test-next/gitdirđể tham chiếu /newpath/test-nextthay thế.

Hãy cẩn thận khi xóa một nhánh: trước git 2.9 (tháng 6 năm 2016), bạn có thể xóa một nhánh đang sử dụng trong một cây làm việc khác .

Khi git worktreetính năng "" được sử dụng ", git branch -d" cho phép xóa một nhánh được kiểm tra trong một bàn làm việc khác.

Xem cam kết f292244 (29 tháng 3 năm 2016) của Kazuki Yamaguchi ( rhenium) .
Được giúp đỡ: Eric Sunshine ( sunshineco) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 4fca4e3 , ngày 13 tháng 4 năm 2016)}

branch -d: từ chối xóa một chi nhánh hiện đang được kiểm tra

Khi một nhánh được kiểm tra bởi cây làm việc hiện tại, việc xóa nhánh bị cấm.
Tuy nhiên, khi chi nhánh chỉ được kiểm tra bởi các cây làm việc khác, xóa thành công không chính xác.
Sử dụng find_shared_symref()để kiểm tra xem nhánh đang được sử dụng, không chỉ so sánh với ĐẦU của cây làm việc hiện tại.

Tương tự, trước git 2.9 (tháng 6 năm 2016), việc đổi tên một chi nhánh đã được kiểm tra trong một worktree khác đã không điều chỉnh ĐẦU tượng trưng trong các worktree khác đã nói.

Xem cam kết 18eb3a9 (08 tháng 4 năm 2016) và cam kết 70999e9 , cam kết 2233066 (27 tháng 3 năm 2016) của Kazuki Yamaguchi ( rhenium) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 741a694 , ngày 18 tháng 4 năm 2016)}

branch -m: cập nhật tất cả các tiêu đề trên mỗi công việc

Khi đổi tên một nhánh, hiện tại chỉ có đầu của cây làm việc hiện tại được cập nhật, nhưng nó phải cập nhật các đầu của tất cả các cây làm việc chỉ vào nhánh cũ.

Đây là hành vi hiện tại, / path / to / wt's HEAD không được cập nhật:

  % git worktree list
  /path/to     2c3c5f2 [master]
  /path/to/wt  2c3c5f2 [oldname]
  % git branch -m master master2
  % git worktree list
  /path/to     2c3c5f2 [master2]
  /path/to/wt  2c3c5f2 [oldname]
  % git branch -m oldname newname
  % git worktree list
  /path/to     2c3c5f2 [master2]
  /path/to/wt  0000000 [oldname]

Bản vá này khắc phục vấn đề này bằng cách cập nhật tất cả các tiêu đề công việc có liên quan khi đổi tên chi nhánh.

Cơ chế khóa được hỗ trợ chính thức với git 2.10 (quý 3 năm 2016)

Xem cam kết 080739b , cam kết 6d30862 , cam kết 58142c0 , cam kết 346ef53 , cam kết 346ef53 , cam kết 58142c0 , cam kết 346ef53 , cam kết 346ef53 (13 tháng 6 năm 2016), và cam kết 984ad9e , cam 6.835.314 (ngày 03 tháng 6 năm 2016) do Nguyễn Thái Ngọc Duy ( pclouds) .
Gợi ý: Eric Sunshine ( sunshineco) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 2c608e0 , ngày 28 tháng 7 năm 2016)}

git worktree lock [--reason <string>] <worktree>
git worktree unlock <worktree>

Nếu cây làm việc được liên kết được lưu trữ trên thiết bị di động hoặc chia sẻ mạng không phải lúc nào cũng được gắn kết, bạn có thể ngăn các tệp quản trị của nó bị cắt xén bằng cách ban hành git worktree locklệnh, tùy chọn chỉ định --reasonđể giải thích tại sao cây làm việc bị khóa.

<worktree>: Nếu các thành phần đường dẫn cuối cùng trong đường dẫn của cây làm việc là duy nhất trong số các cây làm việc, thì nó có thể được sử dụng để xác định các bàn làm việc.
Ví dụ: nếu bạn chỉ phải làm việc với cây tại " /abc/def/ghi" và " /abc/def/ggg", thì " ghi" hoặc " def/ghi" là đủ để trỏ đến cây làm việc trước đây.

Git 2.13 (quý 2 năm 2017) thêm locktùy chọn trong cam kết 507e6e9 (ngày 12 tháng 4 năm 2017) của Nguyễn Thái Ngọc Duy ( pclouds) .
Gợi ý: David Taylor ( dt) .
Giúp đỡ: Jeff King ( peff) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết e311597 , ngày 26 tháng 4 năm 2017)}

Cho phép khóa một bàn làm việc ngay sau khi nó được tạo.
Điều này giúp ngăn chặn cuộc đua giữa " git worktree add; git worktree lock" và " git worktree prune".

Như vậy git worktree add' --lock là tương đương với git worktree locksau git worktree add, nhưng không có điều kiện chủng tộc.

Git 2.17+ (quý 2 năm 2018) thêm git worktree move/ git worktree remove: xem câu trả lời này .

Git 2.19 (Q3 2018) thêm --quiettùy chọn "" để làm cho " git worktree add" ít dài dòng hơn.

Xem cam kết 371979c (15 tháng 8 năm 2018) của Elia Pinto ( devzero2000) .
Được giúp đỡ: Martin gren, Duy Nguyễn ( pclouds) và Eric Sunshine ( sunshineco) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết a988ce9 , ngày 27 tháng 8 năm 2018)}

worktree: thêm --quiettùy chọn

Thêm --quiettùy chọn '' vào git worktree, như đối với các gitlệnh khác .
' add' là lệnh duy nhất bị ảnh hưởng bởi nó vì tất cả các lệnh khác, ngoại trừ ' list', hiện đang im lặng theo mặc định.

Lưu ý rằng " git worktree add" được sử dụng để thực hiện "tìm tên có sẵn bằng stat và sau đó mkdir", dễ bị đua.
Điều này đã được khắc phục với Git 2.22 (quý 2 năm 2019) bằng cách sử dụng mkdirvà phản ứng EEXISTtrong một vòng lặp.

Xem cam kết 7af01f2 (20 tháng 2 năm 2019) của Michal suchanek ( hramrach) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 20fe798 , ngày 09 tháng 4 năm 2019)}

worktree: sửa worktree addcuộc đua

Git chạy một vòng lặp stat để tìm một tên công việc có sẵn và sau đó thực hiện mkdirtrên tên tìm thấy.
Biến nó thành mkdirvòng lặp để tránh một lệnh gọi khác của worktree thêm tìm cùng tên miễn phí và tạo thư mục trước.

Git 2.22 (Q2 2019) sửa lỗi logic để biết liệu kho lưu trữ Git có cây làm việc bảo vệ " git branch -D" khỏi việc xóa nhánh hiện đang được kiểm tra do nhầm lẫn hay không.
Việc triển khai logic này đã bị phá vỡ đối với các kho lưu trữ có tên khác thường, điều không may là tiêu chuẩn cho các mô hình con ngày nay.

Xem cam kết f3534c9 (19 tháng 4 năm 2019) của Jonathan Tan ( jhowtan) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết ec2642a , ngày 08 tháng 5 năm 2019)}

Yêu cầu kéo mã 178 Thông tin chi tiết

worktree: cập nhật is_bareheuristic

Khi " git branch -D <name>" được chạy, Git thường kiểm tra trước nếu nhánh đó hiện đang được kiểm tra.
Nhưng kiểm tra này không được thực hiện nếu thư mục Git của kho lưu trữ đó không ở " <repo>/.git", đó là trường hợp nếu kho lưu trữ đó là một mô hình con có thư mục Git được lưu trữ dưới dạng " super/.git/modules/<repo>", chẳng hạn.
Điều này dẫn đến việc chi nhánh bị xóa ngay cả khi nó được kiểm tra.

Điều này là do get_main_worktree()trong worktree.ccác tập hợp is_baretrên một worktree chỉ sử dụng heuristic rằng một repo trống nếu đường dẫn của worktree không kết thúc bằng " /.git", và không phải là trần.
Đây is_baremã đã được giới thiệu trong 92718b7 ( " worktree: add chi tiết để các struct worktree", 2015/10/08, Git v2.7.0-RC0), sau một pre-core.bareheuristic.

Bản vá này thực hiện 2 điều:

• Thay vào đó, hãy dạy get_main_worktree()cách sử dụng is_bare_repository(), được giới thiệu trong 7d1864c ("Giới thiệu biến cấu hình is_bare_Vposeective () và core.bare", 2007-01-07, Git v1.5.0-rc1) và cập nhật trong e90fdc3 ("Dọn dẹp xử lý cây công việc", 2007 -08-01, Git v1.5.3-RC4).
  Điều này giải quyết git branch -D <name>vấn đề "" được mô tả ở trên.

Tuy nhiên ... Nếu một kho lưu trữ có core.bare=1nhưng gitlệnh "" đang được chạy từ một trong các worktrees thứ cấp của nó, is_bare_repository()trả về false (điều này là tốt, vì có sẵn một worktree).

Và, coi công việc chính là không trần khi nó trần gây ra các vấn đề:

Ví dụ, thất bại trong việc xóa một nhánh từ một bàn làm việc phụ được đề cập bởi TRỤ của người làm việc chính, ngay cả khi bàn làm việc chính đó trống.

Để tránh điều đó, cũng kiểm tra core.barekhi cài đặt is_bare.
Nếu core.bare=1, tin tưởng nó, và nếu không, sử dụng is_bare_repository().

Việc gitphân phối đi kèm với một kịch bản đóng góp được gọi là git-new-workdir. Bạn sẽ sử dụng nó như sau:

git-new-workdir project-dir new-workdir branch

trong đó project-dir là tên của thư mục chứa .gitkho lưu trữ của bạn . Tập lệnh này tạo một .gitthư mục khác có nhiều liên kết tượng trưng đến thư mục gốc ngoại trừ các tệp không thể chia sẻ (như nhánh hiện tại), cho phép bạn làm việc ở hai nhánh khác nhau.

Nghe có vẻ hơi mong manh, nhưng đó là một lựa chọn.

Tôi bắt gặp câu hỏi này với hy vọng giải pháp mà tôi không tìm thấy ở đây. Vì vậy, bây giờ tôi đã tìm thấy những gì tôi cần, tôi quyết định đăng nó ở đây cho người khác.

Hãy cẩn thận: Đây có lẽ không phải là một giải pháp tốt nếu bạn cần chỉnh sửa đồng thời nhiều nhánh, như trạng thái OP. Đó là để có nhiều chi nhánh được kiểm tra đồng thời mà bạn không có ý định chỉnh sửa. (Nhiều thư mục làm việc được hỗ trợ bởi một thư mục .git.)

Có một vài điều tôi học được từ lần đầu tiên đến câu hỏi này:

1. Thật là một " kho lưu trữ trần ". Nó thực chất là nội dung của .gitthư mục, mà không nằm trong một cây làm việc.

2. Thực tế là bạn có thể chỉ định vị trí của repo bạn đang sử dụng (vị trí của .gitthư mục của bạn ) trên dòng lệnh với gittùy chọn--git-dir=

3. Thực tế là bạn có thể chỉ định vị trí của bản sao làm việc của bạn với --work-tree=

4. Thật là một "gương repo".

Điều này cuối cùng là một sự phân biệt khá quan trọng. Tôi thực sự không muốn làm việc trên repo, tôi chỉ cần có các bản sao của các chi nhánh và / hoặc thẻ khác nhau được kiểm tra đồng thời. Trong thực tế, tôi cần đảm bảo rằng các chi nhánh không kết thúc khác với các chi nhánh từ xa của tôi. Vì vậy, một tấm gương là hoàn hảo cho tôi.

Vì vậy, đối với trường hợp sử dụng của tôi , tôi đã nhận được những gì tôi cần bằng cách làm:

git clone --mirror <remoteurl> <localgitdir> # Where localgitdir doesn't exist yet
mkdir firstcopy
mkdir secondcopy
git --git-dir=<localgitdir> --work-tree=firstcopy checkout -f branch1
git --git-dir=<localgitdir> --work-tree=secondcopy checkout -f branch2

Nhắc nhở lớn về điều này là không có một ĐẦU riêng cho hai bản. Vì vậy, sau những điều trên, việc chạy git --git-dir=<localgitdir> --work-tree=firstcopy statussẽ hiển thị tất cả sự khác biệt từ nhánh2 đến nhánh1 là những thay đổi không được cam kết - bởi vì CHÍNH đang chỉ vào nhánh2. (Đó là lý do tại sao tôi sử dụng -ftùy chọn để checkout, vì tôi không thực sự có kế hoạch để thực hiện bất kỳ thay đổi cục bộ ở tất cả. Tôi có thể kiểm bất kỳ thẻ hoặc chi nhánh đối với bất kỳ công việc cây, chừng nào tôi còn sử dụng các -ftùy chọn.)

Đối với trường hợp sử dụng của tôi có nhiều thanh toán cùng tồn tại trên cùng một máy tính mà không cần chỉnh sửa chúng , điều này hoạt động hoàn hảo. Tôi không biết có cách nào để có nhiều ĐẦU cho nhiều cây làm việc mà không có tập lệnh như được nêu trong các câu trả lời khác không, nhưng tôi hy vọng điều này sẽ hữu ích cho người khác.

Giải pháp duy nhất tôi có thể nghĩ đến là sao chép hai thư mục và thêm chúng làm kho lưu trữ từ xa của nhau. Sau đó, bạn có thể tiếp tục kéo các thứ từ cái đã thay đổi sang cái khác mà không thực sự đẩy bất cứ thứ gì vào kho lưu trữ từ xa.

Tôi giả sử bạn muốn có hai thư mục hoạt động chứ không phải hai bản sao của điều khiển từ xa vì bạn không muốn đẩy một số nhánh vào điều khiển từ xa. Nếu không, hai bản sao của điều khiển từ xa của bạn sẽ hoạt động tốt - bạn chỉ cần thực hiện một số lần đẩy và kéo để giữ cho cả ba đồng bộ.