dvcs - có phải là bản sao nhái vào nhánh nhánh của quy trình phổ biến không?

Gần đây tôi đã thảo luận về dvcs với đồng nghiệp, bởi vì văn phòng của chúng tôi đang bắt đầu xem xét chuyển đổi từ TFS (chúng tôi là một cửa hàng MS). Trong quá trình đó, tôi đã rất bối rối vì anh ta nói rằng mặc dù anh ta sử dụng Mercurial, anh ta đã không nghe thấy lệnh "chi nhánh" hay "thanh toán", và những thuật ngữ này không quen thuộc với anh ta. Sau khi tự hỏi làm thế nào có thể anh ta không biết về họ và giải thích cách các nhánh dvcs hoạt động "tại chỗ" trên các tệp cục bộ của bạn, anh ta đã khá bối rối.

Anh ấy giải thích rằng, tương tự như cách TFS hoạt động, khi anh ấy muốn tạo ra một "nhánh", anh ấy làm điều đó bằng cách nhân bản, vì vậy anh ấy có toàn bộ bản sao repo của mình. Điều này có vẻ thực sự xa lạ đối với tôi, nhưng lợi ích mà tôi phải thừa nhận là bạn có thể xem hoặc làm việc trên hai nhánh cùng một lúc vì các tệp riêng biệt.

Khi tìm kiếm trang web này để xem liệu điều này đã được hỏi trước khi tôi thấy một nhận xét rằng nhiều tài nguyên trực tuyến quảng bá phương pháp "nhân bản chi nhánh" này, đến sự mất tinh thần của người đăng bài. Đây có thực sự phổ biến trong cộng đồng dvcs? Và một số ưu và nhược điểm của việc đi theo cách này là gì? Tôi sẽ không bao giờ làm điều đó vì tôi không cần phải xem nhiều chi nhánh cùng một lúc, chuyển đổi rất nhanh và tôi không cần tất cả các bản sao lấp đầy đĩa của mình.

Ngoài lợi thế / bất lợi chung là có thể nhìn thấy cả hai nhánh, tôi nghĩ còn có một lợi thế đặc biệt của Mercurial để làm điều đó.

Nếu bạn sao chép để tạo một nhánh, bạn có thể xóa bản sao sau nếu bạn không muốn giữ các thay đổi của mình. Nếu bạn quyết định hợp nhất chúng, thì thực tế là bạn đã quyết định tách các thay đổi của mình ra theo cách này sẽ không hiển thị với bất kỳ ai khác.

Ngược lại, nếu bạn sử dụng hg branchđể tạo một nhánh có tên mới, tên nhánh được ghi lại trong lịch sử khi bạn cam kết, hiển thị cho mọi người khác và phải khá độc đáo để tránh sự nhầm lẫn tiềm ẩn sau này. Điều này có thể không phù hợp nếu chi nhánh của bạn phát triển một số tính năng thử nghiệm hoặc cho một thay đổi có thể là nhỏ.

Nếu bạn sử dụng các nhánh được đặt tên để duy trì các phiên bản đã phát hành của phần mềm của mình và cũng sử dụng chúng để phát triển các tính năng hoặc lỗi ngắn hạn, bạn sẽ dễ bị nhầm lẫn vì không có cách nào (ngoài các quy ước đặt tên) để tách hai loại nhánh này.

http://mercurial.selenic.com/wiki/St ChuẩnBranching giải thích điều này chi tiết hơn. Điều đáng nói là kể từ Mercurial 1.8, có thể tạo bookmark ( hg bookmark) - tên dùng một lần cho một nhánh tồn tại ngắn. Dấu trang có thể được đẩy, kéo, di chuyển và xóa.

Mỗi khi bạn thực hiện một cam kết trong DVCS, về mặt kỹ thuật bạn đang tạo một nhánh trong lịch sử, mỗi khi bạn đẩy nó trở lại kho lưu trữ may mắn mà bạn tích hợp lại, đây là phần thú vị:

