Tôi cố gắng hiểu những lợi ích của hệ thống kiểm soát phiên bản phân tán (DVCS).

Tôi thấy Subversion Re-giáo dục và bài viết này của Martin Fowler rất hữu ích.

Mercurial và những người khác DVCS thúc đẩy một cách làm việc mới về mã với các thay đổi và cam kết cục bộ. Nó ngăn chặn sự hợp nhất địa ngục và các vấn đề hợp tác khác

Chúng tôi không bị ảnh hưởng bởi điều này vì tôi thực hành tích hợp liên tục và làm việc một mình trong một chi nhánh tư nhân không phải là một lựa chọn, trừ khi chúng tôi đang thử nghiệm. Chúng tôi sử dụng một nhánh cho mọi phiên bản chính, trong đó chúng tôi sửa các lỗi được hợp nhất từ ​​thân cây.

Mercurial cho phép bạn có trung úy

Tôi hiểu điều này có thể hữu ích cho các dự án rất lớn như Linux, nhưng tôi không thấy giá trị trong các nhóm nhỏ và có tính hợp tác cao (5 đến 7 người).

Mercurial nhanh hơn, chiếm ít không gian đĩa hơn và sao chép toàn bộ cục bộ cho phép các hoạt động nhật ký & khác biệt nhanh hơn.

Tôi cũng không quan tâm đến điều này, vì tôi không nhận thấy vấn đề về tốc độ hoặc không gian với SVN ngay cả với các dự án rất lớn mà tôi đang thực hiện.

Tôi đang tìm kiếm kinh nghiệm cá nhân và / hoặc ý kiến ​​của bạn từ các chuyên viên máy tính SVN trước đây. Đặc biệt là liên quan đến việc changesets khái niệm và tổng thể hiệu suất tăng bạn đo.

CẬP NHẬT (ngày 12 tháng 1) : Bây giờ tôi tin chắc rằng nó đáng để thử.

CẬP NHẬT (ngày 12 tháng 6) : Tôi đã hôn Mercurial và tôi thích nó. Hương vị của anh đào địa phương cam kết. Tôi hôn Mercurial chỉ để thử nó. Tôi hy vọng Máy chủ SVN của tôi không quan tâm đến nó. Nó cảm thấy rất sai. Nó cảm thấy rất đúng. Đừng có nghĩa là tôi đang yêu tối nay .

CẬP NHẬT CUỐI CÙNG (ngày 29 tháng 7) : Tôi có đặc quyền xem xét cuốn sách tiếp theo của Eric Sink có tên là Kiểm soát phiên bản theo ví dụ . Anh nói xong để thuyết phục tôi. Tôi sẽ đi Mercurial.

Lưu ý: Xem "EDIT" để biết câu trả lời cho câu hỏi hiện tại

Trước hết, hãy đọc Subversion Re-giáo dục của Joel Spolsky. Tôi nghĩ rằng hầu hết các câu hỏi của bạn sẽ được trả lời ở đó.

Một đề xuất khác, cuộc nói chuyện của Linus Torvalds trên Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Câu hỏi khác này cũng có thể trả lời hầu hết các câu hỏi của bạn, và nó là một câu hỏi khá thú vị.

BTW, một điều tôi thấy khá buồn cười: ngay cả Brian Fitzpatrick & Ben Collins-Sussman, hai trong số những người tạo ra sự lật đổ ban đầu đã nói trong một cuộc nói chuyện trên google "xin lỗi về điều đó" đề cập đến việc lật đổ không thua kém (và nói chung là DVCS).

Bây giờ, IMO và nói chung, tính năng động của nhóm phát triển tự nhiên hơn với bất kỳ DVCS nào và một lợi ích nổi bật là bạn có thể cam kết ngoại tuyến vì nó bao hàm những điều sau:

