Kiểm soát phiên bản cho nhà phát triển độc lập?

Bạn có nghĩ rằng đáng để sử dụng kiểm soát phiên bản nếu bạn là nhà phát triển độc lập và nếu vậy, tại sao? Bạn có giữ kho lưu trữ trên máy tính của riêng bạn, hoặc ở nơi khác, nơi nó có thể phục vụ như một bản sao lưu không?

Nếu bạn sử dụng kiểm soát nguồn phi tập trung (Mercurial hoặc Git hoặc Bazaar hoặc bất cứ điều gì), bạn sẽ có được lợi thế so với SVN / CVS, giúp sử dụng dễ dàng, hữu ích và mạnh mẽ trong trường hợp bạn là một người không chuyên:

1. Bạn cam kết tại địa phương : thư mục dự án của bạn là repo của bạn với lịch sử ĐẦY ĐỦ. Vì vậy, bạn không cần phải có máy chủ, bạn cam kết trực tiếp trong repo của mình và bạn có thể có một số repos trong cùng một máy tính. Sử dụng máy tính xách tay mà đôi khi bạn mở để tiếp tục làm việc? Tuyệt quá! Bạn không phải thiết lập một máy chủ và nếu bạn cần một máy chủ sau, thật dễ dàng và bạn chỉ cần "đẩy" và "kéo" các thay đổi giữa các kho lưu trữ.
2. Nó được thực hiện để dễ dàng thử nghiệm : thường bạn cần có ý tưởng về một tính năng mà không gây ô nhiễm mã. Với SVN và CVS, bạn có thể sử dụng hệ thống phân nhánh và bỏ nhánh nếu tính năng này không tốt như bạn muốn. Nhưng nếu bạn muốn hợp nhất tính năng này với phiên bản trung kế, bạn sẽ gặp rất nhiều khó khăn để khắc phục những bất ngờ. Git, Mercurial và Bazaar (ít nhất) làm cho việc hợp nhất và các chi nhánh thực sự dễ dàng. Bạn thậm chí có thể chỉ cần sao chép một repo, làm việc trên nó một thời gian, vẫn cam kết và giết nó hoặc đẩy các thay đổi của bạn trong repo chính nếu bạn muốn.
3. Tính linh hoạt của tổ chức : như đã chỉ ra trước đây, khi bạn có repos mà bạn tổ chức khi bạn cần, thật dễ dàng để bắt đầu một mình và cho phép người khác làm việc với bạn bằng cách thay đổi tổ chức của bạn. Không có tổ chức nào được áp đặt nên bạn chỉ cần thiết lập và voilà. Tôi thường chỉ đẩy / kéo thay đổi giữa các máy tính của riêng tôi (máy tính xách tay / máy tính để bàn / máy chủ) và tôi vẫn một mình trên các nhà phát triển của mình. Tôi sử dụng Mercurial và điều đó giúp tôi nhân đôi công việc của mình nhưng cũng hoạt động với các tính năng tôi nghĩ về bên ngoài trên máy tính xách tay của mình, sau đó tiếp tục làm việc với các tính năng khác trên máy tính để bàn của tôi, sau đó đẩy các thay đổi máy tính xách tay của tôi trên máy tính để bàn hoặc máy chủ của tôi và hợp nhất toàn bộ máy tính để bàn + máy tính xách tay và đặt nó (như bản sao lưu và repo làm việc nhóm trong tương lai) trên máy chủ của tôi.
4. Nó giúp thiết lập các bản sao lưu : nếu bạn thiết lập một repo trung tâm (trên GitHub nếu nó công khai hoặc trong một repo riêng trên BitBucket), bạn có thể dễ dàng viết một tập lệnh sẽ được thực thi mỗi khi máy tính được khởi động, và sau đó chuyển tập lệnh đã nói cho bạn bè của bạn để nó tự động sao lưu công việc của bạn. Đó là những gì tôi đang làm nên bây giờ tôi chắc chắn sẽ không dễ bị mất việc.

