Cách hiệu quả / hiệu quả nhất để phát triển một ứng dụng có nhiều người mà không cần kiểm soát nguồn là gì?

Giới thiệu về tình hình của tôi

Tôi làm việc cho một công ty phát triển web nhỏ. Chúng tôi có một nhóm gồm bốn nhà phát triển ASP.NET, bao gồm cả tôi. Hầu như tất cả các dự án của chúng tôi (> 98%) là các dự án một người mất khoảng 1-4 tuần để hoàn thành. Chúng tôi không sử dụng kiểm soát nguồn hoặc phiên bản. Điều duy nhất chúng tôi có là một thư mục dùng chung trên máy chủ cục bộ chứa nguồn mới nhất (== nguồn của ứng dụng trực tiếp) của tất cả các dự án.

Trong những dịp hiếm hoi mà chúng tôi cần phải làm việc trong cùng một dự án với nhiều người, chúng tôi sử dụng ... Ngoài so sánh. Một hoặc hai lần một ngày các nhà phát triển hỏi nhau rằng họ có phiên bản biên dịch và sau đó họ đồng bộ hóa mã của họ bằng cách sử dụng Beyond So sánh. Khi chỉ có hai người đang làm việc trong một dự án, điều này hoạt động "khá tốt", nhưng ngay khi một nhà phát triển thứ ba bước vào quy trình, nó sẽ trở thành một thứ rác rưởi không thể quản lý được. Đặc biệt là khi mọi người bắt đầu thay đổi cơ sở dữ liệu.

Tôi (và một hoặc hai trong số các nhà phát triển đồng nghiệp của tôi) đã nói với sếp của tôi nhiều lần rằng chúng ta nên bắt đầu sử dụng một số hình thức kiểm soát nguồn và phiên bản như Git, Mercurial hoặc TFS (ông chủ của chúng tôi rất quan tâm đến Microsoft). Thật không may, ông chủ của tôi không thấy được lợi thế của việc chuyển sang hệ thống kiểm soát nguồn và phiên bản, bởi vì trong mắt anh ấy mọi thứ đều hoạt động tốt và anh ấy không muốn đầu tư thời gian và tiền bạc để thiết lập một hệ thống mới và đảm bảo mọi người biết cách sử dụng nó Ngay cả sau khi tôi giải thích các ưu điểm (như cộng tác đơn giản hóa, các phiên bản khác nhau của ứng dụng, cách thay đổi mã an toàn hơn, ...) với anh ta, anh ta vẫn không nghĩ rằng đó là thứ chúng tôi cần.

Trong số bốn nhà phát triển, chỉ có hai (bao gồm cả tôi) có kinh nghiệm về kiểm soát nguồn (Git). Và kinh nghiệm đó rất hạn chế. Tôi biết cách sao chép kho lưu trữ Github vào máy tính của mình, thực hiện một số thay đổi, cam kết chúng và đẩy chúng trở lại Github. Đó là nó.

Giải thích về vấn đề / mối quan tâm của tôi

Trong vài tuần nữa, chúng tôi sẽ bắt đầu thực hiện một dự án khá lớn cho các tiêu chuẩn của chúng tôi. Có thể sẽ mất 2-3 nhà phát triển một vài tháng để hoàn thành nó. Tôi sẽ là trưởng dự án (quản lý dự án và nhà phát triển chính) và tôi sẽ chịu trách nhiệm về mọi thứ. Tôi đã chia sẻ các vấn đề của mình với phương pháp Beyond So sánh của chúng tôi và tôi không muốn đi theo con đường này với dự án lớn này sẽ là trách nhiệm của tôi.

Vì tôi nghi ngờ rằng chúng tôi sẽ có thể

• thiết lập máy chủ Git của chúng ta,
• dạy mọi người làm việc với Git và
• sử dụng Git thành công trong dự án lớn này,

Tôi quan tâm nếu bất kỳ ai trong số các bạn biết một số cách tốt để cho phép nhiều người cộng tác trong cùng một dự án mà không cần sử dụng kiểm soát nguồn hoặc phiên bản.

Cập nhật

Tôi muốn cảm ơn tất cả mọi người cho câu trả lời và ý kiến ​​của họ. Đây là kế hoạch:

