Một ví dụ điển hình của người phù hợp với mô tả đó có thể là người quản lý dự án.

Tôi đã được ông chủ của tôi hỏi vào một ngày khác, "điều Github này là gì và tại sao nó quan trọng?" Anh ta có một số dự án độc quyền nên anh ta sẽ cần lưu trữ riêng và tôi thấy mình phải vật lộn để giải thích vượt quá thông thường: Các VCS làm cho việc cộng tác trở nên tầm thường, cung cấp lịch sử và "sao lưu" tất cả dữ liệu của bạn và cho phép bạn ghi lại các thay đổi nguyên tử trong cơ sở mã . Trong tâm trí tôi đã suy nghĩ, "gần như là bạn phải sử dụng DRVS để thực sự hiểu nó có lợi như thế nào".

Cuối cùng tôi đã chỉ cho anh ấy đến BitBucket vì họ cung cấp cho bạn các kho riêng tư không giới hạn (tôi thậm chí phải giải thích kho lưu trữ là gì).

Có ai có một ví dụ cụ thể thực sự tốt về cách một VCS đã cứu cái mông của họ hoặc làm cho cuộc sống dễ dàng hơn, v.v. - về cơ bản, làm thế nào bạn bán DVSC cho một người không quen với lập trình, nhưng không phải là lập trình viên chuyên nghiệp?

Kiểm soát phiên bản rất tốt cho (ít nhất) ba bốn điều: sao lưu, chia sẻ mã giữa các nhà phát triển, tìm + sửa lỗi và theo dõi tiến trình.

1. Sao lưu . Nếu không có gì khác, đó là sao lưu trên steroid. Bạn có toàn bộ lịch sử phát triển, mỗi cam kết là một ảnh chụp nhanh toàn bộ mã của bạn với một id (số sửa đổi), mô tả, dấu thời gian, thông tin người dùng. Và thật đơn giản để so sánh các tập tin giữa các phiên bản. Nếu không có gì khác, nó nhanh hơn một bản sao lưu đơn giản (chỉ thay đổi tệp được gửi và lưu trữ) và chứa siêu dữ liệu hữu ích hơn nhiều. Tại sao phải phát minh lại điều này?

2. Chia sẻ mã giữa các nhà phát triển . Nếu bạn có ít nhất hai nhà phát triển làm việc trên cùng một sản phẩm cùng một lúc, tôi không thấy cách nào khác để chia sẻ thay đổi mã một cách đáng tin cậy và nhất quán và hợp nhất chúng. Gửi zips bằng thư?

3. Tìm và sửa lỗi . Khi khách hàng của bạn báo cáo lỗi cho một phiên bản sản phẩm cụ thể, bạn có thể nhanh chóng nhận được ảnh chụp nhanh nguồn thực tế để sao chép và sửa lỗi. Thật khó để tái tạo lỗi nếu nguồn của bạn khác với khách hàng. Bạn có yêu cầu họ gửi tệp thực thi để bạn có thể tháo rời nó không? Hơn nữa, nếu bạn gặp vấn đề trong việc xác định nguyên nhân gây ra lỗi, bạn có thể sử dụng VCS để xác định chính xác bản sửa đổi nơi nó được giới thiệu.

4. Theo dõi tiến độ . Khi bạn cam kết công việc của mình trong ảnh chụp nhanh, nó cho phép bạn (và người quản lý của bạn) theo dõi tiến trình triển khai tính năng và trạng thái của các lỗi mở. Các hệ thống VC cũng dễ dàng được tích hợp với các hệ thống theo dõi và hệ thống tích hợp liên tục . Gần như không thể giữ mức chất lượng cho bất kỳ thứ gì khác ngoài dự án sở thích, trừ khi bạn có VCS.

Khi bạn đã đồng ý rằng không nên thực hiện phát triển phần mềm nào ngoài VCS (tôi sẽ không bỏ lỡ nó ngay cả đối với dự án sở thích), sau đó bạn có thể thảo luận về các tính năng của DVCS (hơi phức tạp hơn) (phần sau đây được sao chép một cách trắng trợn Wikipedia ):