• Nếu không ai thực hiện thay đổi trong cam kết của bạn, nó sẽ không giống như một nhánh trong DAG (biểu đồ chu kỳ theo hướng)
• Nếu người khác thực hiện thay đổi trong cam kết của bạn, nó sẽ trông giống như một nhánh trong DAG, chỉ chưa được đặt tên

Hãy nhớ nút "fork" trong Bitbucket / github?, Forking có thể được coi là đồng nghĩa của việc phân nhánh và nút "fork" làm gì chỉ là một bản sao của kho lưu trữ đó vào tài khoản của bạn.

Ưu điểm duy nhất của "nhân bản vào chi nhánh" là có thể làm việc đồng thời tại hai điểm trong lịch sử và trớ trêu thay cho đồng nghiệp của bạn, đó là một quy trình làm việc chung để làm việc trên các chi nhánh khác nhau cùng một lúc (mà không phải quay đi quay lại ).

Nói với đồng nghiệp của bạn để học cách phân nhánh , rất dễ dàng, ở đây, có một hướng dẫn:

D:\>mkdir lol

D:\>cd lol

D:\lol>hg init

D:\lol>hg branch
default

D:\lol>touch lol

D:\lol>hg add lol

D:\lol>hg commit -m "lol"

D:\lol>hg branch lol
marked working directory as branch lol
(branches are permanent and global, did you want a bookmark?)

D:\lol>hg branches
default                        0:35d562fafaf2

D:\lol>echo "lol" > lol

D:\lol>hg commit -m "New lol branch"

D:\lol>hg branches
lol                            1:9384f923e78d
default                        0:35d562fafaf2 (inactive)

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg update lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg merge lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

D:\lol>hg commit -m "lol merge"

D:\lol>hg branch
default

D:\lol>hg update lol
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

"Nhân bản vào chi nhánh" có ý nghĩa khi bạn làm việc ở các chi nhánh khác nhau cùng một lúc hoặc khi bạn muốn thử một thử nghiệm mà không tạo chi nhánh cố định trong lịch sử và vẫn có thể tích hợp nó trở lại chi nhánh đã có .

Cá nhân tôi không thích cách làm này và thích làm chi nhánh và đóng chúng nếu cần thiết. Đây là cách bạn làm điều đó:

D:\lol>hg branches
default                        2:46420aca1612
lol                            1:9384f923e78d (inactive)

D:\lol>hg branch
lol

D:\lol>hg commit --close-branch -m "Obai, glorious lol branch"

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branch
lol

D:\lol>hg update default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branches --closed
default                        2:46420aca1612
lol                            3:4b79c577e029 (closed)

Hy vọng điều này sẽ xóa tan nghi ngờ phân nhánh DVCS của bạn, ở đây các chi nhánh không còn đáng sợ nữa.

Cá nhân tôi sẽ không lo lắng về việc lấp đầy mã của mình ... đầu tiên, đó chỉ là mã và thứ hai, bạn sẽ không giữ tất cả các bản sao của mình mãi mãi.

Phương pháp này được quảng bá trong rất nhiều tài nguyên trực tuyến, đặc biệt là đối với Hg. Tôi chưa bao giờ thấy nó được sử dụng trong sản xuất, trong môi trường CI, việc có các nhánh tính năng tồn tại ngắn hơn nhiều so với các bản sao lưu trữ bổ sung. Tôi không thấy lợi thế của việc này, nếu bất cứ điều gì nó sẽ làm cho lịch sử của bạn trở nên rắc rối hơn, không ít hơn, và nó cũng không mang lại cho bạn bất cứ điều gì. Nếu bạn muốn xem mã mới của mình cạnh mã cũ, bạn có thể sử dụng công cụ diff / merge để xem hai cam kết cạnh nhau, với lợi thế bổ sung là bạn sẽ thấy các thay đổi của mình được tô sáng.