Tôi đã tìm kiếm và không thể tìm thấy bất kỳ lý do kinh doanh nào tại sao các hệ thống git / mercurial / bazzr tốt hơn các hệ thống tập trung (lật đổ, lực lượng).

Nếu bạn đang cố bán DVCS cho một người không có kỹ thuật, bạn sẽ cung cấp những lý lẽ nào cho lợi nhuận tăng DVCS .

Tôi sẽ sớm giới thiệu git cho người quản lý của mình, sẽ mất một thời gian để chuyển đổi kho lưu trữ lật đổ và một số chi phí trong việc mua giấy phép smartgit.

Chỉnh sửa Tôi đã cố gắng biến câu hỏi này thành một cuộc thảo luận chung về tập trung so với phi tập trung, nhưng chắc chắn nó đã biến thành git vs lật đổ. Chắc chắn có những hệ thống tập trung tốt hơn lật đổ.

Hmm, đã từng là một người quản lý, tôi có hai phản ứng "giật đầu gối" ngay lập tức:

• Nếu bạn không có lý do chính đáng tại sao bạn lại ném git ngoài việc hợp thời trang?
• Tương tự, Subversion thất bại như thế nào mà bạn cần một sự thay thế?

Thật ra tôi không phải là người tiêu cực - tôi nghĩ có lẽ có một trường hợp được tạo ra (phụ thuộc vào hoàn cảnh) nhưng nếu trường hợp đơn giản là git đó "tốt" hơn lật đổ thì bạn không thực sự có.

Bạn cũng cần có khả năng liệt kê những nhược điểm - bạn đã xác định được chi phí di chuyển và công cụ lại - còn vấn đề gì nữa không? ví dụ: Điều gì xảy ra với kho lưu trữ đẹp, trung tâm, được sao lưu của bạn? Làm thế nào để bạn tích hợp với máy chủ xây dựng tích hợp liên tục của bạn (nếu bạn không có, hãy quên git và sắp xếp nó trước). Oh bảo mật và theo dõi - SVN chạy với thông tin đăng nhập và quyền thích hợp.

Theo suy nghĩ của tôi, các lợi ích là linh hoạt, hợp nhất tốt hơn, khả năng thực hiện các cam kết cục bộ mà không phá vỡ các bản dựng và như vậy. Những nhược điểm là thiếu kiểm soát và tính linh hoạt tương tự.

Có thể là tất cả những gì bạn muốn làm là chạy git cục bộ vào máy của bạn dưới dạng máy khách lật đổ "tốt hơn" (tôi đang xem xét việc này bằng cách sử dụng đồng bóng).

Hmm, có lẽ toàn bộ câu trả lời này là một nhận xét thực sự? Bạn cần đưa ra trường hợp của bạn ở đây (trong câu hỏi) để git over lật đổ (trong môi trường của bạn) để xem liệu chúng tôi có thể giúp bạn xác định trường hợp kinh doanh hay không.

FWIW, tôi biết rằng người ta có thể dễ dàng chỉ định một thể hiện cụ thể của kho lưu trữ thành nguồn trung kế / nguồn tham chiếu và hơn nữa đó là cách một dây vào máy chủ xây dựng của một người - sự khác biệt là với DVCS có nhiều quyết định quản trị hơn một cái gì đó vốn có trong kiến ​​trúc.

Tôi có thể nói rằng việc phân nhánh và sáp nhập nhanh chóng và không đau sẽ cho phép các nhà phát triển làm việc hiệu quả hơn với mã của họ, vì mọi tính năng mới có thể được phân nhánh, sau đó được hợp nhất. Làm cho quá trình phát triển trôi qua suôn sẻ hơn nhiều. Ngoài ra, bản chất phân tán, sẽ cho phép mọi nhà phát triển có toàn bộ bản sao của mã, do đó, không có lo lắng về lỗi máy chủ tập trung lấy hết mã của bạn. Có lẽ có nhiều lý do hơn, tuy nhiên, hai lý do đó là lý do hàng đầu của tôi khi sử dụng Git.

Tôi giả sử bạn có thể tạo ra một trường hợp để kiểm soát phiên bản tăng năng suất (và do đó lợi nhuận) ngay cả khi nhà phát triển đang làm việc một mình.

Một DVCS tốt nhận ra những lợi ích năng suất tương tự ngay cả khi làm việc trong nhóm - mỗi nhà phát triển có thể nhận được tất cả lợi ích khi làm việc với kiểm soát phiên bản - họ có thể thực hiện các cam kết thường xuyên, quay lại, chơi xung quanh với mọi thứ, v.v. - mà không phải lo lắng về xung đột với những gì các nhà phát triển khác đang làm cho đến khi họ sẵn sàng đẩy những thay đổi của họ ra.