• Bạn không phụ thuộc vào máy chủ và kết nối, nghĩa là thời gian nhanh hơn.
• Không trở thành nô lệ cho những nơi mà bạn có thể truy cập internet (hoặc VPN) chỉ để có thể cam kết.
• Mọi người đều có một bản sao lưu của tất cả mọi thứ (tập tin, lịch sử), không chỉ máy chủ. Có nghĩa là bất cứ ai cũng có thể trở thành máy chủ .
• Bạn có thể cam kết bắt buộc nếu bạn cần mà không làm hỏng mã của người khác . Cam kết là địa phương. Bạn không giẫm lên các ngón chân của nhau trong khi cam kết. Bạn không phá vỡ các bản dựng hoặc môi trường của người khác chỉ bằng cách cam kết.
• Những người không có "quyền truy cập cam kết" có thể cam kết (vì cam kết trong DVCS không ngụ ý mã tải lên), hạ thấp rào cản cho các đóng góp, bạn có thể quyết định lấy các thay đổi của họ hoặc không phải là nhà tích hợp.
• Nó có thể củng cố giao tiếp tự nhiên vì DVCS làm cho điều này trở nên thiết yếu ... trong việc lật đổ những gì bạn có thay vào đó là các cuộc đua cam kết, điều này buộc phải giao tiếp, nhưng bằng cách cản trở công việc của bạn.
• Những người đóng góp có thể lập nhóm và xử lý việc hợp nhất của riêng họ, nghĩa là cuối cùng sẽ làm việc ít hơn cho các nhà tích hợp.
• Người đóng góp có thể có chi nhánh riêng mà không ảnh hưởng đến người khác (nhưng có thể chia sẻ chúng nếu cần thiết).

Về điểm của bạn:

• Sáp nhập địa ngục không tồn tại trong DVCSland; không cần phải xử lý. Xem điểm tiếp theo .
• Trong DVCS, mọi người đều đại diện cho một "nhánh", nghĩa là có sự hợp nhất mỗi khi thay đổi được kéo. Chi nhánh được đặt tên là một điều khác.
• Bạn có thể tiếp tục sử dụng tích hợp liên tục nếu bạn muốn. IMHO không cần thiết mặc dù, tại sao thêm sự phức tạp?, Chỉ cần giữ thử nghiệm của bạn như là một phần của văn hóa / chính sách của bạn.
• Mercurial nhanh hơn trong một số thứ, git nhanh hơn trong những thứ khác. Không thực sự lên đến DVCS nói chung, nhưng với việc triển khai cụ thể của họ AFAIK.
• Mọi người sẽ luôn có dự án đầy đủ, không chỉ bạn. Điều phân tán phải làm với việc bạn có thể cam kết / cập nhật cục bộ, chia sẻ / lấy từ bên ngoài máy tính của bạn được gọi là đẩy / kéo.
• Một lần nữa, đọc Subversion Re-giáo dục. Các DVCS dễ dàng và tự nhiên hơn, nhưng chúng khác nhau, đừng cố nghĩ rằng cvs / svn === cơ sở của tất cả các phiên bản.

Tôi đã đóng góp một số tài liệu cho dự án Joomla để giúp rao giảng về việc di chuyển sang DVCS và ở đây tôi đã thực hiện một số sơ đồ để minh họa tập trung so với phân tán.

Tập trung

Phân phối trong thực tiễn chung

Phân phối đầy đủ nhất

Bạn thấy trong sơ đồ vẫn còn một "kho lưu trữ tập trung" và đây là một trong những đối số ưa thích của người hâm mộ phiên bản tập trung: "bạn vẫn đang được tập trung", và không, vì bạn không phải là kho lưu trữ "tập trung" tất cả đều đồng ý (ví dụ như một repo github chính thức), nhưng điều này có thể thay đổi bất cứ lúc nào bạn cần.

Bây giờ, đây là quy trình công việc điển hình cho các dự án nguồn mở (ví dụ: một dự án có sự cộng tác lớn) sử dụng DVCS:

Bitbucket.org là một phần của github tương đương với đồng bóng, biết rằng họ có kho riêng tư không giới hạn với không gian không giới hạn, nếu nhóm của bạn nhỏ hơn năm bạn có thể sử dụng miễn phí.

Cách tốt nhất bạn có thể thuyết phục bản thân khi sử dụng DVCS là dùng thử DVCS, mọi nhà phát triển DVCS có kinh nghiệm đã sử dụng svn / cvs sẽ cho bạn biết điều đó đáng giá và họ không biết làm thế nào họ sống sót sau thời gian không có nó.

EDIT : Để trả lời chỉnh sửa thứ hai của bạn, tôi chỉ có thể nhắc lại rằng với một DVCS bạn có một quy trình làm việc khác, tôi khuyên bạn không nên tìm lý do không thử vì những cách thực hành tốt nhất , cảm giác như khi mọi người tranh luận rằng OOP không cần thiết bởi vì họ có thể có được xung quanh các mẫu thiết kế phức tạp với những gì họ luôn làm với mô hình XYZ; bạn có thể có lợi

Hãy thử nó, bạn sẽ thấy làm việc trong "một chi nhánh tư nhân" thực sự là một lựa chọn tốt hơn. Một lý do tôi có thể nói về lý do tại sao điều cuối cùng là đúng là vì bạn mất đi nỗi sợ phải cam kết , cho phép bạn cam kết bất cứ lúc nào bạn thấy phù hợp và làm việc một cách tự nhiên hơn.

Về "sát nhập địa ngục", bạn nói "trừ khi chúng tôi đang thử nghiệm", tôi nói "ngay cả khi bạn đang thử nghiệm + bảo trì + làm việc trong phiên bản v2.0 được tân trang cùng một lúc ". Như tôi đã nói trước đó, sáp nhập địa ngục không tồn tại, bởi vì:

• Mỗi khi bạn cam kết bạn tạo ra một nhánh không tên và mỗi khi các thay đổi của bạn gặp thay đổi của người khác, sẽ xảy ra sự hợp nhất tự nhiên.
• Vì các DVCS thu thập nhiều siêu dữ liệu hơn cho mỗi lần xác nhận, ít xảy ra xung đột hơn trong quá trình hợp nhất ... vì vậy bạn thậm chí có thể gọi đó là "hợp nhất thông minh".
• Khi bạn va vào xung đột hợp nhất, đây là những gì bạn có thể sử dụng:

Ngoài ra, quy mô dự án không thành vấn đề, khi tôi chuyển từ lật đổ, tôi thực sự đã thấy được lợi ích khi làm việc một mình, mọi thứ đều cảm thấy đúng. Các changesets (không hẳn là một phiên bản, nhưng một tập hợp cụ thể của sự thay đổi cho các tập tin cụ thể mà bạn bao gồm một cam kết, bị cô lập từ trạng thái của codebase) cho phép bạn hình dung chính xác những gì bạn có nghĩa là bằng cách làm những gì bạn đã làm cho một nhóm cụ thể của tác phẩm, không phải toàn bộ cơ sở mã.

Về cách thức thay đổi hoạt động và tăng hiệu suất. Tôi sẽ cố gắng minh họa nó bằng một ví dụ tôi muốn đưa ra: chuyển đổi dự án mootools từ svn được minh họa trong biểu đồ mạng github của họ .

Trước

Sau

Những gì bạn đang thấy là các nhà phát triển có thể tập trung vào công việc của chính họ trong khi cam kết, mà không sợ phá vỡ mã của người khác, họ lo lắng về việc phá mã của người khác sau khi đẩy / kéo (DVCSs: trước tiên cam kết, sau đó đẩy / kéo, sau đó cập nhật ) nhưng vì việc hợp nhất ở đây thông minh hơn, họ thường không bao giờ thực hiện ... ngay cả khi có xung đột hợp nhất (rất hiếm), bạn chỉ mất 5 phút hoặc ít hơn để khắc phục.