1. Có một cuộc họp với các nhà phát triển để đảm bảo tất cả những người kỹ thuật đều cảm thấy giống như cách thực hiện kiểm soát nguồn. Chúng tôi sẽ làm cho một điểm mạnh hơn khi tất cả mọi người đằng sau nó.
2. Trình bày ý tưởng với sếp và nói với anh ta rằng chúng tôi thực sự cần kiểm soát nguồn.
3. Thực hiện nó càng sớm càng tốt.

Vui lòng dành một ngày để cài đặt kiểm soát phiên bản và dạy mọi người trong dự án sử dụng nó. Nó không khó lắm đâu. Cá nhân tôi chưa sử dụng Git, nhưng tôi đã thiết lập và sử dụng các hệ thống kiểm soát phiên bản khác và chúng không khó để làm việc. Hãy chắc chắn rằng bạn chọn một trong đó tích hợp với môi trường phát triển của bạn. Điều này sẽ làm cho việc sử dụng nó hầu như liền mạch.

Điều này sẽ không lãng phí thời gian.

Thời gian bạn sẽ mất khi ai đó ghi đè hoặc xóa một số mã sẽ khiến bạn tốn nhiều tiền hơn.

Nếu bạn không có quyền kiểm soát phiên bản, bạn cũng sẽ dành một lượng thời gian không đáng có để sao lưu dự án của mình và lo lắng về việc mọi người có phiên bản nào và phiên bản nào trên máy chủ, v.v.

Nếu bạn cần thuyết phục sếp ước tính thời gian bạn sẽ phải thiết lập và giám sát mọi giải pháp kiểm soát không phải phiên bản và thêm chi phí viết lại một vài ngày mất việc. Đừng quên thêm chi phí cho việc chỉnh sửa thủ công từ 3 nhà phát triển làm việc trên cùng một tệp nguồn và chi phí thêm khi nhận được sự hợp nhất đó. Kiểm soát phiên bản tốt cung cấp cho bạn miễn phí

Sau đó so sánh với chi phí để có được kiểm soát phiên bản - không (nếu bạn truy cập nguồn mở) và thiết lập nó - 3 ngày.

Đừng quên rằng một lỗi sau này trong dự án sẽ có giá cao hơn một lỗi sớm. Nếu bạn phải làm lại toàn bộ dự án vì một sai lầm bất cứ ai cũng có thể làm điều này sẽ tốn kém hơn nhiều so với thời gian viết lại, nó có thể khiến sếp của bạn mất danh tiếng của công ty.

Nếu bạn chia sẻ nguồn trên một thư mục, bạn cũng có thể chia sẻ repo ở đó. Sếp sẽ không biết về nó ngoại trừ có một thư mục .git trong đó.

Bạn không bao giờ phải xin phép để thực hiện công việc của mình đúng cách - Seth Godin.

Thiết lập kiểm soát nguồn, tìm hiểu cách sử dụng và không nói với sếp của bạn. Tôi thường không ủng hộ việc không tuân theo quản lý, nhưng trong trường hợp này, sếp của bạn thật ngu ngốc. Nếu bạn thực sự nghĩ rằng git sẽ mất quá nhiều thời gian để tìm hiểu, thì hãy bắt đầu với một hệ thống kiểm soát phiên bản đơn giản hơn như svn - nó không làm tất cả những điều tuyệt vời mà git làm, nhưng thậm chí còn dễ hiểu hơn.

Đừng đợi cho đến khi bạn ở giữa nó và gặp rắc rối nghiêm trọng trước khi bạn thực hiện một cái gì đó. Chỉ cần làm điều đó, và hoàn thành công việc.

Chỉnh sửa để thêm: Điều mà câu hỏi của bạn thực sự hỏi là 'làm cách nào để kiểm soát nguồn mà không sử dụng hệ thống kiểm soát nguồn'. Bạn đã nhận ra nhu cầu và tôi nghĩ mọi người ở đây thực sự đang nói với bạn điều tương tự: Không có cách nào lành mạnh để kiểm soát nguồn mà không có hệ thống kiểm soát nguồn.