• Chi nhánh mỗi lỗi
• Giảm độ trễ trên diffs của bạn.
• Có thể rất nhanh chóng điều hướng tùy ý thông qua lịch sử của một chi nhánh khi bạn xem xét ngang hàng.
• Bạn vẫn có quyền truy cập vào toàn bộ lịch sử của mình khi bạn không có quyền truy cập vào máy chủ tập trung: bạn không ở văn phòng, điện bị cúp nhưng pin của máy tính xách tay vẫn hoạt động, ...

Những điều này cho phép bạn làm việc hiệu quả hơn, cả solo và trong một nhóm. Làm việc hiệu quả hơn = thời gian phát triển nhanh hơn = thời gian tiếp thị nhanh hơn = lợi nhuận.

Xin lỗi vì đã liên kết với blog của riêng tôi, nhưng tôi đã viết bài về chủ đề này:

• Tại sao Mẹo nên luôn luôn biên dịch
• Tại sao DVCS cung cấp kiểm soát trung tâm tốt hơn
• Tại sao phân nhánh tốt hơn với DVCS
• Tại sao các mô hình phân nhánh có thể không hoạt động tốt trên CVCS của bạn .

Vui lòng downvote nếu bạn không thấy chúng có liên quan.

Tóm lại, DVCS làm cho các mô hình phân nhánh dễ dàng có thể giữ cho các nhóm lớn các nhà phát triển không bước lên từng ngón chân, điều này làm tăng cả năng suất và chất lượng xây dựng hàng ngày của bạn. Phần cộng tác lộn xộn của kiểm soát phiên bản có thể được thực hiện trong các repos cục bộ, để lại kho lưu trữ trung tâm của bạn sạch hơn và có chất lượng cao hơn. Ngoài ra, các quyết định về thời điểm phân nhánh có thể có ảnh hưởng lớn đến hiệu quả, ví dụ nếu một bộ phận sẵn sàng bắt đầu công việc trên 2.0 khi 1.0 vẫn đang được những người khác dọn sạch. DVCS cho phép những quyết định đó được đưa ra ở cấp địa phương thay vì theo ủy ban.

Đối số của tôi cho DVCS là:

• Sự phân nhánh không bị phá vỡ, điều này dẫn đến ít ma sát hơn trong việc phát triển các tính năng và giữ cho các sản phẩm hiện có được vá. Ma sát tốn tiền kịp thời.

• Chuyển sang một hệ thống hiện đại thu hút tốt hơn các nhà phát triển tiên tiến, điều này sẽ dẫn đến văn hóa các sản phẩm tốt hơn, cho phép doanh nghiệp bán được nhiều sản phẩm hơn.

• Các cam kết phi mạng nhanh hơn , cho phép các nhà phát triển cam kết thường xuyên, dẫn đến phát hiện và phân tích lỗi chi tiết.

Về cơ bản, đó là về việc giảm ma sát. Có một thuật ngữ cho việc này: Muda . Càng nhiều ma sát, càng đau đớn khi làm mọi việc. Càng nhiều nỗi đau, càng ít được thực hiện, lợi nhuận càng ít.

Tôi xin lỗi nếu tôi hiểu, nhưng cho phép tôi đặt trường hợp kinh doanh không có điều khoản không chắc chắn:

SVN làm cho cuộc sống của các nhà phát triển khốn khổ . Và điều đó làm cho một doanh nghiệp phần mềm khốn khổ.

... theo những cách mà nhiều người sẽ không nhận ra cho đến khi họ bắt đầu sử dụng DVCS. Đây là trường hợp kinh doanh quan trọng nhất có thể được thực hiện . Tại sao? Chà, so với chi phí tìm kiếm và giữ chân các nhà phát triển giỏi, chi phí chuyển sang DVCS gần như không tồn tại .

Hãy xem xét những điều sau đây:

• Tất cả trừ các hoạt động tầm thường nhất trong SVN (và hầu hết các CVCS khác) đều yêu cầu truy cập mạng. Trong hầu hết các DVCSes, truy cập mạng chỉ xảy ra khi bạn làm một pushhoặc pullphẫu thuật. Điều này có nghĩa là các lệnh không tầm thường là chậm . Bạn làm gì khi một lệnh được thực hiện mãi mãi? Cá nhân tôi duyệt các lập trình viên. Tin tức hoặc tin tặc trong khi chờ đợi. Nói một cách đơn giản, DVCS cho phép các lập trình viên tập trung vào làm những gì họ yêu thích: viết phần mềm của công ty .
• SVN có hỗ trợ phân nhánh theo cách tương tự như các nhà tù có hỗ trợ thả xà phòng của bạn khi tắm: bạn có thể làm điều đó, nhưng khi bạn làm bạn bị đụ. Do đó, SVN buộc các nhà phát triển của bạn phải liên tục chiến đấu với nhau để thực hiện các thay đổi .
• Khi SVN ngừng hoạt động, nó sẽ ngừng hoạt động. Nó trở nên cực kỳ khó khăn cho các nhà phát triển để thực hiện công việc của họ nếu họ có thể làm tất cả. Do đó, SVN buộc các nhà phát triển của bạn phải phụ thuộc vào cơ sở hạ tầng của bạn không có lỗi 100% .
• Những ngày này, git đang nhanh chóng đạt được tư duy trong khi SVN đang nhanh chóng mất nó. Nếu không có lợi ích gì khi sử dụng DVCS qua SVN, tại sao cộng đồng lập trình lại thay đổi nhanh nhất có thể?