Lời khuyên của tôi cho bạn là hãy tìm một người biết cách sử dụng đồng bóng / git và nói với anh ấy / cô ấy để giải thích điều đó với bạn. Bằng cách dành khoảng nửa giờ với một số người bạn trong dòng lệnh trong khi sử dụng đồng bóng với máy tính để bàn và tài khoản bitbucket của chúng tôi chỉ cho họ cách hợp nhất, thậm chí tạo ra xung đột cho họ để xem cách khắc phục thời gian vô lý, tôi đã có thể chỉ ra chúng là sức mạnh thực sự của một DVCS.

Cuối cùng, tôi khuyên bạn nên sử dụng mercurial + bitbucket thay vì git + github nếu bạn làm việc với folks windows. Mercurial cũng đơn giản hơn một chút, nhưng git mạnh mẽ hơn cho việc quản lý kho lưu trữ phức tạp hơn (ví dụ: git rebase ).

Một số bài đọc khuyến nghị bổ sung:

• Hệ thống kiểm soát sửa đổi phân tán: Git so với Mercurial so với SVN
• Git vs. Mercurial: Hãy thư giãn
• Kiểm soát phiên bản phân tán & Git [Phần 1] & Kiểm soát phiên bản phân tán & Git [Phần 2]
• Git / Mercurial vs Subversion: Chiến đấu!
• Đập bóng DVCS vs Subversion, vòng 3
• Tại sao tôi thích Mercurial hơn Git ( phần 1 , phần 2 )
• Đóng góp với Git: Giảm các ma sát của sự hợp tác Nguồn mở với Git VCS
• "Làm thế nào các DVCS làm việc cho bạn cho đến nay?" - đăng trên Joomla! Danh sách gửi thư Phát triển Khung yêu cầu phản hồi sau khi áp dụng thử nghiệm đồng bóng và git cho Joomla! Dự án nền tảng
• Phân nhánh DVCS (với Mercurial) - Giới thiệu chi tiết và định hướng ví dụ về phân nhánh trông như thế nào trong DVCS, đây có thể là tính năng quan trọng nhất trong các hệ thống này

Những gì bạn đang nói là một trong những điều khác mà nếu bạn chủ yếu ở một nhánh, thì bạn không cần kiểm soát phiên bản phân tán.

Điều đó là đúng, nhưng đó không phải là một hạn chế mạnh mẽ không cần thiết đối với cách làm việc của bạn và một hạn chế không phù hợp với nhiều địa điểm trong nhiều múi giờ? Máy chủ lật đổ trung tâm nên được đặt ở đâu và mọi người nên về nhà nếu máy chủ đó vì lý do nào đó bị hỏng?

DVCS là để lật đổ, Bittorrent là gì để ftp

(về mặt kỹ thuật, không hợp pháp). Có lẽ nếu bạn nghĩ rằng, bạn có thể hiểu tại sao nó là một bước nhảy vọt lớn như vậy?

Đối với tôi, việc chuyển sang git, ngay lập tức dẫn đến

• Sao lưu của chúng tôi dễ thực hiện hơn (chỉ cần "cập nhật từ xa" và bạn đã hoàn tất)
• Dễ dàng hơn để thực hiện các bước nhỏ khi làm việc mà không cần truy cập vào kho lưu trữ trung tâm. Bạn chỉ làm việc và đồng bộ hóa khi bạn quay lại mạng lưu trữ kho lưu trữ trung tâm.
• Hudson xây dựng nhanh hơn. Sử dụng git pull nhanh hơn nhiều so với cập nhật.

Vì vậy, hãy xem xét tại sao bittorrent tốt hơn ftp và xem xét lại vị trí của bạn :)

Lưu ý: Nó đã được đề cập rằng có những trường hợp sử dụng trong đó ftp nhanh hơn và bittorrent. Điều này đúng theo cách mà tệp sao lưu mà trình soạn thảo yêu thích của bạn duy trì sử dụng nhanh hơn hệ thống kiểm soát phiên bản.