Tôi chỉ có bản tóm tắt của bạn để đi qua, nhưng từ đó có vẻ như ông chủ của bạn đang tranh luận về thời gian và tiền bạc, và bạn đang đưa ra một lập luận ưu việt về kỹ thuật. Bạn cần phải tranh luận về thời gian và tiền bạc. Tìm hiểu cách thức hoạt động của git và theo dõi trong một khoảng thời gian nó có thể tiết kiệm, sau đó xuất trình nhật ký cho sếp của bạn với các mục như "28/03/2011 phải đợi 30 phút để Joe quay lại bản dựng có thể biên dịch được vì vậy chúng tôi có thể thực hiện một lệnh hợp nhất, git merge với cam kết cuối cùng của anh ta sẽ có khoảng 5 giây "với tổng số tốt ở phía dưới.

Nếu đào tạo và thiết lập máy chủ là các rào cản kinh doanh, có vô số cách để thiết lập quy trình công việc git, bao gồm chỉ có một thành viên trong nhóm thực sự sử dụng git, với các thư mục được chia sẻ cho "máy chủ".

Hướng dẫn các đồng nghiệp của bạn sao chép mã của họ vào một thư mục được chia sẻ bất cứ khi nào nó là điểm tốt để chia sẻ. Bạn có thể giữ một kho lưu trữ cho mỗi người trong số họ và tự mình thực hiện tất cả các công cụ kiểm soát nguồn, và từ từ chuyển giao ngày càng nhiều trách nhiệm kiểm soát nguồn cho họ khi bạn đủ tự tin để đào tạo họ. Đó là cách xa lý tưởng để làm điều đó, nhưng so với những gì bạn có bây giờ, thậm chí điều đó sẽ giúp bạn tiết kiệm thời gian cho việc hợp nhất. Việc thuyết phục sếp của bạn với đường cong học tập nhóm ít hơn và bạn sẽ nhận được tất cả các lợi ích quay vòng và phiên bản mà bạn muốn.

Tôi không làm nhiều công việc cơ sở dữ liệu, nhưng theo hiểu biết của tôi, việc hợp nhất các thay đổi lược đồ cơ sở dữ liệu không được xử lý tốt bằng kiểm soát nguồn. Nếu những sự hợp nhất đó là khó khăn, bạn có thể muốn xem xét một sự thay đổi quy trình trong đó tất cả các thay đổi cơ sở dữ liệu đều đi qua một người gác cổng duy nhất.

Điều này là điên rồ. Bạn nên sử dụng một VCS ngay cả khi bạn tự làm việc. Không sử dụng VCS trong một công ty nên bị cấm. Cứ làm đi. Ngay bây giờ! Thực sự ... Bạn không cần những thứ tiên tiến ngay từ đầu. GitHub và GitLab rất dễ sử dụng, nhưng tôi chắc chắn rằng bạn có thể tìm thấy một số dịch vụ lưu trữ tương thích với Windows hơn nếu sếp của bạn khăng khăng (mặc dù không khó để thiết lập và sử dụng Git trên Windows).

Suy nghĩ bạn hỏi là không thể . Nếu nhiều người đang làm việc trên cùng một dự án mà không sử dụng bất kỳ kiểm soát nguồn nào, bạn sẽ nhanh chóng gặp nhiều vấn đề và vì bạn sẽ là nhà phát triển chính, bạn sẽ phải đối phó với họ.

Từ kinh nghiệm cá nhân của tôi, làm việc trên một dự án mà không có kiểm soát nguồn trở thành không thể từ hai nhà phát triển . Không phải ba. Không phải bốn. Hai. Bạn có thể có thể quản lý tình huống với hai nhà phát triển trong một số trường hợp đặc biệt : nếu những nhà phát triển đó rất có tổ chức và chuyên nghiệp, nếu họ tương tác tốt, nếu họ có thể dễ dàng trao đổi (vì vậy được đặt trong cùng một phòng vào cùng một giờ, mọi thời gian) và nếu họ có thể tránh được lỗi của con người (sửa đổi bằng cách nhầm lẫn tệp đã được sửa đổi bởi người khác cùng một lúc, sau đó xóa các thay đổi do người này thực hiện).

Trong trường hợp của tôi, nó luôn luôn là một thảm họa ít nhiều xảy ra khi khiến hai người tham gia vào một dự án mà không có kiểm soát phiên bản. Trong trường hợp tốt nhất, một người đã gửi các tệp đã thay đổi đến người thứ hai và người thứ hai này đã sử dụng một công cụ khác để áp dụng các thay đổi theo cách thủ công. Trong trường hợp xấu nhất, một người đã theo dõi những thay đổi cô ấy đang làm, sau đó áp dụng lại chúng mỗi khi người thứ hai sửa đổi mã nguồn. Kết quả: mất rất nhiều thời gian, tiền bạc và năng suất.