Tất cả số tiền này để làm gì? Tôi vẫn chưa gặp một nhà phát triển đã cho DVCS một thử nghiệm trung thực mà sau đó thích SVN hơn. Nếu tôi có thể đưa ra một tuyên bố khó chịu, táo bạo hơn, SVN là một "điều ác cần thiết" mà các nhà phát triển buộc mình phải sử dụng. Git là một công cụ giúp các nhà phát triển làm việc hiệu quả hơn và hạnh phúc hơn .

(Tôi nên chỉ ra rằng các tuyên bố được in đậm là những tuyên bố cụ thể mà bạn nên tập trung vào. Phần còn lại của chúng chỉ cung cấp ngữ cảnh.)

Điều duy nhất tôi có thể nghĩ là git hoạt động mà không cần kết nối mạng. Mọi thứ khác thậm chí thường khó bán cho người dùng kỹ thuật sử dụng chìm hoặc lực lượng trong một thời gian khá lâu.

Sự khác biệt cho thấy khi có sự cố

Chúng tôi đã chuyển sang git 6 tháng trước sau khi chuyển kho lưu trữ cũ trong thập kỷ của chúng tôi.

Cho đến nay tôi đã tìm thấy những điều sau đây, sau một chút thử nghiệm:

• phân nhánh và sáp nhập gần như không đau. Điều này làm cho nó dễ dàng hơn nhiều để làm việc trên các tính năng riêng biệt và sửa lỗi mà không cần bước lên các ngón chân khác. Nó cũng làm cho nó rất dễ dàng để áp dụng một lỗi nhất định ở một nơi khác.

• mạnh mẽ hơn theo thiết kế - bạn không phụ thuộc 100% vào một máy chủ trung tâm có sẵn và nếu không, bạn có thể sử dụng tạm thời bất kỳ bản sao nào để thay thế. Điều này loại bỏ một điểm quan trọng của sự thất bại - nếu máy chủ SVN ngừng hoạt động vì bất kỳ lý do gì, không ai có thể thực hiện công việc của SVN. Nếu kho lưu trữ git trung tâm bị hỏng vì bất kỳ lý do gì, bạn vẫn có thể làm việc và đẩy / kéo cục bộ để đảm bảo rằng các cam kết được sao chép. Bạn thậm chí có thể có nhiều kho lưu trữ ngoài trang web cho chính xác mục đích này.

• tương tác kho lưu trữ được đơn giản hóa. Đối với CVS, về cơ bản bạn cần truy cập mọi lúc mọi nơi bạn cần một số thông tin. Đối với git, toàn bộ kho lưu trữ có sẵn tại địa phương cho phép nhiều thứ đi nhanh hơn.

Vì vậy, lợi ích không nhiều trong thói quen hàng ngày, nhưng rất rõ ràng thời điểm bạn có một cái gì đó không hoạt động chính xác!

Do đó, tôi đề nghị rằng đối với trường hợp kinh doanh của bạn, hãy nhìn vào những gì bạn sẽ làm khi thảm họa xảy ra ...

Sự dễ dàng của việc phân nhánh và hợp nhất là lý do cụ thể nhất, nhưng để thuyết phục ai đó bạn sẽ phải cho họ một ví dụ cụ thể về cách cải thiện mọi thứ.

Giả sử bạn có một vài lập trình viên làm việc để cải thiện hiệu suất cho một ứng dụng và họ đang trong giai đoạn thử nghiệm và không biết liệu mã họ đang viết có bao giờ là một phần của nhánh chính / thân không. Tuy nhiên, họ cần thường xuyên chia sẻ mã với nhau và thử những ý tưởng có thể là ngõ cụt. Làm thế nào để bạn quản lý phân nhánh và sáp nhập thường xuyên như vậy trong lật đổ? Câu trả lời ngắn gọn là bạn không. Với một dvcs, điều đó thực sự dễ dàng và các lập trình viên có thể nhanh chóng thử các ý tưởng mới trong các nhánh và chia sẻ với những người khác trước khi quyết định liệu ý tưởng đó có tồn tại không.

Trường hợp kinh doanh cho việc bỏ SubVersion là hỗ trợ phân nhánh là một rào cản đối với việc ổn định và bảo trì sản phẩm. Nếu bạn cần phát hành một sản phẩm và sau đó tiếp tục phát triển, bạn cần một chi nhánh. Với lật đổ, các nhà phát triển sẽ không sử dụng phân nhánh đúng cách và do đó bạn sẽ không tiếp tục phát triển trên tunk và đảm bảo rằng các bản sửa lỗi thực sự cũng làm cho nó trên cả thân cây và nhánh.