Tính năng sát thủ của các hệ thống kiểm soát phiên bản phân tán là phần phân tán. Bạn không kiểm tra "bản sao làm việc" từ kho lưu trữ, bạn sao chép toàn bộ bản sao của kho lưu trữ. Điều này là rất lớn, vì nó cung cấp lợi ích mạnh mẽ:

• Bạn có thể tận hưởng những lợi ích của việc kiểm soát phiên bản, ngay cả khi bạn không có quyền truy cập internet như ... Điều này không may bị lạm dụng và sử dụng quá mức vì lý do DVCS là tuyệt vời --- nó không phải là một điểm bán hàng mạnh như nhiều chúng tôi thấy mình viết mã mà không truy cập internet thường xuyên khi trời bắt đầu mưa.

• Lý do thực sự có một kho lưu trữ cục bộ là kẻ giết người là bạn có toàn quyền kiểm soát lịch sử cam kết của mình trước khi nó được đẩy đến kho lưu trữ chính .

Đã từng sửa một lỗi và kết thúc với một cái gì đó như:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

Và như vậy. Lịch sử như thế là lộn xộn --- thực sự chỉ có một sửa chữa, nhưng bây giờ việc triển khai được lan truyền giữa nhiều cam kết có chứa các tạo phẩm không mong muốn như thêm và xóa các câu lệnh gỡ lỗi. Với một hệ thống như SVN, giải pháp thay thế là không cam kết (!!!) cho đến khi mọi thứ hoạt động để giữ cho lịch sử sạch sẽ. Ngay cả khi đó, những sai lầm đã xảy ra và Luật Murphy đang chờ đợi để tàn bạo bạn khi số lượng công việc đáng kể không được bảo vệ bởi kiểm soát phiên bản.

Có một bản sao cục bộ của kho lưu trữ mà bạn sở hữu , sửa lỗi này vì bạn có thể viết lại lịch sử bằng cách liên tục cuộn "sửa lỗi" và "oops" cam kết vào cam kết "sửa lỗi". Vào cuối ngày, một cam kết sạch sẽ được gửi đến kho lưu trữ chính trông như:

r321 Fixed annoying bug.

Đó là cách nó nên được.

Khả năng viết lại lịch sử thậm chí còn mạnh mẽ hơn khi kết hợp với mô hình phân nhánh. Một nhà phát triển có thể thực hiện công việc hoàn toàn biệt lập trong một chi nhánh và sau đó đến lúc đưa chi nhánh đó vào trong thân cây, bạn có tất cả các loại tùy chọn thú vị:

• Làm một hợp nhất vanilla đồng bằng . Mang tất cả mọi thứ trong mụn cóc và tất cả.

• Làm một cuộc nổi loạn . Cho phép bạn sắp xếp lịch sử chi nhánh, sắp xếp lại thứ tự các cam kết, ném các cam kết, tham gia các cam kết với nhau, viết lại các thông điệp cam kết --- thậm chí chỉnh sửa các cam kết hoặc thêm các cam kết mới! Một hệ thống kiểm soát phiên bản phân tán có hỗ trợ sâu cho việc xem xét mã.

Khi tôi biết được các kho lưu trữ địa phương cho phép tôi chỉnh sửa lịch sử của mình như thế nào vì sự tỉnh táo của các lập trình viên đồng nghiệp và bản thân tương lai của tôi, tôi đã treo lên SVN mãi mãi. Khách hàng Subversion của tôi bây giờ git svn.

Cho phép các nhà phát triển và quản lý thực hiện kiểm soát biên tập đối với kết quả lịch sử cam kết trong lịch sử dự án tốt hơn và có lịch sử sạch sẽ để làm việc thực sự giúp năng suất của tôi như một lập trình viên. Nếu tất cả những điều này nói về "viết lại lịch sử" làm bạn sợ, đừng lo lắng vì đó là những gì các kho lưu trữ trung tâm, công cộng hoặc chính dành cho. Lịch sử có thể (và nên!) Được viết lại cho đến khi ai đó mang nó vào một nhánh trong kho lưu trữ mà người khác đang kéo đến. Tại thời điểm đó, lịch sử nên được coi như thể được khắc trên một phiến đá.