Bây giờ, từ quan điểm của tôi và kinh nghiệm của riêng tôi, tôi thấy ba giải pháp cho vấn đề bạn có:

• Cài đặt một điều khiển phiên bản dễ sử dụng . Tôi đã từng cài đặt CollabNetSubversion làm máy chủ SVN, nó khá nhanh và dễ cài đặt, nếu bạn không quan tâm gì đến bảo mật . Nếu bạn sử dụng Visual Studio, AnkhSvn có thể được cài đặt để cho phép các nhà phát triển cập nhật / cam kết mã nguồn dễ dàng từ bên trong Visual Studio.

• Thuyết phục sếp của bạn rằng bài kiểm tra Joel được viết bởi một người biết rất rõ công việc của anh ta, và nếu bài kiểm tra Joel đề nghị kiểm soát phiên bản, có một lý do chính đáng đằng sau nó. Rốt cuộc, anh ta cũng có thể quyết định rằng các nhà phát triển không cần một công cụ tô sáng IDE / cú pháp để viết mã. Windows Notepad vẫn ổn, phải không? Và tại sao có truy cập internet? Tất cả những gì chúng ta cần là một PC rất cũ chạy Windows 3.1.

• Thoát khỏi công ty này , vì tôi có một số nghi ngờ rằng mọi thứ ngoại trừ kiểm soát phiên bản đều hoàn hảo và chuyên nghiệp ở đó.

Không sử dụng VCS cho bất kỳ dự án lớn nào vì bạn không muốn đầu tư thời gian thiết lập cũng giống như thực hiện một hành trình dài bằng chân trần, vì bạn không muốn đầu tư thời gian đi giày.

Bất kỳ VCS nào cũng là đơn đặt hàng có cường độ tốt hơn là không có gì cả.

