Kiểm soát Nguồn Dựa trên Git trong Doanh nghiệp: Các Công cụ và Thực tiễn được Đề xuất?

Tôi sử dụng git cho các dự án cá nhân và nghĩ rằng nó rất tuyệt. Nó nhanh, linh hoạt, mạnh mẽ và hoạt động tuyệt vời để phát triển từ xa.

Nhưng bây giờ nó được yêu cầu trong công việc và thành thật mà nói, chúng tôi đang gặp vấn đề.

Ngoài ra, git dường như không hoạt động tốt để phát triển tập trung trong một tổ chức lớn (hơn 20 nhà phát triển) với các nhà phát triển có khả năng và mức độ tinh vi khác nhau của git - đặc biệt là so với các hệ thống kiểm soát nguồn khác như Perforce hoặc Subversion, nhằm vào loại môi trường đó. (Vâng, tôi biết, Linus không bao giờ có ý định đó.)

Nhưng - vì lý do chính trị - chúng tôi bị mắc kẹt với git, ngay cả khi nó tệ vì những gì chúng tôi đang cố gắng làm với nó.

Dưới đây là một số điều chúng ta đang thấy:

• Các công cụ GUI chưa hoàn thiện
• Sử dụng các công cụ dòng lệnh, thật dễ dàng để bắt kịp hợp nhất và xóa các thay đổi của người khác
• Nó không cung cấp các quyền đối với kho lưu trữ cho mỗi người dùng ngoài các đặc quyền chỉ đọc hoặc đọc ghi trên toàn cầu
• Nếu bạn có quyền đối với BẤT KỲ phần nào của kho lưu trữ, bạn có thể làm điều đó tương tự với MỌI phần của kho lưu trữ, vì vậy bạn không thể làm điều gì đó như tạo một nhánh theo dõi nhóm nhỏ trên máy chủ trung tâm mà những người khác không thể gây rối với.
• Khó có thể khuyến khích các quy trình làm việc khác với quy trình "bất cứ điều gì xảy ra" hoặc "nhà độc tài nhân từ", chứ đừng nói đến việc thực thi
• Không rõ liệu tốt hơn nên sử dụng một kho lưu trữ lớn duy nhất (cho phép mọi người xáo trộn mọi thứ) hay nhiều kho lưu trữ cho mỗi thành phần (khiến bạn đau đầu khi cố gắng đồng bộ hóa các phiên bản).
• Với nhiều kho lưu trữ, cũng không rõ ràng làm thế nào để sao chép tất cả các nguồn mà người khác có bằng cách lấy từ kho lưu trữ trung tâm hoặc làm điều gì đó như tải mọi thứ vào lúc 4:30 chiều hôm qua.

Tuy nhiên, tôi nghe nói rằng mọi người đang sử dụng thành công git trong các tổ chức phát triển lớn.

Nếu bạn đang ở trong tình huống đó - hoặc nếu bạn thường có các công cụ, mẹo và thủ thuật để giúp sử dụng git dễ dàng và hiệu quả hơn trong một tổ chức lớn, nơi một số người không phải là người hâm mộ dòng lệnh - tôi rất muốn nghe những gì bạn có để gợi ý.

BTW, tôi đã hỏi một phiên bản của câu hỏi này trên LinkedIn và không có câu trả lời thực sự nhưng rất nhiều câu "trời ơi, tôi cũng muốn biết điều đó!"

CẬP NHẬT: Hãy để tôi làm rõ ...

Nơi tôi làm việc, chúng tôi không thể sử dụng BẤT KỲ THỨ GÌ ngoài git . Nó không phải là một lựa chọn. Chúng tôi bị mắc kẹt với nó. Chúng tôi không thể sử dụng swurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monotone, Perforce, Fossil, AccuRev, CVS, hoặc thậm chí là Máy chiếu tốt của Apple mà tôi đã sử dụng vào năm 1987. Vì vậy, trong khi bạn được hoan nghênh thảo luận về các lựa chọn khác, bạn sẽ không nhận được tiền thưởng nếu bạn không thảo luận về git.

Ngoài ra, tôi đang tìm kiếm các mẹo thực tế về cách sử dụng git trong doanh nghiệp . Tôi đặt một danh sách toàn bộ các vấn đề mà chúng tôi đang gặp phải ở đầu câu hỏi này. Một lần nữa, mọi người được hoan nghênh thảo luận về lý thuyết, nhưng nếu bạn muốn kiếm được tiền thưởng, hãy cho tôi giải pháp.

Ngược lại với quan điểm chung, tôi nghĩ rằng sử dụng DVCS là một lựa chọn lý tưởng trong môi trường doanh nghiệp vì nó cho phép quy trình làm việc rất linh hoạt. Trước tiên, tôi sẽ nói về việc sử dụng DVCS so với CVCS, các phương pháp hay nhất và sau đó là về git nói riêng.