Trên thực tế, hiện tại, bạn không có lý do gì để không sử dụng công cụ nguồn điều khiển cho bất kỳ dự án nào. Bởi vì chúng mạnh mẽ và linh hoạt hơn trước và quy mô với nhu cầu của bạn.

kiểm soát mã nguồn hoàn toàn vô dụng đối với các nhà phát triển độc lập, vì như chúng ta đều biết:

• nhà phát triển độc lập không bao giờ phạm sai lầm
• các nhà phát triển độc lập không bao giờ bỏ qua các phiên bản không hoạt động
• nhà phát triển độc lập không bao giờ có nhiều hơn một phiên bản nên họ không sử dụng cho các chi nhánh
• nhà phát triển độc lập không bao giờ quan tâm đến những gì họ đã thay đổi ngày hôm qua hoặc tuần trước
• nhà phát triển độc lập không bao giờ, bao giờ cần sao lưu

Gọi tôi là "nhà phát triển phụ thuộc": Các kho lưu trữ Mercurial dễ dàng sao chép giữa máy tính để bàn, máy tính xách tay, ổ đĩa sao lưu USB và bitbucket.org của tôi. Tôi đã trở nên phụ thuộc và tôi thích nó theo cách đó!

Tại sao không?

Tôi là nhà phát triển solo và tôi sử dụng BitBucket và Mercurial cho các dự án cá nhân của mình. Có khả năng hoàn nguyên và fork mã của bạn là quá tốt để vượt qua.

Tôi tìm thấy giá trị trong đó, cá nhân. Các dự án của tôi đều được kiểm tra vào kho git (tất cả đều được giữ trên nhiều máy trong trường hợp có lỗi phần cứng). Các tính năng hữu ích nhất là phân nhánh (để tôi có thể chạy thử nghiệm gây rối với một nửa cơ sở mã của mình và không lo lắng về việc làm nổ tung vĩnh viễn) và hoàn nguyên (về cơ bản chỉ là hoàn tác trên steroid; trong trường hợp tôi thấy rằng tôi đã thực hiện một số sai lầm nằm ngoài phạm vi hoàn tác thường xuyên).

Đúng. Nó rất rất hữu ích. Matt Gallagher, người bạn của tôi đã đăng bài viết tuyệt vời về chủ đề này chỉ vài ngày trước lên blog phát triển iOS / MacOS "Ca cao với tình yêu" của anh ấy.

Bài viết là Mac & Git centric nhưng nó bao gồm những điều cơ bản.

Bạn cũng có thể quan tâm đến Câu hỏi StackExchange sau đây (và câu trả lời của họ).

• Có những lợi thế khi sử dụng một dvcs cho một nhà phát triển solo?
• Những kỹ thuật công cụ có thể có lợi cho một nhà phát triển solo?
• Git cho một nhà phát triển solo.

Đáng giá ?? Phải! Nếu bạn không sử dụng Kiểm soát nguồn thì bạn không kiểm soát nguồn của mình và điều đó thật tệ. Bạn không thể khác, bạn không thể hoàn nguyên, bạn không thể theo dõi các thay đổi - bạn sẽ mất hàng giờ để tìm ra lỗi giả mà bạn vừa nhập. Nó là tốt hơn để có nó trên một số máy chủ sao lưu, nhưng bạn cũng có thể máy tính của bạn và sử dụng bất kỳ phương pháp sao lưu nào bạn thấy phù hợp.

Hoàn toàn sử dụng kiểm soát nguồn. Sau đó, thiết lập một máy chủ xây dựng và tự động hóa các quy trình xây dựng và thử nghiệm của bạn. Xây dựng kích hoạt từ cam kết nguồn của bạn về repo trung tâm của bạn. Tôi đã làm việc một mình trong ba năm theo cách này và điều đó thật tuyệt vời.

Đúng.

Ngay cả các nhà phát triển đơn lẻ đôi khi cũng cần phải xem trạng thái mã của họ từ một số sửa đổi trong quá khứ. Và luôn luôn là một ý tưởng tốt để sao lưu mọi thứ quan trọng và áp dụng cho tất cả mọi người.