DVCS được sử dụng trong các đội lớn như thế nào?

Question

Gần đây tôi đã bắt đầu tham gia vào Git trên một dự án cá nhân và tôi có thể thấy DVCS có thể mang lại lợi ích cho chúng tôi như thế nào (công ty phần mềm doanh nghiệp lớn hiện đang chạy Perforce). Tính năng công việc trong nhóm của tôi, ví dụ chủ yếu bao gồm các nhà phát triển tạo ra các chi nhánh của riêng họ; đôi khi chúng được chia sẻ giữa các nhóm nhỏ các nhà phát triển. Tôi nghĩ rằng nó sẽ hiệu quả hơn trong trường hợp này để sử dụng DVCS.

Trong trường hợp tổng quát hơn, tuy nhiên, tôi muốn được nghe từ những người sử dụng DVCS tại nơi làm việc, trong các nhóm trung bình đến lớn.

1. Làm thế nào để bạn đối phó với hợp nhất N-cách? Đây có phải là một tình huống phổ biến không? Mercurial chỉ hỗ trợ hợp nhất N-way bằng cách thực hiện (N-1) hợp nhất 2 chiều (và read rằng đây là giải pháp ưu tiên trong DVCS khác), nghe giống như một quá trình rất mất thời gian cho cả tương đối nhỏ N.
2. sử dụng một kho lưu trữ có thẩm quyền trung tâm duy nhất, hay nó thực sự là P2P?
3. Các nhà phát triển có thường xuyên đẩy và kéo mã vào và ra khỏi nhau hay thực hiện mọi thứ qua kho lưu trữ trung tâm?

Answer 1

Nhóm của tôi tại nhà tuyển dụng trước đây của tôi đã sử dụng Git và nó hoạt động tốt cho chúng tôi. Chúng tôi không phải là tất cả những gì lớn (có thể 16 hoặc hơn, với 8 ủy ban hoạt động thực sự?), Nhưng tôi có câu trả lời cho các câu hỏi của bạn:

1. N-cách sáp nhập không quá phổ biến. Chúng tôi đã đưa ra một số quy ước về đặt tên chi nhánh cho phép chúng tôi viết kịch bản làm giảm quy trình "phát hành kỹ thuật" (tôi sử dụng dấu ngoặc kép vì chúng tôi không có kỹ sư phát hành) và mọi người sẽ tạo các chi nhánh riêng, nhưng chúng tôi hiếm khi có vấn đề với việc hợp nhất nhiều hơn hai nhánh (xem phần tiếp theo).
2. (và # 3).Chúng tôi đã có kho lưu trữ trung tâm trên một máy chủ phát triển vì ba lý do: (a) Máy phát triển có RAID5 (khả năng chịu lỗi nhiều hơn) và sao lưu hàng đêm (máy trạm không phải là ban đêm), (b) bản phát hành sản xuất được xây dựng trên máy chủ phát triển, và (c) có một kịch bản lưu trữ tập trung đơn giản hóa. Kết quả là, sự kết hợp N-way đơn giản chưa bao giờ xảy ra. Điều gần nhất mà chúng tôi đã có đối với N-way là khi một người nào đó sáp nhập vào nhau và sau đó sáp nhập theo chiều dọc.

Git là một điều thực sự tuyệt vời đối với chúng tôi vì tính linh hoạt cao; tuy nhiên, chúng tôi đã phải thiết lập một số quy ước (tên chi nhánh và thẻ, vị trí repo, tập lệnh, v.v.) hoặc có thể hơi hỗn loạn. Khi chúng tôi đã thiết lập các quy ước, tính linh hoạt mà chúng tôi có chỉ là tuyệt vời.

Cập nhật: ước của chúng tôi về cơ bản là như sau:

• một thư mục trên máy chủ NFS của chúng tôi là nơi ở của tất cả các kho trung tâm
• chúng tôi đã có một số dự án thành phần chia sẻ, vì vậy chúng tôi đã phá vỡ chúng ra vào thư viện, về cơ bản, với các kho lưu trữ của riêng họ và các dự án có thể phân phối chỉ bao gồm chúng dưới dạng các mô đun con git.
• đã có chuỗi phiên bản và phát hành tên đối với chúng ta từ trên cao, vì vậy chúng tôi chỉ sử dụng một biến thể của những người như tên chi nhánh
• tương tự, cho thẻ, họ theo tên phát hành quá trình quyết
• các dự án chuyển giao chứa một tệp thuộc tính mà tôi đọc vào các kịch bản lệnh shell và cho phép tôi viết một kịch bản lệnh duy nhất để quản lý quá trình phát hành cho tất cả các dự án, mặc dù mỗi người có các biến thể nhỏ trên quy trình - các biến thể được tính trong các tệp thuộc tính đó
• Tôi đã viết tập lệnh có thể tạo lại gói có thể phân phối từ bất kỳ thẻ nào
• bằng git al hạ thấp chúng tôi để kiểm soát quyền truy cập bằng PAM và/hoặc quyền người dùng thông thường (ssh, v.v.)
• Có các quy ước khác khó đưa vào danh sách có dấu đầu dòng, như khi việc hợp nhất xảy ra. Thực sự, tôi và một người khác là loại "gitus" trong nhà, và chúng tôi đã giúp mọi người tìm ra cách sử dụng các nhánh và khi nào để hợp nhất.
• khiến mọi người tham gia vào các đoạn nhỏ và không thả bom khác trong nhánh chính là một thách thức. Một anh chàng đã mất khoảng hai tuần làm việc vững chắc trong một lần cam kết, và cuối cùng chúng tôi phải làm sáng tỏ tất cả. A to phí thời gian và bực bội cho tất cả mọi người.
• bình luận thông tin và chi tiết để đi với cam kết

Có những thứ khác mà bạn học được khi đội của bạn được trải nghiệm và học cách làm việc với nhau, nhưng điều này đã đủ để chúng ta bắt đầu.

Cập nhật: bất kỳ ai theo dõi những điều như vậy bây giờ đã biết về điều đó, nhưng Vincent Dreissen đã viết một bản vững chắc và khá toàn diện (nhưng không exaustive) take on branching and release engineering using Git. Tôi rất muốn khuyến khích sử dụng quy trình của mình như là một điểm khởi đầu bởi vì đối với hai lý do:

• rất nhiều đội làm theo cách này hoặc đang sử dụng một số biến thể gần (bao gồm cả Linux, Git, và nhiều nhóm dự án OSS khác), trong đó có nghĩa là phương pháp này đã được thử nghiệm và tinh chỉnh để thành công trong hầu hết các trường hợp. Bạn rất khó có thể đối mặt với một vấn đề chưa được đối mặt và giải quyết trong các ràng buộc của mô hình này.
• vì đã nói ở trên, hầu như bất kỳ kỹ sư nào có trải nghiệm Git đều sẽ hiểu những gì đang diễn ra. Bạn sẽ không phải viết tài liệu chi tiết về bản chất cơ bản của quá trình phát hành của bạn; bạn sẽ chỉ phải ghi lại những điều cụ thể chỉ cho dự án hoặc nhóm của bạn.

Answer 2

Dưới đây là một ví dụ (bởi không có nghĩa là một "phổ quát" một)

Chúng tôi đã VCS trung ương (ClearCase hoặc Subversion, tùy thuộc vào các dự án khác nhau), và chúng tôi đang sử dụng chúng cho sự phát triển "chính thức" nỗ lực (dev, bản vá lỗi, bản sửa lỗi), nơi số lượng chi nhánh bị hạn chế và được xác định rõ.

Tuy nhiên, để phát triển tái cấu trúc liên quan đến nhiều trạng thái trung gian, không có gì hoạt động và nhiều nhà phát triển cần có chi nhánh hoạt động của riêng mình hoặc chi nhánh , một số kho Git được thiết lập giữa các nhà phát triển đó Cách P2P.
Một khi công việc đạt được một số loại 0,1 ổn định, và sáp nhập được giảm, nó được tái nhập khẩu trong VCS, nơi công việc có thể đi vào trong một "trật tự" thời trang trung tâm.

Kể từ Git on Windows works well (MSysGit), chúng tôi quản lý để có những phát triển ban đầu nhỏ được thực hiện nhanh chóng theo cách đó.

Chúng tôi vẫn đang đánh giá Git để phát triển dự án có quy mô đầy đủ.

Answer 3

Có lẽ tốt nhất là hãy xem xét cách các nhà phát triển hạt nhân Linux hoạt động. Họ có một luồng công việc khá phức tạp, nơi các thay đổi được gửi từ nhiều nguồn, và sau đó các nhà phát triển đáng tin cậy cho mỗi subsytem (gọi là trung úy) kéo các thay đổi, và khi họ vui lòng gửi chúng cho Linus, người cuối cùng hoặc kéo chúng vào cây hoặc từ chối chúng. Tất nhiên nó phức tạp hơn thế, nhưng đó là tổng quan chung.

Answer 4

Tôi đã làm việc nhiều năm với nhóm Glasgow Haskell Compiler sử dụng Darcs. Gần đây tôi đã (vài tháng) bắt đầu sử dụng git cho bản sao repo của riêng tôi, cả về hiệu suất và cải thiện giáo dục của tôi.

1. Làm thế nào để bạn đối phó với hợp nhất N-cách?

   Không có cách hợp nhất N-cách. Mỗi nhà phát triển bắt nguồn một luồng các bản vá và các luồng được hợp nhất từng lần một tại mỗi repo. Vì vậy, nếu nhà phát triển N thực hiện thay đổi cùng một lúc, họ sẽ được hợp nhất theo cặp.

2. Bạn có sử dụng một kho lưu trữ có thẩm quyền trung tâm duy nhất không?

   Tuyệt đối. Đó là cách duy nhất để biết GHC là gì và những gì không phải là GHC.

3. Các nhà phát triển có thường xuyên đẩy và kéo mã vào và ra khỏi nhau hay thực hiện mọi thứ qua kho lưu trữ trung tâm?

   Tôi nghĩ điều đó tùy thuộc vào nhà phát triển và VCS bạn đang sử dụng. Trên dự án GHC gần như tất cả các kéo và đẩy tôi thấy đi qua kho trung tâm. Nhưng có một gatekeeper nặng (self-quản lý) trên push to repo trung tâm, và nếu một đồng nghiệp có một sửa chữa lỗi tôi cần bây giờ, tôi sẽ kéo nó trực tiếp từ repo của mình. Với darcs, rất dễ dàng để kéo chỉ một miếng vá (chứ không phải toàn bộ trạng thái như trong git), và tôi biết rằng các đồng nghiệp của tôi, những người có nhiều kinh nghiệm hơn với darcs, sử dụng tính năng này nhiều hơn tôi --- và họ thích nó rất nhiều.

   Với git, khi tôi làm việc chặt chẽ với một nhà phát triển khác, tôi sẽ thường xuyên tạo chi nhánh mới chỉ nhằm mục đích chia sẻ nó với một người khác. Nhánh đó sẽ không bao giờ chạm vào repo trung tâm.

Answer 5

Các khá nổi tiếng "Tech Talk: Linus Torvalds trên git" giải thích cách nó được sử dụng cho Linux (khoảng lớn như đội như tôi có thể nghĩ đến)

Nếu tôi nhớ chính xác, đó là sử dụng được Giống như một chuỗi lệnh của quân đội - mỗi mô-đun có một người bảo trì, người xử lý các yêu cầu kéo từ các nhà phát triển, sau đó có một vài người "đáng tin cậy nhất" xử lý dữ liệu từ các nhà duy trì mô-đun vào kho lưu trữ kernel.org git chính thức.

"Linux: Managing the Kernel Source With 'git'" cũng giải thích nó, mặc dù một lần nữa nó hầu như không một lời giải thích ngắn gọn .. schema

Answer 6

Work-dòng chảy từ whygitisbetterthanx:

alt git work-flow with integration manager http://whygitisbetterthanx.com/images/workflow-b.png

Để mở rộng quy mô này lên đến thậm chí nhiều nhà phát triển, bạn chỉ cần thêm một lớp "người trung thành đáng tin cậy" khác giữa người quản lý tích hợp và nhà phát triển.