DVCS so với CVCS trong bối cảnh doanh nghiệp:

Tôi sẽ không nói về ưu / nhược điểm chung ở đây, mà tập trung vào ngữ cảnh của bạn. Người ta thường quan niệm rằng việc sử dụng DVCS đòi hỏi một nhóm có kỷ luật hơn so với việc sử dụng một hệ thống tập trung. Điều này là do một hệ thống tập trung cung cấp cho bạn một cách dễ dàng để thực thi quy trình làm việc của mình, việc sử dụng một hệ thống phi tập trung đòi hỏi nhiều giao tiếp và kỷ luật hơn để tuân thủ các quy ước đã thiết lập. Mặc dù điều này có vẻ như nó gây ra chi phí cao, nhưng tôi thấy lợi ích trong việc tăng cường giao tiếp cần thiết để biến nó thành một quá trình tốt. Nhóm của bạn sẽ cần trao đổi về mã, về các thay đổi và về trạng thái dự án nói chung.

Một khía cạnh khác trong bối cảnh kỷ luật là khuyến khích phân nhánh và thử nghiệm. Đây là một trích dẫn từ mục nhập Bliki gần đây của Martin Fowler trên Công cụ kiểm soát phiên bản , anh ấy đã tìm thấy một mô tả rất ngắn gọn cho hiện tượng này.

DVCS khuyến khích phân nhánh nhanh để thử nghiệm. Bạn có thể mở các chi nhánh trong Subversion, nhưng thực tế là chúng được hiển thị cho tất cả mọi người không khuyến khích mọi người mở chi nhánh cho công việc thử nghiệm. Tương tự như vậy, một DVCS khuyến khích việc kiểm tra chỉ điểm công việc: thực hiện các thay đổi chưa hoàn chỉnh, thậm chí có thể không biên dịch hoặc vượt qua các bài kiểm tra, vào kho lưu trữ cục bộ của bạn. Một lần nữa, bạn có thể thực hiện việc này trên một chi nhánh của nhà phát triển trong Subversion, nhưng thực tế là các chi nhánh như vậy nằm trong không gian chia sẻ khiến mọi người ít có khả năng làm như vậy.

DVCS cho phép các quy trình làm việc linh hoạt vì chúng cung cấp theo dõi tập thay đổi thông qua các số nhận dạng duy nhất trên toàn cầu trong một biểu đồ xoay chiều có hướng (DAG) thay vì các khác biệt văn bản đơn giản. Điều này cho phép họ theo dõi rõ ràng nguồn gốc và lịch sử của tập thay đổi, điều này có thể khá quan trọng.

Quy trình làm việc:

Larry Osterman (một nhà phát triển Microsoft làm việc trong nhóm Windows) có một bài đăng trên blog tuyệt vời về quy trình làm việc mà họ tuyển dụng tại nhóm Windows. Đáng chú ý nhất là họ có:

• Một thân cây mã chỉ sạch, chất lượng cao (đại diện chính)
• Tất cả sự phát triển xảy ra trên các nhánh tính năng
• Nhóm tính năng có repos nhóm
• Họ thường xuyên hợp nhất các thay đổi thân mới nhất vào nhánh tính năng của họ ( Tích hợp chuyển tiếp )
• Các tính năng hoàn chỉnh phải vượt qua một số cửa chất lượng, ví dụ như đánh giá, phạm vi kiểm tra, Q&A (tự repos)
• Nếu một tính năng được hoàn thành và có chất lượng chấp nhận được thì nó sẽ được hợp nhất vào trung kế ( Tích hợp ngược )

Như bạn có thể thấy, khi từng kho này tự hoạt động, bạn có thể tách các đội khác nhau tiến lên ở các tốc độ khác nhau. Ngoài ra, khả năng thực hiện một hệ thống cổng chất lượng linh hoạt giúp phân biệt DVCS với CVCS. Bạn cũng có thể giải quyết các vấn đề về quyền của mình ở cấp độ này. Chỉ một số ít người được phép truy cập vào repo chính. Đối với mỗi cấp của hệ thống phân cấp, có một repo riêng biệt với các chính sách truy cập tương ứng. Thật vậy, cách tiếp cận này có thể rất linh hoạt ở cấp độ đội. Bạn nên để cho mỗi nhóm quyết định xem họ muốn chia sẻ repo nhóm của họ với nhau hoặc nếu họ muốn một cách tiếp cận thực tế hơn, trong đó chỉ có trưởng nhóm mới có thể cam kết repo nhóm.

(Hình ảnh bị đánh cắp từ hginit.com của Joel Spolsky .)