• Mỗi người dùng có một bản sao cục bộ của kho lưu trữ (và hiệu quả là một bản sao lưu)
• Cho phép người dùng làm việc năng suất ngay cả khi không kết nối với mạng
• Làm cho hầu hết các hoạt động nhanh hơn nhiều vì không có mạng liên quan
• Cho phép tham gia vào các dự án mà không cần sự cho phép từ chính quyền dự án
• Cho phép công việc riêng tư, vì vậy người dùng có thể sử dụng hệ thống kiểm soát sửa đổi của họ ngay cả đối với các bản nháp đầu tiên mà họ không muốn xuất bản
• Tránh dựa vào một máy vật lý duy nhất là một điểm thất bại duy nhất

"Bạn đã bao giờ thấy nút 'hoàn tác' hữu ích chưa? Ồ, vậy bạn có đồng ý chúng ta nên sử dụng điều khiển phiên bản không?"

Khi tôi bắt đầu sử dụng kiểm soát phiên bản, tính năng chính tôi quan tâm là khả năng 'hoàn tác' các lỗi của mình và quay lại phiên bản trước. Mọi người có thể đánh giá cao một nút hoàn tác. Kiểm soát phiên bản được cấp có thể làm nhiều hơn nữa.

Bắt đầu với những điều cơ bản:

Đầu tiên, một VCS bảo vệ các nhà phát triển khỏi chính họ và khỏi nhau - nếu nó không phục vụ mục đích nào khác ngoài việc cho phép hai hoặc nhiều nhà phát triển làm việc trên cùng một cơ sở mã tương đối an toàn thì nó sẽ có giá trị rất lớn (và tôi đã ở trong một nhóm nơi trước đó ngày làm việc đã bị ghi đè bởi một chút sao chép bất cẩn).

Thứ hai, nó cung cấp một dấu vết kiểm toán - một lịch sử - bạn có thể quay lại và xem ai đã thay đổi cái gì và khi nào và bạn có thể quay lại và lấy mã mà bạn đã xóa vì nó không còn cần thiết hoặc phù hợp khi nó cần thiết sau đó tất cả.

Thứ ba, nó cung cấp cho bạn một điểm tham chiếu - nguồn chính xác là mã cam kết (trong thế giới thực, nó phức tạp hơn một chút, đặc biệt là với DVCS, nhưng vì lợi ích của cuộc thảo luận này, nó đủ gần). Nếu bạn có kho lưu trữ được sao lưu đúng cách, thì bạn nên bảo vệ tài sản của công ty.

Ba điều đó phải là "nó" để bán VCS - nếu người quản lý không thể thấy đủ giá trị trong thời gian trên để tìm người quản lý khác.

Sau khi bạn đã bán VCS (cuối cùng, chỉ sử dụng cho các nhóm phát triển có số lượng nhà phát triển lớn hơn 0), câu hỏi tại sao DVCS hơn, nói, SVN hoặc TFS và câu hỏi tiếp theo về việc có nên hoạt động không tại nhà hoặc sử dụng dịch vụ lưu trữ như Kiln hoặc Bitbucket hoặc Github (hoạt động riêng tư nếu bạn trả tiền) khá sâu sắc và phụ thuộc vào ngữ cảnh nhiều hơn.

VCS

Chỉ cần giải thích các khái niệm về sao lưu . Sao lưu cho phép bạn thấy những gì bạn đã làm việc tại một thời điểm nhất định. Cho biết trước khi các lập trình viên của VCS sử dụng sao chép toàn bộ dự án của họ một cách bắt buộc, nói chung là để lưu từng bản phát hành tốt và ổn định mà họ có, vì vậy khi mọi thứ trở nên tồi tệ, họ có một điểm tham khảo tốt khi mọi thứ hoạt động, so sánh chúng với những thứ mới nhất và xem họ hoặc ai đó đã làm rối và sửa nó dễ dàng hơn bằng cách chỉ nhìn vào sự khác biệt thay vì toàn bộ hai bản sao lưu của dự án.

Tóm lại : Các VCS cho phép bạn lưu các bản sao lưu công việc của bạn và cung cấp cho bạn khả năng chỉ nhìn thấy sự khác biệt giữa các bản sao lưu.

DVCS