câu trả lời của dukofgamings có lẽ là tốt nhất có thể, nhưng tôi muốn tiếp cận điều này từ một hướng khác.

Chúng ta hãy giả sử rằng những gì bạn nói là hoàn toàn đúng và bằng cách áp dụng các thực tiễn tốt, bạn có thể tránh được các sự cố mà DVCS được thiết kế để khắc phục. Điều này có nghĩa là một DVCS sẽ cung cấp cho bạn không có lợi thế? Mọi người bốc mùi theo các thực hành tốt nhất. Mọi người sẽ rối tung lên. Vậy tại sao bạn lại tránh phần mềm được thiết kế để khắc phục một loạt vấn đề, thay vào đó là dựa vào mọi người để làm điều gì đó mà bạn có thể dự đoán trước mà họ sẽ không làm?

Vâng, thật đau lòng khi bạn phải hợp nhất các cam kết lớn trong lật đổ. Nhưng đây cũng là một trải nghiệm học tập tuyệt vời, khiến bạn làm mọi thứ có thể để tránh xung đột sáp nhập. Nói cách khác, bạn học cách kiểm tra thường xuyên . Tích hợp sớm là một điều rất tốt cho bất kỳ dự án cùng vị trí. Miễn là mọi người đang làm điều đó, sử dụng lật đổ không phải là vấn đề lớn.

Git, chẳng hạn, được thiết kế cho công việc phân tán và khuyến khích mọi người làm việc trên các dự án của riêng họ và tạo ra các nhánh riêng cho việc hợp nhất (cuối cùng) sau này. Nó không được thiết kế đặc biệt để tích hợp liên tục trong một "nhóm nhỏ và hợp tác cao", đó là những gì OP đang yêu cầu. Nó là hoàn toàn ngược lại, hãy nghĩ về nó. Bạn sẽ không sử dụng các tính năng phân tán ưa thích của nó nếu tất cả những gì bạn đang làm đang ngồi trong cùng một phòng làm việc trên cùng một mã.

Vì vậy, đối với một nhóm sử dụng CI cùng vị trí, tôi thực sự không nghĩ nó quan trọng lắm nếu bạn sử dụng hệ thống phân tán hay không. Nó sôi sục đến một vấn đề của hương vị và kinh nghiệm.

Bởi vì bạn nên liên tục thử thách kiến ​​thức của chính mình. Bạn thích lật đổ, và tôi có thể hiểu bởi vì tôi đã sử dụng nó trong nhiều năm, và rất hài lòng về nó, nhưng điều đó không có nghĩa là nó vẫn là công cụ phù hợp nhất với bạn.

Tôi tin rằng khi tôi bắt đầu sử dụng nó, đó là sự lựa chọn tốt nhất vào thời điểm đó. Nhưng các công cụ khác xuất hiện theo thời gian và bây giờ tôi thích git hơn, ngay cả đối với các dự án thời gian rảnh rỗi của riêng tôi.

Và lật đổ có một số thiếu sót. Ví dụ: nếu bạn đổi tên một thư mục trên đĩa, thì nó không được đổi tên trong kho lưu trữ. Di chuyển tệp không được hỗ trợ, làm cho một tệp di chuyển một hoạt động sao chép / xóa, làm cho việc thay đổi hợp nhất khi các tệp đã được di chuyển / đổi tên khó khăn. Và theo dõi hợp nhất không thực sự được xây dựng trong hệ thống, thay vào đó được thực hiện dưới dạng một cách giải quyết.

Git giải quyết những vấn đề này (bao gồm tự động phát hiện nếu một tập tin đã được di chuyển, bạn thậm chí không cần phải nói đó là sự thật).