Tuy nhiên, một điều vẫn cần được nói vào thời điểm này: - mặc dù DVCS cung cấp khả năng hợp nhất tuyệt vời, điều này không bao giờ thay thế cho việc sử dụng Tích hợp liên tục. Ngay cả tại thời điểm đó, bạn có rất nhiều sự linh hoạt: CI cho đại diện thân, CI cho đại diện nhóm, đại diện hỏi đáp, v.v.

Git trong bối cảnh doanh nghiệp:

Git có thể không phải là giải pháp lý tưởng cho bối cảnh doanh nghiệp như bạn đã chỉ ra. Nhắc lại một số mối quan tâm của bạn, tôi nghĩ đáng chú ý nhất là:

• Hỗ trợ vẫn còn hơi non nớt trên Windows (vui lòng sửa cho tôi nếu điều đó đã thay đổi gần đây) Bây giờ windows có ứng dụng khách github windows , rùa , SourceTree từ atlassian
• Thiếu các công cụ GUI hoàn thiện, không có tích hợp công cụ vdiff / hợp nhất công dân hạng nhất
• Giao diện không phù hợp với mức độ trừu tượng rất thấp trên các hoạt động bên trong của nó
• Một đường cong học tập rất dốc cho người dùng svn
• Git rất mạnh và giúp bạn dễ dàng sửa đổi lịch sử, rất nguy hiểm nếu bạn không biết mình đang làm gì (và đôi khi bạn sẽ làm như vậy ngay cả khi bạn nghĩ rằng mình đã biết)
• Không có tùy chọn hỗ trợ thương mại nào

Tôi không muốn bắt đầu cuộc chiến git vs. hg ở đây, bạn đã thực hiện đúng bước khi chuyển sang DVCS. Mercurial giải quyết một số điểm ở trên và tôi nghĩ rằng nó phù hợp hơn trong bối cảnh doanh nghiệp:

• Tất cả các plattforms chạy python đều được hỗ trợ
• Các công cụ GUI tuyệt vời trên tất cả các plattform chính (win / linux / OS X), tích hợp công cụ hợp nhất / vdiff hạng nhất
• Giao diện rất nhất quán, dễ dàng chuyển đổi cho người dùng svn
• Có thể làm hầu hết những thứ mà git có thể làm, nhưng cung cấp một sự trừu tượng rõ ràng hơn. Các hoạt động nguy hiểm luôn rõ ràng. Các tính năng nâng cao được cung cấp thông qua các tiện ích mở rộng phải được bật rõ ràng.
• Hỗ trợ thương mại có sẵn từ selenic.

Tóm lại, khi sử dụng DVCS trong một doanh nghiệp, tôi nghĩ điều quan trọng là phải chọn một công cụ giới thiệu ít ma sát nhất. Để quá trình chuyển đổi thành công, điều đặc biệt quan trọng là phải xem xét kỹ năng khác nhau giữa các nhà phát triển (liên quan đến VCS).

Giảm ma sát:

Được rồi, vì bạn có vẻ thực sự bị mắc kẹt với tình huống này, IMHO còn hai tùy chọn. Không có công cụ nào để làm cho git bớt phức tạp hơn; git là phức tạp. Hoặc bạn đối mặt với điều này hoặc làm việc xung quanh git: -

1. Nhận một khóa học giới thiệu git cho cả nhóm. Điều này chỉ nên bao gồm những điều cơ bản và một số bài tập (quan trọng!).
2. Chuyển đổi tổng đại diện thành svn và để "các ngôi sao trẻ" git-svn . Điều này mang lại cho hầu hết các nhà phát triển một giao diện dễ sử dụng và có thể bù đắp cho sự thiếu kỷ luật trong nhóm của bạn, trong khi các ngôi sao trẻ có thể tiếp tục sử dụng git cho repo của riêng họ.

Thành thật mà nói, tôi nghĩ bạn thực sự có vấn đề về con người hơn là vấn đề về công cụ. Có thể làm gì để cải thiện tình trạng này?

• Bạn nên nói rõ rằng bạn nghĩ rằng quy trình hiện tại của bạn sẽ kết thúc với một cơ sở mã có thể bảo trì được.
• Đầu tư một chút thời gian vào Tích hợp liên tục. Như tôi đã trình bày ở trên, bất kể bạn sử dụng loại VCS nào, không bao giờ có sự thay thế cho CI. Bạn đã nói rằng có những người đẩy những thứ tào lao vào tổng kho: Yêu cầu họ sửa lỗi tào lao của họ trong khi cảnh báo đỏ xuất hiện và đổ lỗi cho họ vì đã phá vỡ bản dựng (hoặc không đáp ứng chỉ số chất lượng hoặc bất cứ điều gì).

Tôi là kỹ sư SCM cho một tổ chức phát triển lớn hợp lý và chúng tôi đã chuyển đổi sang git từ svn trong khoảng năm ngoái. Chúng tôi sử dụng nó theo cách tập trung.