Đối với kiểm soát phiên bản phân tán, hãy giải thích cách kiểm soát phiên bản điển hình được sử dụng để cần máy chủ và kết nối internet và mọi người đều cảm thấy mệt mỏi vì điều đó chậm hơn và mọi người đều làm việc trên một bản sao lưu, nếu một điều đó làm rối tung dự án cho mọi người, Vì vậy, với điều khiển phiên bản phân tán, mọi người có thể tự làm việc sao lưu trong máy của mình mà không cần kết nối internet và mọi người đều vui vì không ai làm phiền với bản sao lưu của họ trong khi họ làm việc và họ có thể lo lắng về việc chia sẻ công việc của mình sau khi hoàn thành.

Một điều tốt nữa là không giống như một VCS tập trung, nơi chỉ có một bản sao lưu, nếu máy có bản sao lưu bắt lửa thì vẫn có những bản sao lưu hoàn chỉnh khác để đi xung quanh (ít nhất là một bản cho mỗi nhà phát triển).

Tóm lại : Các DVCS cho phép bạn làm việc trong bản sao lưu của riêng bạn mà không cần mọi người phải nhồi nhét trong một máy chủ làm phiền lẫn nhau và để bạn lo lắng về những thay đổi của người khác sau khi bạn hoàn thành công việc của mình. Ngoài ra, không có gì xảy ra nếu máy lưu trữ chính bắt lửa .

Tôi làm việc chủ yếu với các kỹ sư (không phải nhà phát triển, nhưng họ viết mã)

Điểm chính, khi tôi giải thích cho họ về kiểm soát phiên bản, là khả năng hoàn tác và quản lý mã / tài liệu của bạn / bất cứ điều gì và đơn giản hóa việc cộng tác với các nhà phát triển / nhà văn khác / v.v ...

Đó là một điểm bán hàng tốt - và là lý do chính để tôi sử dụng VCS cho tất cả các công việc của mình, cũng là những lợi thế khác: có một lịch sử, một repo có thể dễ dàng sao lưu ...

Hầu hết trong số họ thích ý tưởng và thấy nó khá hữu ích, áp dụng nó cho các dự án của họ (đặc biệt nếu họ liên quan đến việc cộng tác với các kỹ sư khác).

Khi cố gắng thuyết phục bất cứ ai về bất cứ điều gì, bạn luôn cần cố gắng đến với nó từ quan điểm của họ.

Người quản lý dự án của bạn có một mục tiêu đơn giản - hoàn thành các dự án đúng thời gian và ngân sách.

Nếu bạn hiện không sử dụng kiểm soát phiên bản, thì nhóm phát triển của bạn sẽ giải quyết các vấn đề mà kiểm soát phiên bản giải quyết bằng tay. Tất cả những vấn đề đó đã được liệt kê tốt bằng các câu trả lời khác, vì vậy tôi sẽ không giải quyết chúng ở đây.

Những gì bạn cần làm là giải thích cho người quản lý dự án của bạn rằng nhóm đang dành Xsố giờ mỗi tuần để giải quyết thủ công các vấn đề mà GIT có thể giải quyết tự động, hoặc, nói, 0.1 * Xsố giờ của nhà phát triển.

Đừng tiếp cận nó bằng lý do GIT sẽ giúp cuộc sống của bạn dễ dàng hơn hoặc cuộc sống của các nhà phát triển đồng nghiệp của bạn dễ dàng hơn, hãy tiếp cận nó từ quan điểm rằng GIT sẽ vận chuyển phần mềm nhanh hơn và rẻ hơn.

Tôi thích mô tả của @ Nút840 về nó như một nút hoàn tác cho cơ sở mã. Nó cũng có thể giúp so sánh nó với phiên bản (ít gây khó chịu hơn) của tính năng "Theo dõi thay đổi" của Word hoặc InDesign. Theo kinh nghiệm của tôi, nó chắc chắn sẽ giảm nhu cầu một người đi khắp nơi nói với những người khác không được chạm vào các tệp X, Y và Z trong vài giờ tới, rất tiện cho việc hoàn thành công việc.

Tôi cũng đã tìm thấy thông tin phiên bản chi tiết cực kỳ hữu ích để sửa / khắc phục các lỗi. Tôi bỏ số phiên bản SVN (thông qua thuộc tính $ Id) trong gần như mọi tệp dữ liệu tôi tạo. Theo cách đó, nếu (khi nào?) Một lỗi được tìm thấy, việc xác định các tệp có vấn đề tiềm ẩn và tái tạo chúng hoặc có mã khác bù cho lỗi đó là chuyện nhỏ.