Mặt khác, git không cho phép bạn phân nhánh trên các cấp thư mục riêng lẻ như lật đổ.

Vì vậy, câu trả lời của tôi là, bạn nên điều tra các lựa chọn thay thế, xem nó có phù hợp với nhu cầu của bạn hơn những gì bạn quen thuộc không, và sau đó quyết định.

Liên quan đến hiệu suất, Git hoặc bất kỳ DVCS nào khác có lợi thế lớn so với SVN khi bạn phải chuyển từ chi nhánh này sang chi nhánh khác hoặc chuyển từ sửa đổi này sang sửa đổi khác. Vì mọi thứ được lưu trữ cục bộ, mọi thứ nhanh hơn nhiều so với SVN.

Điều này một mình có thể làm cho tôi chuyển đổi!

Thay vì dựa vào ý tưởng rằng "bằng cách áp dụng các thực tiễn tốt nhất bạn không cần DVCS", tại sao không xem xét rằng quy trình công việc SVN là một quy trình công việc, với một tập hợp các thực tiễn tốt nhất và quy trình công việc GIT / Hg là một quy trình công việc khác, với một tập hợp thực hành tốt nhất khác nhau.

git bisect (và tất cả ý nghĩa của nó trên kho lưu trữ chính của bạn)

Trong Git, một nguyên tắc rất quan trọng là bạn có thể tìm thấy lỗi bằng cách sử dụng git bisect. Để thực hiện việc này, bạn lấy phiên bản cuối cùng mà bạn đã chạy được biết là hoạt động và phiên bản đầu tiên bạn chạy bị lỗi và bạn thực hiện (với sự trợ giúp của Git) để tìm ra lỗi nào gây ra lỗi. Để làm điều này, toàn bộ lịch sử sửa đổi của bạn phải tương đối không có các lỗi khác có thể gây trở ngại cho việc tìm kiếm lỗi của bạn (tin hay không, điều này thực sự hoạt động khá tốt trong thực tế và các nhà phát triển nhân Linux luôn làm điều này).

Để đạt được git bisectkhả năng, bạn phát triển một tính năng mới trên nhánh tính năng của riêng mình , khởi động lại và xóa lịch sử (để bạn không có bất kỳ sửa đổi không hoạt động nào được biết đến trong lịch sử của mình - chỉ là một loạt các thay đổi mà mỗi lần bạn có được để khắc phục sự cố) và sau đó khi tính năng được hoàn thành, bạn hợp nhất nó vào nhánh chính với lịch sử làm việc.

Ngoài ra, để làm cho công việc này, bạn phải có kỷ luật về phiên bản của nhánh chính mà bạn bắt đầu từ nhánh tính năng của mình. Bạn không thể bắt đầu từ trạng thái hiện tại của masterchi nhánh vì điều đó có thể có các lỗi không liên quan - vì vậy lời khuyên trong cộng đồng kernel là bắt đầu làm việc từ phiên bản ổn định mới nhất của kernel (cho các tính năng lớn) hoặc bắt đầu công việc từ ứng cử viên phát hành được gắn thẻ mới nhất.

Trong thời gian này, bạn cũng có thể sao lưu tiến trình trung gian của mình bằng cách đẩy nhánh tính năng đến máy chủ và bạn có thể đẩy nhánh tính năng đến máy chủ để chia sẻ nó với người khác và gợi ý phản hồi, trước khi tính năng hoàn tất, trước khi bạn phải biến mã thành một tính năng vĩnh viễn của cơ sở mã mà mọi người * trong dự án của bạn phải đối phó.

Các gitworkflows trang người đàn ông là một giới thiệu tốt để các quy trình công việc mà Git được thiết kế cho. Ngoài ra Tại sao Git tốt hơn X thảo luận về quy trình công việc của git.

Dự án lớn, phân phối

Tại sao chúng ta cần trung úy trong một nhóm cộng tác cao với thực tiễn tốt và thói quen thiết kế tốt?