Chúng tôi sử dụng gitosis để lưu trữ các kho lưu trữ. Chúng tôi đã phá vỡ các kho lưu trữ svn nguyên khối của mình thành nhiều kho lưu trữ git nhỏ hơn vì đơn vị phân nhánh của git về cơ bản là kho lưu trữ. (Có nhiều cách giải quyết vấn đề đó, nhưng chúng rất khó xử.) Nếu bạn muốn các loại điều khiển truy cập theo từng nhánh, gitolite có thể là một cách tiếp cận tốt hơn. Ngoài ra còn có phiên bản tường lửa bên trong của GitHub nếu bạn muốn chi tiền. Đối với mục đích của chúng tôi, gitosis là tốt vì chúng tôi có các quyền khá mở đối với kho lưu trữ của mình. (Chúng tôi có các nhóm người có quyền ghi vào các nhóm kho và mọi người đều có quyền đọc vào tất cả các kho.) Chúng tôi sử dụng gitweb cho giao diện web.

Đối với một số mối quan tâm cụ thể của bạn:

• hợp nhất: Bạn có thể sử dụng một công cụ hợp nhất trực quan mà bạn chọn; có hướng dẫn ở nhiều nơi khác nhau về cách thiết lập nó. Thực tế là bạn có thể thực hiện hợp nhất và kiểm tra tính hợp lệ của nó hoàn toàn trên repo cục bộ của bạn, theo ý kiến ​​của tôi, là một điểm cộng lớn cho git; bạn có thể xác minh việc hợp nhất trước khi đẩy bất cứ thứ gì.
• GUI: Chúng tôi có một vài người sử dụng TortoiseGit nhưng tôi không thực sự khuyên bạn nên sử dụng nó; nó dường như tương tác theo những cách kỳ lạ với dòng lệnh. Tôi phải đồng ý rằng đây là một lĩnh vực cần được cải thiện. (Điều đó nói rằng, tôi không phải là một fan hâm mộ của GUI để kiểm soát phiên bản nói chung.)
• các nhánh theo dõi nhóm nhỏ: Nếu bạn sử dụng thứ gì đó cung cấp ACL chi tiết hơn như gitolite, thì việc này rất dễ dàng, nhưng bạn cũng có thể tạo một nhánh chia sẻ bằng cách kết nối các kho lưu trữ cục bộ của các nhà phát triển khác nhau - một kho git có thể có nhiều điều khiển từ xa.

Chúng tôi chuyển sang git vì chúng tôi có nhiều nhà phát triển từ xa và vì chúng tôi gặp nhiều vấn đề với Subversion. Chúng tôi vẫn đang thử nghiệm quy trình làm việc, nhưng hiện tại về cơ bản chúng tôi sử dụng nó theo cách giống như chúng tôi đã sử dụng Subversion. Một điều khác mà chúng tôi thích về nó là nó đã mở ra các quy trình công việc có thể có khác, chẳng hạn như việc sử dụng các kho lưu trữ tổ chức để xem xét mã và chia sẻ mã giữa các nhóm nhỏ. Nó cũng được khuyến khích nhiều người bắt đầu theo dõi các tập lệnh cá nhân của họ, v.v. bởi vì việc tạo một kho lưu trữ rất dễ dàng.

Vâng, tôi biết, Linus chưa bao giờ có ý định đó.

Trên thực tế, Linus lập luận rằng các hệ thống tập trung không thể hoạt động.

Và, có gì sai với quy trình làm việc của các nhà độc tài và các trung úy?

Hãy nhớ rằng, git là một hệ thống phân tán ; đừng cố gắng sử dụng nó như một trung tâm.

(đã cập nhật)

Hầu hết các vấn đề của bạn sẽ biến mất nếu bạn không cố gắng sử dụng git như thể nó là "svn trên steroid" (vì nó không phải vậy).

Thay vì sử dụng kho lưu trữ trống làm máy chủ trung tâm nơi mọi người có thể đẩy đến (và có khả năng làm hỏng), hãy thiết lập một số trình quản lý tích hợp xử lý các hợp nhất, để chỉ họ có thể đẩy đến kho lưu trữ trống.

Thông thường những người này nên là trưởng nhóm: mỗi người lãnh đạo tích hợp công việc của nhóm riêng của mình và đẩy nó vào kho lưu trữ may mắn.

Thậm chí tốt hơn, ai đó khác (tức là nhà độc tài) lấy từ các trưởng nhóm và tích hợp các thay đổi của họ vào kho lưu trữ may mắn.

Không có gì sai với quy trình làm việc đó, nhưng chúng tôi là một công ty khởi nghiệp làm việc quá sức và cần các công cụ của chúng tôi để thay thế cho thời gian và sự chú ý của con người; không ai có băng thông để thậm chí thực hiện đánh giá mã, hãy để một mình trở thành nhà độc tài nhân từ.