Nếu bạn không sử dụng kiểm soát phiên bản, làm thế nào để bạn biết cách xây dựng lại môi trường sản xuất của mình?

1 người khác nhau (người kiểm tra, nhà phát triển) sẽ tìm kiếm cùng một thông tin ở những nơi khác nhau

dẫn đến dữ liệu DUPLICATE không đồng bộ.
Kiểm soát phiên bản là cách dễ nhất để loại bỏ dữ liệu trùng lặp.

2 Nếu bạn sử dụng kiểm soát phiên bản, thật dễ dàng để đảm bảo môi trường sản xuất khớp với kiểm soát phiên bản.

Điều này giúp dễ dàng phát hiện xem sự cố có phải do bản dựng xấu (prod không khớp với kiểm soát phiên bản) hay lỗi thiết kế hoặc mã hóa (prod không khớp với kiểm soát phiên bản).

Kiểm soát phiên bản giúp dễ dàng gán số phát hành cho từng môi trường thử nghiệm và bạn tự nhiên mong muốn sản xuất có số phát hành thấp hơn kiểm tra hoặc phát triển và kiểm tra có số phát hành thấp hơn phát triển. Nếu đây không phải là trường hợp, một số phần của mã chưa được kiểm tra đúng cách ..

Ngoài ra, nếu bạn phát hành phần mềm, tính năng sau đây của VCS là khá cần thiết: Giả sử khách hàng của bạn tìm thấy lỗi. Sự phát triển hiện tại của phần mềm có lẽ ở một trạng thái rất khác so với phiên bản mà khách hàng có. Có thể lỗi đã được sửa ngay bây giờ, có thể là không, nhưng trong mọi trường hợp, phần mềm hiện tại không ở trạng thái mà bạn có thể gửi nó cho khách hàng.

Một VCS làm cho nó trở nên tầm thường để quay trở lại phiên bản đã được chuyển đến khách hàng, sửa lỗi mà anh ta yêu cầu, xây dựng nó và gửi cho anh ta một phiên bản sửa đổi. Tất cả điều này mà không làm phiền sự phát triển hiện tại, mà không phải gửi cho anh ta một phiên bản với các tính năng chưa hoàn thành / không ổn định hoặc các lỗi bổ sung được giới thiệu do sự phát triển chưa hoàn thành mới.

Ngoài ra, một VCS giúp bạn dễ dàng chuyển bản sửa lỗi này trở lại nhánh phát triển mới nếu lỗi vẫn còn tồn tại ở đó.

Bằng kỷ luật mạnh mẽ, bạn có thể quản lý việc này mà không cần VCS cho một nhóm rất nhỏ, nhưng sử dụng một nhóm sẽ giúp bạn tiết kiệm thời gian và tiền cuối cùng. Nhiều khả năng nó cũng sẽ giúp bạn giữ khách hàng của bạn.

Nếu công ty của bạn có nhiều hơn hai người, thì bạn có thể có một tài liệu từ hoặc tài liệu excel nằm ở đâu đó được chỉnh sửa bởi nhiều người. Và đôi khi những người đó tạo ra các bản sao địa phương, để thực hiện một chuyến công tác, vv Hoặc tài liệu được gửi qua email sau mỗi thay đổi.

Nếu bạn có một tệp như vậy, thì một số sửa đổi của một số người đã bị mất trong quá khứ hoặc sẽ bị mất trong tương lai. Hoặc mọi người nghĩ rằng họ đã mất các thay đổi, nhưng không thể chứng minh điều đó. Hoặc họ muốn xem ai đã thay đổi khi nào và tại sao. Đó chính xác là vấn đề mà một VCS giải quyết.

Khi chọn phần mềm / thư viện nguồn mở, có kho lưu trữ DVCS chắc chắn là một lợi thế trong tiêu chí lựa chọn.

1) Chúng tôi có thể sao chép toàn bộ kho lưu trữ, không cần phải lo lắng về dự án hoặc trang web của nó đã chết.

2) Mọi người sẵn sàng gửi sửa lỗi thông qua yêu cầu kéo, dẫn đến sửa lỗi nhanh hơn cho các vấn đề khẩn cấp.