Bởi vì trong các dự án như Linux, có rất nhiều người tham gia được phân phối theo địa lý đến mức khó có thể hợp tác cao như một nhóm nhỏ có chung phòng hội nghị. (Tôi nghi ngờ rằng để phát triển một sản phẩm lớn như Microsoft Windows mà ngay cả khi mọi người đều ở trong cùng một tòa nhà, nhóm chỉ quá lớn để duy trì mức độ hợp tác làm cho một VCS tập trung hoạt động mà không cần người nói dối.)

Tại sao không sử dụng chúng song song? Trong dự án hiện tại của tôi, chúng tôi buộc phải sử dụng CVS. Tuy nhiên, chúng tôi cũng giữ các kho git cục bộ để phát triển tính năng. Đây là điều tốt nhất của cả hai thế giới bởi vì bạn có thể thử nhiều giải pháp khác nhau và giữ các phiên bản của những gì bạn đang làm việc trên máy của riêng bạn. Điều này cho phép bạn quay trở lại các phiên bản trước của tính năng hoặc thử một số cách tiếp cận mà không gặp sự cố khi bạn làm rối mã của mình. Có một kho lưu trữ trung tâm sau đó cung cấp cho bạn những lợi ích của việc có một kho lưu trữ tập trung.

Tôi không có kinh nghiệm cá nhân với DVCS, nhưng từ những gì tôi thu thập được từ các câu trả lời ở đây và một số tài liệu được liên kết, sự khác biệt cơ bản nhất giữa DVCS và CVCS là mô hình làm việc được sử dụng

DVCS

Mô hình làm việc của DVCS là bạn đang thực hiện phát triển biệt lập . Bạn đang phát triển tính năng / sửa lỗi mới tách biệt với tất cả các thay đổi khác cho đến khi bạn quyết định phát hành nó cho các thành viên còn lại trong nhóm. Cho đến thời điểm đó, bạn có thể thực hiện bất kỳ đăng ký nào bạn thích, bởi vì không ai khác sẽ bị làm phiền với nó.

CVCS

Mô hình làm việc của CVCS (đặc biệt là Subversion) là bạn đang thực hiện phát triển hợp tác . Bạn đang phát triển tính năng / sửa lỗi mới của mình trong sự hợp tác trực tiếp với tất cả các thành viên khác trong nhóm và tất cả các thay đổi có sẵn ngay lập tức cho tất cả mọi người.

Sự khác biệt khác

Sự khác biệt khác giữa svnvà git/ hg, chẳng hạn như sửa đổi so với thay đổi là ngẫu nhiên. Rất có thể tạo DVCS dựa trên các phiên bản (vì Subversion có chúng) hoặc CVCS dựa trên các thay đổi (như Git / Mercurial có chúng).

Tôi sẽ không đề xuất bất kỳ công cụ cụ thể nào, bởi vì nó chủ yếu phụ thuộc vào mô hình làm việc mà bạn (và nhóm của bạn) cảm thấy thoải mái nhất.
Cá nhân tôi không gặp vấn đề gì khi làm việc với CVCS.

• Tôi không sợ kiểm tra các thứ, vì tôi không có vấn đề gì khi đưa nó vào trạng thái không hoàn chỉnh, nhưng có thể biên dịch được.
• Khi tôi trải nghiệm địa ngục hợp nhất, đó là trong tình huống nó sẽ xảy ra ở cả hai svnvà git/ hg. Ví dụ, V2 của một số phần mềm đang được duy trì bởi một nhóm khác, sử dụng một VCS khác, trong khi chúng tôi đang phát triển V3. Đôi khi, các lỗi phải được nhập từ V2 VCS ​​sang V3 VCS, về cơ bản có nghĩa là thực hiện đăng ký rất lớn trên V3 VCS (với tất cả các lỗi trong một thay đổi duy nhất). Tôi biết điều đó không lý tưởng, nhưng đó là quyết định quản lý để sử dụng các hệ thống VCS khác nhau.