Nếu các nhà tích hợp không có thời gian để xem xét mã, điều đó cũng tốt, nhưng bạn vẫn cần có những người tích hợp các hợp nhất từ ​​mọi người.

Thực hiện kéo git không mất nhiều thời gian như vậy.

git pull A
git pull B
git pull C

git không thay thế cho thời gian của con người và sự chú ý; đó là lý do tại sao nó được viết ngay từ đầu.

• Các công cụ GUI chưa hoàn thiện

Các công cụ gui có thể xử lý những thứ cơ bản khá tốt.

Các hoạt động nâng cao yêu cầu tư duy lập trình viên / mọt sách (ví dụ: tôi cảm thấy thoải mái khi làm việc từ dòng lệnh). Phải mất một chút thời gian để nắm bắt các khái niệm, nhưng nó không khó lắm.

• Sử dụng các công cụ dòng lệnh, thật dễ dàng để bắt kịp hợp nhất và xóa các thay đổi của người khác

Điều này sẽ không thành vấn đề trừ khi bạn có nhiều nhà phát triển không đủ năng lực có toàn quyền ghi vào "kho lưu trữ trung tâm".

Tuy nhiên, nếu bạn thiết lập quy trình làm việc của mình để chỉ một số người (nhà tích hợp) ghi vào kho lưu trữ "may mắn", đó sẽ không phải là vấn đề.

Git không giúp bạn dễ dàng vặn các hợp nhất.

Khi có xung đột hợp nhất, git sẽ đánh dấu rõ ràng các dòng xung đột để bạn biết thay đổi nào là của bạn và thay đổi nào không.

Cũng dễ dàng xóa mã của người khác bằng svn hoặc bất kỳ công cụ nào khác (không được phân bổ). Trên thực tế, nó dễ dàng hơn với những công cụ khác này vì bạn có xu hướng "ngồi thay đổi" trong một thời gian dài và tại một số thời điểm, việc hợp nhất có thể trở nên khó khăn khủng khiếp.

Và bởi vì những công cụ này không biết cách hợp nhất, bạn sẽ luôn phải hợp nhất mọi thứ theo cách thủ công. Ví dụ: ngay sau khi ai đó thực hiện cam kết đối với tệp bạn đang chỉnh sửa cục bộ, tệp đó sẽ được đánh dấu là xung đột cần được giải quyết theo cách thủ công; bây giờ đó là một cơn ác mộng bảo trì.

Với git, hầu hết thời gian sẽ không có bất kỳ xung đột hợp nhất nào vì git thực sự có thể hợp nhất. Trong trường hợp xung đột xảy ra, git sẽ đánh dấu rõ ràng các dòng cho bạn để bạn biết chính xác những thay đổi nào là của bạn và những thay đổi nào là của người khác.

Nếu ai đó xóa các thay đổi của người khác trong khi giải quyết xung đột hợp nhất, thì đó sẽ không phải là do nhầm lẫn: đó có thể là vì nó cần thiết cho việc giải quyết xung đột hoặc vì họ không biết mình đang làm gì.

• Nó không cung cấp các quyền đối với kho lưu trữ cho mỗi người dùng ngoài các đặc quyền chỉ đọc hoặc đọc ghi trên toàn cầu

• Nếu bạn có quyền đối với BẤT KỲ phần nào của kho lưu trữ, bạn có thể làm điều đó tương tự với MỌI phần của kho lưu trữ, vì vậy bạn không thể làm điều gì đó như tạo một nhánh theo dõi nhóm nhỏ trên máy chủ trung tâm mà những người khác không thể gây rối với.

• Khó có thể khuyến khích các quy trình làm việc khác với quy trình "bất cứ điều gì xảy ra" hoặc "nhà độc tài nhân từ", chứ đừng nói đến việc thực thi

Những vấn đề này sẽ biến mất khi bạn ngừng cố gắng sử dụng git như thể nó là một hệ thống tập trung.

• Không rõ liệu tốt hơn nên sử dụng một kho lưu trữ lớn duy nhất (cho phép mọi người xáo trộn mọi thứ) hay nhiều kho lưu trữ cho mỗi thành phần (khiến bạn đau đầu khi cố gắng đồng bộ hóa các phiên bản).

Gọi phán quyết.

Bạn có những loại dự án nào?

Ví dụ: phiên bản xy của dự án A có phụ thuộc vào chính xác phiên bản wz của dự án B sao cho mỗi khi bạn kiểm tra xy của dự án A bạn cũng phải kiểm tra wz của dự án B, nếu không nó sẽ không được xây dựng? Nếu vậy, tôi sẽ đặt cả dự án A và dự án B vào cùng một kho lưu trữ, vì chúng rõ ràng là hai phần của một dự án duy nhất.