Một cách dễ dàng để thiết lập một VCS là lấy TortoiseSVN (vì dường như bạn đang sử dụng C #, tôi giả sử bạn đang ở trên Windows). Bạn tạo một kho lưu trữ trong một thư mục cục bộ mà bạn chọn (điều hướng đến nó, nhấp chuột phải> TortoiseSVN> Tạo kho lưu trữ tại đây). Chia sẻ thư mục này trong mạng của bạn (tốt nhất là trên máy, luôn có sẵn) và thực hiện kiểm tra với url file://computername/path/to/that/repository. Tải xuống loại trừ, điều này mất không quá một phút để thiết lập.

Câu trả lời của bạn là một liên kết đơn giản đến sếp của bạn ... gửi trang này cho anh ấy / cô ấy và làm nổi bật số lần các từ "bỏ" xuất hiện từ các chuyên gia.

Mặc dù từ "câm" có thể xuất hiện nhiều lần, tôi chắc chắn rằng ông chủ của bạn thì không. Nó chỉ không rõ ràng với anh ta giá trị tuyệt đối của điều này. Câu hỏi đặt ra cho anh ta là câu hỏi nào liên quan đến kinh doanh sẽ dẫn đến cùng một câu trả lời (có lẽ một kế toán gợi ý "Thay vì không đảm bảo tòa nhà này mà bạn được liên kết đến mức tối đa, nó sẽ giúp bạn tiết kiệm một vài đô la!")

Kiểm soát nguồn chỉ cần thiết khi số lượng nhà phát triển trong một dự án> 0. Tôi bắt đầu nghĩ rằng người ta có thể nói như vậy về tích hợp liên tục ...

(-:

Là nhà phát triển ASP.NET, tôi khuyên bạn nên dùng một trong Subversion, TFS hoặc Mercurial - nhưng thành thật mà nói, không vấn đề gì miễn là bạn đi với thứ gì đó. Phát triển mà không có kiểm soát phiên bản sẽ không có ý nghĩa gì - thậm chí còn ít hơn khi các công cụ ít nhiều được tự do triển khai và chi phí sử dụng chúng là tối thiểu.

TFS sẽ cung cấp cho bạn một mức độ tích hợp tuyệt vời. DVCS (đồng bóng hoặc git) có thể sẽ cung cấp cho bạn sự linh hoạt và khả năng nhất. Không có lý do chính đáng KHÔNG làm điều này.

Nếu tôi bắt đầu lại từ đầu thì gần như chắc chắn sẽ có Mercurial.

Khi bạn có quyền kiểm soát phiên bản, bạn có thể chuyển sang máy chủ xây dựng (TFS, TeamCity) và từ đó đến tích hợp liên tục và tại thời điểm đó, bạn bắt đầu chiến thắng trong tay.

Để quay lại điểm xuất phát của bạn:

Tôi sẽ là trưởng dự án (quản lý dự án và nhà phát triển chính) và tôi sẽ chịu trách nhiệm về mọi thứ

Đúng vậy, bạn chịu trách nhiệm nên bạn quyết định bạn cần kiểm soát phiên bản (vì bạn làm), bạn quyết định rằng bạn cần một máy chủ xây dựng (vì bạn làm), bạn quyết định rằng bạn cần phải có đầu ra có thể triển khai từ dự án của bạn ngay từ ngày đầu tiên (bởi vì nếu bạn luôn có thể triển khai nó - và do đó tạo điều kiện cho việc thử nghiệm nhiều hơn) và việc triển khai sẽ được tự động hóa cao - đây là những bước bạn đang thực hiện để đảm bảo thành công cho dự án của mình (mà bạn chịu trách nhiệm ...)

Như đã đề cập ở trên, bạn có thể đặt một kho lưu trữ vào thư mục chia sẻ mà bạn đã có. Bạn không cần phải dành thời gian cấu hình máy chủ nếu bạn sử dụng hệ thống kiểm soát nguồn phân tán, như Git, Mercurial hoặc Bazaar.

Tôi khuyên bạn nên sử dụng Git, vì bạn đã có một số kinh nghiệm với nó, hoặc Mercurial, có tích hợp tốt vào Visual Studio.

Nếu trong tương lai, sếp của bạn sẽ bảo bạn chuyển sang TFS, điều đó vẫn tốt hơn là không có kiểm soát phiên bản nào cả.

Quay trở lại những ngày Powerbuilder của tôi, chúng tôi đã có cả một nhóm làm việc trên một bộ ứng dụng mà không sử dụng kiểm soát nguồn. Ồ, Powerbuilder có quyền kiểm soát nguồn, nhưng thực sự sử dụng nó là một crapshoot - nếu PB bị lỗi trong khi bạn đã kiểm tra tệp (và nó bị lỗi RẤT NHIỀU), thì tệp mã nguồn nhị phân, sở hữu đó hiện không thể truy cập được. Một số cờ đã được đặt trong tệp và không có bản sao PB nào khác có thể tải nó, ngay cả cùng một người đã kiểm tra nó.

Vì vậy, những gì chúng tôi đã làm là khá đơn giản. "Này, Tom, tôi sẽ làm việc trên xyz.pbl. Vì vậy, đừng thực hiện bất kỳ thay đổi nào". Trong sơ đồ lớn của mọi thứ, chúng tôi hiếm khi có bất kỳ vấn đề.

Giả sử bạn không thể thuyết phục nhóm của mình chấp nhận kiểm soát phiên bản hoặc ông chủ của bạn có được sự khuất phục và khăng khăng rằng nhóm dừng lại, có một cách tiếp cận ít tối ưu hơn bạn có thể thực hiện.

Cài đặt Git hoặc Mercurial trên máy của riêng bạn. Phiên bản công việc của riêng bạn. Khi nhóm đồng bộ hóa công việc của họ thông qua quy trình Beyond So sánh, hãy thêm các thay đổi vào repo cục bộ của bạn dưới dạng một cam kết mới. Bạn sẽ luôn có thể truy xuất phiên bản làm việc trước đó từ repo cục bộ nếu đồng bộ hóa của nhóm phá vỡ thứ gì đó.

Sử dụng DVCS đảm bảo rằng không có yêu cầu phải có máy chủ và không có quy trình thiết lập phức tạp. Cài đặt Mercurial và nhận và chạy với những điều cơ bản sẽ mất không quá 30 phút.

Nó không phải là một giải pháp lý tưởng, nhưng nó tốt hơn là không có gì.

Phản ứng ban đầu của tôi về điều này là bạn đã có một quy trình làm việc lý tưởng mà không cần kiểm soát phiên bản. Tất cả các bạn dường như có một cách tốt để quản lý sáp nhập và như vậy. Từ góc độ quản lý, đây có vẻ là một tình huống tốt. Tôi đã gặp các nhóm sử dụng kiểm soát phiên bản, nhưng phải đấu tranh với chính quá trình phát triển.

Vì vậy, việc thuyết phục sếp của bạn chỉ dựa vào lập luận của bạn về kiểm soát phiên bản đó sẽ mang lại "một quy trình tốt hơn" là khá vô nghĩa. Tuy nhiên, có một lập luận quan trọng hơn nhiều về lý do tại sao bạn cần sử dụng kiểm soát phiên bản hoặc nguồn ở vị trí đầu tiên, có thể dễ dàng tính toán thành tiền. Và đó là:

Rủi ro

Vấn đề không phải là việc sử dụng kiểm soát nguồn làm cho quá trình phát triển của bạn tốt hơn. Đây là vấn đề sẽ xảy ra nếu bạn không có quyền kiểm soát nguồn. Những rủi ro là gì?

Nói ai đó xóa nhầm một hàm trong mã hoặc toàn bộ tệp? Chi phí sửa chữa là bao nhiêu? Hy vọng rằng ai đó đã được bảo hiểm, vì vậy sửa chữa là cận biên.

Nhưng điều gì xảy ra nếu không có ai có bản sao lưu của tập tin bị mất? Mất bao nhiêu giờ để sửa chữa? Điều đó có thể sẽ mất nhiều ngày và điều đó dễ dàng được tính trung bình trong số giờ của con người. Đó sẽ là quá nhiều cho công ty? Điều này có thể được khắc phục bằng cách nào đó nhanh hơn?

Vâng, với một số loại kiểm soát nguồn. Ngược lại: mất bao lâu để thiết lập kiểm soát phiên bản và sao lưu nó? Hầu hết các mã nguồn mở như git hoặc mercurial không mất nhiều thời gian để thiết lập. Dạy mọi người cách sử dụng sẽ không khó lắm, vì bạn đã biết cách hợp nhất với Beyond So sánh và bạn "đăng ký" vào một thư mục dùng chung. Đây là một chi phí thiết lập một lần. Những người đàn ông này sẽ ít hơn những người mà rủi ro có? Nếu điều này là đúng thì việc sử dụng kiểm soát nguồn sẽ là ưu tiên hàng đầu.

Miễn là bạn có thể chỉ ra một lý do kinh doanh tại sao việc kiểm soát nguồn lại hữu ích và quản lý rủi ro sẽ là một trong những yếu tố lớn như vậy, điều đó sẽ thuyết phục hầu hết các ông chủ.

Sử dụng Hệ thống kiểm soát phiên bản phân tán như git và sử dụng máy thư mục dùng chung của bạn để lưu trữ kho lưu trữ tham chiếu. Đây là lý do tại sao:

Mỗi bản sao là một bản sao lưu

Nếu máy chủ ổ cứng gặp sự cố, mọi người đều có một bản sao, sẵn sàng để được triển khai trên một ổ đĩa hoặc máy chủ mới. Vì công ty của bạn không nghiêm túc về kiểm soát phiên bản, tôi cho rằng nó có thể khá giống với các bản sao lưu.

Tài liệu tham khảo chung

Có một kho lưu trữ chính với một nhánh chính cho phép biết phiên bản có từ cuối cùng. Điều này giải quyết "Bạn đã kiểm tra các thay đổi của mình so với phiên bản của Franck, nhưng bạn cũng có John's phải không? Và bạn đã hợp nhất chúng như thế nào?".

Cung cấp thoải mái hơn

Khách hàng muốn có phiên bản alpha ngày hôm nay? Vâng, bạn có thể kiểm tra xem chủ có đủ ổn định và vận chuyển không. Nếu không và bạn không có thời gian để sửa nó, hãy quay ngược thời gian và lấy phiên bản cũ hơn nhưng ổn định hơn. Bạn không thể làm điều đó nếu bạn chỉ có phiên bản mới nhất.

Quay ngược thời gian và sửa chữa sai lầm của bạn

Hợp nhất thủ công của bạn có vấn đề mà bạn chỉ thấy sau vài ngày, nhưng bạn đã ghi đè lên nội dung của các thư mục được chia sẻ của bạn? Nếu không có VSC, bạn không có lịch sử nên bạn không thể dễ dàng quay lại điểm mà bạn có thể kiểm tra các lỗi bạn đã mắc phải và sửa chúng. Mã không giống như một bức tranh, nó giống như một bộ phim: nó phát triển theo thời gian. Bạn có thể trích xuất một hình ảnh từ một bộ phim. Bạn không thể trích xuất một bộ phim từ một hình ảnh.

Xác định vị trí lỗi dễ dàng hơn

Một lỗi xuất hiện nhưng bạn không thực sự nhận thấy tại thời điểm nó được giới thiệu, vì vậy bạn không thể sửa nó trong khi mã "nóng". Bây giờ bạn không thực sự biết thay đổi nào đã giới thiệu nó, vì vậy nó có thể đến từ một số vị trí khác nhau trong mã. Sẽ mất hàng giờ chỉ để tìm nơi để tìm. Với git, bạn có thể vừa phát triển một thử nghiệm để biết liệu lỗi có xảy ra trên một phiên bản cụ thể hay không và sử dụng git bissectđể tìm ra cam kết chính xác đã đưa ra lỗi. Thay vì tìm kiếm hàng ngàn dòng mã, giờ đây bạn biết nó nằm trong 10 dòng thay đổi và bạn có thể giữ thử nghiệm trong bộ kiểm tra của mình để đảm bảo lỗi không được giới thiệu lại.

Mỗi nhà phát triển chịu trách nhiệm về công việc của mình

Nếu bạn là trưởng nhóm và không có VCS, rất có thể bạn sẽ phải thực hiện công việc bẩn thỉu, sáp nhập. Nếu bạn tự làm, có lẽ bạn không biết mọi thứ về tất cả các thay đổi và có thể gây ra lỗi. Ngược lại, nếu bạn luôn yêu cầu những người đã viết mã để thu thập với bạn mỗi khi có mã để hợp nhất, thì đó là lúc họ sẽ không sử dụng để tạo mã mới.

Với một VCS, trong một quy trình công việc đơn giản, nhà phát triển chỉ phải chăm sóc công việc của mình và một nguồn thay đổi bên ngoài: nhánh chính. Có thể có 1 hoặc 100 người cam kết trong chi nhánh chính, điều đó cũng tương tự. Để có thể thúc đẩy những thay đổi của anh ấy / cô ấy, anh ấy / cô ấy sẽ phải điều chỉnh chúng theo những thay đổi mới nhất được thực hiện bởi những người khác. Có vẻ như mất nhiều thời gian hơn để đẩy mã, nhưng đó là bởi vì bạn cũng đang thực hiện việc hợp nhất, điều này sẽ mất thời gian.

Sự khác biệt là hợp nhất được thực hiện bởi người đã thực hiện các thay đổi, người biết mã đó tốt nhất vì anh ấy / cô ấy đã viết nó.

Ai đã viết mã đó?

Có lỗi ở đây, nhưng ai đã viết dòng mã cụ thể đó? Thật khó để nhớ, đặc biệt là nếu dự án kéo dài bảy tháng. git blamesẽ nói cho bạn biết ai và khi nào dòng đó được viết, vì vậy bạn có thể hỏi đúng người, và không có "Tôi không nhớ việc viết đó".

Dự án ngày càng lớn

Khách hàng muốn nhiều tính năng hơn và bạn là một nhóm quá nhỏ, bạn sẽ cần một nhà phát triển khác. Làm thế nào để bạn quản lý sự phức tạp gia tăng mà không có VSC?

Thay đổi khẩn cấp

Khách hàng đã gọi và yêu cầu sửa lỗi nghiêm trọng cho sản xuất, nhưng bạn hiện đang làm việc trên một tính năng mới. Chỉ cần git stashđặt các thay đổi của bạn sang một bên hoặc cam kết chúng trong một chi nhánh mới và đẩy các thay đổi và bạn đã sẵn sàng bắt đầu khắc phục khẩn cấp, mà không sợ mất công việc đang chờ xử lý.

Nó hoạt động 10 phút trước

Bạn đang thực hiện một số thay đổi cục bộ và một cái gì đó hoạt động 10 phút trước đã ngừng hoạt động. Nếu không có VCS, bạn sẽ nhìn chằm chằm vào mã hoặc tốt nhất, tạo một bản sao của phiên bản tham chiếu và tìm khác biệt để xem những gì bạn thay đổi. Đợi đã, tham chiếu đã thay đổi kể từ khi tôi bắt đầu làm việc, vì vậy tôi không thể khác được nữa. Và tôi đã không nghĩ sẽ giữ một bản sao nguyên sơ của mã mà tôi dựa trên những thay đổi của mình.

Với một VCS, bạn chỉ cần làm một cái gì đó như git diffngay lập tức và thay đổi so với phiên bản đúng của mã mà bạn dựa vào.

Tôi phải giữ nhật ký gỡ lỗi của mình

Vì vậy, bạn là một kẻ xấu và không sử dụng đăng nhập? Bạn đã phải rắc printfs trong tất cả các cơ sở mã của mình cho đến khi bạn tìm thấy tất cả những phần của lỗi khó chịu đó? Bây giờ bạn đã tìm thấy một cái, sửa nó, nhưng muốn giữ mã gỡ lỗi được làm cẩn thận của bạn để sửa các vấn đề còn lại.

Nếu không có VCS, bạn cần phải sao chép các tệp, mở rộng mã gỡ lỗi (có thể thêm một số lỗi chỉnh sửa), đẩy mã đó và đặt lại các tệp đã sao lưu của bạn. Ồ, nhưng có vẻ như một số mã gỡ lỗi đã vào.

Với git, bạn chỉ cần git add --patchchọn vài dòng mã bạn muốn đưa vào cam kết của mình, và có thể cam kết chỉ đó. Sau đó, bạn tiếp tục công việc của bạn và vẫn có mã gỡ lỗi của bạn. Bạn không phải chạm vào mã, do đó không có lỗi sao chép / dán.

Quả bóng lớn

Không có VCS, mọi người làm việc về phía họ và cung cấp cho bạn một loạt các thay đổi, đôi khi không liên quan. Khi có quá nhiều mã để kiểm tra, thật khó để tìm ra lỗi.

Một VCS sẽ cho phép bạn thực hiện các thay đổi nhỏ, tăng dần và cung cấp cho bạn một thay đổi. Các changelog là điều cần thiết: người phải nói có lý do tại sao họ đang làm thay đổi, chứ không phải những gì là sự thay đổi (những gì câu hỏi được trả lời alredy bởi sự thay đổi mã chính nó). Điều này có nghĩa là khi bạn đang kiểm tra một số mã của một tính năng mới chẳng hạn, bạn sẽ không phải đọc nhiều thay đổi hỗn hợp không liên quan như các lỗi không liên quan. Điều này giúp tập trung vào mã bạn quan tâm.

Nếu tôi cho bạn 100 củ khoai tây 1, và một quả bị thối, bạn sẽ thấy ngay lập tức. Bây giờ nếu tôi đổ 100 củ khoai tây trước mặt bạn và yêu cầu bạn tìm cái khoai tây thối, thì đó không phải là nhiệm vụ tương tự.

Lõm

Hy vọng bạn có chính sách phong cách mã hóa tốt, nếu không những thay đổi thụt đầu dòng sẽ khiến bạn phát điên nếu bạn hợp nhất bằng tay. Chắc chắn, bạn có thể bỏ qua khoảng trắng trong các thay đổi (nhưng không phải bằng ngôn ngữ khi số lần thụt lề, như Python). Nhưng sau đó bạn sẽ nhận được mã trông kỳ lạ khó đọc.

Bạn là trưởng dự án

Nếu bạn là người lãnh đạo, điều này có nghĩa là bạn sẽ nhận lỗi nếu mọi thứ không hoạt động. Nếu bạn không thể thoải mái với tình huống này bởi vì sếp của bạn vẫn không thể hiểu rằng sử dụng đúng công cụ cho đúng công việc là xứng đáng, thì ít nhất, tôi sẽ từ chối trở thành người lãnh đạo của một thất bại có thể dự đoán được.

Sử dụng dropbox, nó có lịch sử phiên bản tự động. Bạn có thể chia sẻ thư mục dropbox giữa nhiều người dùng.

Biên tập

Bạn cũng có thể tải xuống TortoiseSVN-client và tạo "kho lưu trữ cục bộ" trên ổ đĩa mạng. Sau đó mọi người có thể kiểm tra mã nguồn theo vị trí thư mục mạng.