Cách tốt nhất ở đây là sử dụng bộ não của bạn

• Với nhiều kho lưu trữ, cũng không rõ ràng làm thế nào để sao chép tất cả các nguồn mà người khác có bằng cách lấy từ kho lưu trữ trung tâm hoặc làm điều gì đó như tải mọi thứ vào lúc 4:30 chiều hôm qua.

Tôi không chắc bạn muốn nói gì.

Tôi thực sự khuyên bạn nên sử dụng http://code.google.com/p/gerrit/ cho công việc của doanh nghiệp. Nó cung cấp cho bạn quyền kiểm soát truy cập cộng với quy trình làm việc dựa trên đánh giá được tích hợp sẵn. Nó xác thực chống lại bất kỳ hệ thống LDAP nào. Bạn có thể kết nối nó với Hudson bằng http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin , cho phép bạn xây dựng và kiểm tra các thay đổi trong khi chúng vẫn đang được xem xét; đó là một thiết lập thực sự ấn tượng.

Nếu bạn quyết định sử dụng gerrit, tôi khuyên bạn nên cố gắng giữ một lịch sử tuyến tính, không phải một lịch sử nhánh như một số mã nguồn mở thích. Gerrit cụm từ này là "chỉ cho phép các thay đổi tua đi nhanh." Sau đó, bạn có thể sử dụng phân nhánh và hợp nhất theo cách bạn đã quen, cho các bản phát hành và những thứ khác.

Tôi trả lời câu hỏi này dựa trên kinh nghiệm của tôi với tư cách là quản lý nhà phát triển trong một công ty viễn thông lớn, nơi chúng tôi đã áp dụng Git vào năm 2010

Bạn có một loạt vấn đề khác nhau ở đây:

• quy trình làm việc
• công cụ khách hàng
• kiểm soát truy cập máy chủ và tích hợp

Quy trình làm việc

Chúng tôi đã áp dụng thành công chế độ kho lưu trữ trung tâm: những gì chúng tôi có trong dự án doanh nghiệp của mình (một cổng thông tin lớn cho cơ sở 5 triệu người dùng) là một kho lưu trữ trung tâm de-facto tạo ra các bản dựng chính thức sau đó được thực hiện qua quá trình phân phối (trong đó bao gồm ba cấp độ thử nghiệm và hai triển khai). Mỗi nhà phát triển quản lý repo của riêng mình và chúng tôi làm việc trên cơ sở chi nhánh cho mỗi tính năng.

Công cụ khách hàng

Hiện tại đã có một số lựa chọn, đây là khu vực rất đông đúc. Nhiều nhà phát triển đang sử dụng thành công IntelliJ Idea và Eclipse với plugin Git mà không cần bất kỳ thứ gì khác. Ngoài ra, hầu hết các nhà phát triển Linux đang sử dụng CLI git client mà không gặp bất kỳ vấn đề gì. Một số nhà phát triển Mac đang sử dụng thành công Tower Git . Xin lưu ý rằng không có ứng dụng khách nào trong số này có thể ngăn người dùng "gây rối" với kho lưu trữ trung tâm: cần có cơ chế kiểm soát phía máy chủ

Kiểm soát truy cập máy chủ và tích hợp

Nếu bạn muốn tránh các nhà phát triển "làm rối" kho lưu trữ Git của bạn, bạn cần chọn một giải pháp:

• hiển thị giao diện quản trị web tốt để thực hiện mọi thao tác
• cho phép bạn thực thi danh tính người dùng (sử dụng kho lưu trữ Git "trần" cực kỳ dễ dàng để cam kết thay mặt cho người khác)
• cung cấp cho bạn khả năng bảo mật chi tiết (ví dụ như bạn có thể ngăn FORCE-PUSH và đặt một số nhánh chỉ đọc cho một số nhà phát triển / nhóm)
• tích hợp với hệ thống xác thực công ty của bạn (tức là LDAP, Windows ActiveDirectory)
• cung cấp cho bạn kiểm tra đầy đủ (tuân thủ SOX đôi khi rất quan trọng đối với các công ty lớn)

Không có quá nhiều giải pháp phía máy chủ sẵn sàng sử dụng có thể giúp được việc này, tôi khuyên bạn nên kiểm tra một trong những giải pháp sau:

• Gitorious : nó có thể cung cấp bảo mật cấp độ truy cập cơ bản, nhưng nó thiếu kiểm soát quyền chi tiết ngoài hộp, vì vậy bạn có thể sẽ phải thực hiện một số mã hóa để xử lý các tình huống như quyền cấp chi nhánh. Nó cũng thiếu tích hợp với các cơ chế xác thực công ty hiện có
• GitHub Enterprise: được GitHub xuất bản gần đây, nó có tính năng GitHub trong công ty của bạn. Nó thiếu tuân thủ SOX và bảo mật chi tiết
• Gerrit : nó có thể cung cấp khả năng bảo mật cấp độ truy cập tốt và tích hợp với các hệ thống xác thực của công ty nhưng nó thiếu tuân thủ SOX và SSO. Ngoài ra, một số hoạt động chỉ có thể được thực hiện qua SSH thông qua CLI
• GitEnterprise : nó cung cấp quyền cấp chi nhánh, tuân thủ SSO, SOX, quản trị dựa trên web đầy đủ. Gần đây nó cũng đã được tích hợp với Gerrit, vì vậy nó cũng cung cấp cho bạn một phiên bản Gerrit đầy đủ

Hi vọng điêu nay co ich!

Có vẻ như vấn đề của bạn là bạn chưa quyết định hoặc thiết lập quy trình làm việc. Git đủ linh hoạt để sử dụng nó như svn hoặc bất kỳ VCS nào khác, nhưng nó mạnh đến mức nếu bạn không thiết lập các quy tắc mà mọi người phải tuân theo thì bạn sẽ chỉ kết thúc với một mớ hỗn độn. Tôi muốn giới thiệu quy trình làm việc của trung úy độc tài mà ai đó đã đề cập ở trên, nhưng kết hợp với mô hình phân nhánh được mô tả bởi Vincent Driessen . Để biết thêm thông tin, hãy xem các video trên màn hình này của David Bock và video này của Mark Derricutt .

Trên các công cụ , người dùng MacOS-X thấy GitX (http://gitx.frim.nl/) rất đơn giản và hiệu quả. Nhược điểm là không hỗ trợ các móc Git Client (những móc dưới $ GIT_ROOT / .git / hooks).

Nhìn chung, tôi thực sự quyết định chọn một công cụ hỗ trợ kiểm soát truy cập chi tiết trên: - các nhánh (để tách các nhánh phát hành ổn định với bảo mật nghiêm ngặt khỏi các nhánh chủ đề cần sự nhanh nhẹn và linh hoạt hơn) - thực thi danh tính (tác giả / người cam kết ). Đây là KEY cho SOX - hạn chế lệnh git - kiểm toán-đường mòn. Đây là KEY cho SOX

Những thứ tôi đã sử dụng thành công với các tính năng đó là:

1. Đánh giá mã Gerrit (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), sử dụng Gerrit 2.1.8 đằng sau hậu trường

PS Đừng đánh giá thấp việc tuân thủ SOX và CMMI : nhiều khi có một số lựa chọn giới hạn mà bạn có được quy định bởi Chính sách Doanh nghiệp của Công ty về Bảo mật.

Hi vọng điêu nay co ich.

Luca.

Gần đây chúng tôi đã chuyển từ svn sang git. Vì git-daemon không hoạt động với msysgit nên chúng tôi đã chọn cách tiếp cận kho lưu trữ trung tâm trên máy chủ Linux có gitosis.

Để loại bỏ khả năng làm hỏng master, chúng tôi chỉ cần xóa nó. Thay vào đó, chúng tôi chuẩn bị tất cả các bản phát hành bằng cách hợp nhất các nhánh được chọn để thử nghiệm và gắn thẻ hợp nhất. Nếu nó vượt qua các bài kiểm tra, cam kết sẽ được gắn thẻ với một phiên bản và được đưa vào sản xuất.

Để xử lý điều này, chúng tôi có một vai trò luân phiên của người quản lý phát hành. Người quản lý phát hành có trách nhiệm xem xét từng nhánh trước khi nó sẵn sàng để kiểm tra. Sau đó, khi chủ sở hữu sản phẩm quyết định đã đến lúc nhóm các nhánh được phê duyệt lại với nhau cho một bản phát hành thử nghiệm mới, người quản lý phát hành thực hiện hợp nhất.

Chúng tôi cũng có vai trò luân phiên của bàn trợ giúp cấp 2 và ít nhất đối với chúng tôi, khối lượng công việc đủ để có thể có cả hai vai trò cùng một lúc.

Vì lợi ích của việc không có chủ, không thể thêm bất kỳ mã nào vào dự án mà không thông qua trình quản lý phát hành, vì vậy chúng tôi đã trực tiếp phát hiện ra bao nhiêu mã đã được âm thầm thêm vào dự án trước đó.

Quá trình xem xét bắt đầu với việc chủ sở hữu chi nhánh đưa ra bảng đánh giá khác biệt và dán một tấm bảng màu xanh lục lên bảng trắng với tên chi nhánh (chúng tôi có quy trình làm việc dựa trên Kanban) trong "để xem xét" hoặc nếu đó là một phần của người dùng đã hoàn thành câu chuyện, chuyển toàn bộ thẻ câu chuyện đến "để xem xét" và đặt postit trên đó. Người quản lý phát hành lại là người chuyển các thẻ và chuyển thẻ sang trạng thái "sẵn sàng để thử nghiệm" và sau đó chủ sở hữu sản phẩm có thể chọn những thẻ nào sẽ nâng cấp trong bản phát hành thử nghiệm tiếp theo.

Khi thực hiện hợp nhất, trình quản lý phát hành cũng đảm bảo rằng cam kết hợp nhất có một thông báo cam kết hợp lý có thể được sử dụng trong bảng thay đổi cho chủ sở hữu sản phẩm.

Khi một bản phát hành đã được đưa vào sản xuất, thẻ được sử dụng làm cơ sở mới cho các chi nhánh và tất cả các chi nhánh hiện có sẽ được hợp nhất với nó. Bằng cách này, tất cả các nhánh đều có cha mẹ chung giúp dễ dàng xử lý các hợp nhất.

Tôi sẽ thêm vào một bài đăng "bạn đã xem xét".

Một trong những điều tuyệt vời về Bazaar là tính linh hoạt của nó. Đây là nơi nó đánh bại tất cả các hệ thống phân tán khác. Bạn có thể vận hành Bazaar ở chế độ tập trung, chế độ phân tán hoặc lấy cái này: cả hai (nghĩa là các nhà phát triển có thể chọn mô hình mà họ cảm thấy thoải mái hoặc mô hình nào hoạt động tốt nhất cho nhóm làm việc của họ). Bạn cũng có thể ngắt kết nối kho lưu trữ tập trung khi đang di chuyển và kết nối lại khi bạn quay lại.

Trên hết, tài liệu tuyệt vời và thứ gì đó sẽ khiến doanh nghiệp của bạn hài lòng: hỗ trợ thương mại có sẵn.

• Cài đặt một giao diện web tốt, như Github FI
• Bám sát một mô hình tương đối tập trung (ban đầu) để giữ mọi người thoải mái.
• Chạy bản dựng Tích hợp liên tục cho mọi nhánh được chia sẻ.
• Chia sẻ một tập hợp tốt các tùy chọn cấu hình git toàn cầu.
• Tích hợp git vào shell của bạn, với quá trình hoàn thành bash và lời nhắc với nhánh hiện tại.
• Hãy thử Tích hợp Git của IntelliJ làm công cụ hợp nhất.
• Hãy chắc chắn rằng bạn .gitignore khi thích hợp.

Về điểm 3 & 4 (quyền cho mỗi người dùng, mỗi phần, mỗi nhánh), hãy xem gitolite (được đề cập trong sách Pro Git: http://progit.org/book/ch4-8.html ).

Chính trị hay không, Git cũng là một lựa chọn tốt của DCVS. Giống như bất kỳ công cụ mạnh mẽ nào, bạn nên dành một chút thời gian trước để hiểu cách công cụ được thiết kế để hoạt động và, về phần cuối, tôi thực sự khuyên bạn nên sử dụng cuốn sách Pro Git. Một vài giờ dành cho nó sẽ giúp bạn đỡ thất vọng về lâu dài.

GUI: Hiện tại, TortoiseGit v1.7.6 sẽ ổn cho hầu hết các hoạt động hàng ngày. Log, commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodule, v.v. Hỗ trợ x64 nguyên bản

Để sử dụng git hiệu quả trong một nhóm phát triển có nhiều nhà phát triển, cần phải có một hệ thống CI xây dựng và kiểm tra liên tục. Jenkins cung cấp một phương tiện như vậy và tôi rất khuyến khích điều đó. Phần tích hợp phải được thực hiện bất kể điều gì và sẽ rẻ hơn rất nhiều nếu làm điều đó sớm hơn và thường xuyên hơn.

Phù hợp hơn để phát triển cộng tác hơn là gitosis hoặc gitolite nhưng mã nguồn mở là Gitorious . Đó là một ứng dụng Ruby on Rails xử lý việc quản lý kho lưu trữ và hợp nhất. Nó sẽ giải quyết nhiều vấn đề của bạn.

Git cho phép tạo các nhánh riêng. Điều này khuyến khích các nhà phát triển cam kết thường xuyên để chia nhỏ các sửa đổi thành các cam kết nhỏ. Khi nhà phát triển sẵn sàng xuất bản các thay đổi của mình, anh ta sẽ đẩy lên máy chủ trung tâm. Anh ta có thể sử dụng các tập lệnh cam kết trước để xác minh mã của mình nếu cần.

NXP đang quản lý Git và Subversion với một nền tảng chung (ở quy mô doanh nghiệp), tích hợp phát triển thiết bị di động Android với các dự án phần mềm truyền thống: http://www.youtube.com/watch?v=QX5wn0igv7Q