Tại sao tôi nên sử dụng kiểm soát phiên bản? [đóng cửa]

Tôi đã đọc một blog nơi người viết nói điều này

"Mã không tồn tại trừ khi nó được kiểm tra trong hệ thống kiểm soát phiên bản. Sử dụng kiểm soát phiên bản cho mọi thứ bạn làm. Mọi kiểm soát phiên bản, SVN, Git, thậm chí CVS, làm chủ và sử dụng nó."

Tôi chưa bao giờ sử dụng bất kỳ loại kiểm soát phiên bản nào và tôi không thấy nó tuyệt vời như vậy. Tôi đã googled nó và xem xét nó trước đây, nhưng tôi chỉ cần đưa nó vào điều khoản của trẻ em nếu bạn muốn.

Theo tôi hiểu ngay bây giờ, những thứ như SVN là để lưu trữ mã của bạn trực tuyến cho một nhóm người dùng hoặc nhà phát triển khác có quyền truy cập vào cùng một mã. Khi bạn cập nhật một số mã, bạn có thể gửi phiên bản mới và SVN sẽ giữ các bản sao của mã cũ cũng như các mã mới mà bạn cập nhật.

Đây có phải là ý tưởng cơ bản của nó hay tôi nhận được nó hoàn toàn sai?

Nếu tôi đúng, thì nó có thể không được sử dụng nhiều nếu tôi:

• Không có người khác làm việc về mã.
• Đừng có kế hoạch để cho người khác có mã.

Bạn có bao giờ:

• Thực hiện thay đổi mã, nhận ra đó là một sai lầm và muốn hoàn nguyên?
• Mất mã hoặc có một bản sao lưu quá cũ?
• Phải duy trì nhiều phiên bản của một sản phẩm?
• Bạn muốn thấy sự khác biệt giữa hai (hoặc nhiều) phiên bản mã của bạn?
• Muốn chứng minh rằng một thay đổi cụ thể đã phá vỡ hoặc sửa một đoạn mã?
• Muốn xem lại lịch sử của một số mã?
• Muốn gửi một thay đổi cho mã của người khác?
• Muốn chia sẻ mã của bạn hoặc để người khác làm việc với mã của bạn?
• Muốn xem bao nhiêu công việc đang được thực hiện, và ở đâu, khi nào và bởi ai?
• Muốn thử nghiệm một tính năng mới mà không can thiệp vào mã làm việc?

Trong những trường hợp này, và không còn nghi ngờ gì nữa, một hệ thống kiểm soát phiên bản sẽ giúp cuộc sống của bạn dễ dàng hơn.

Để đánh lạc hướng một người bạn: Một công cụ văn minh cho một thời đại văn minh.

Ngay cả khi bạn làm việc một mình, bạn có thể hưởng lợi từ kiểm soát nguồn. Trong số những người khác, vì những lý do:

• Bạn không mất gì cả. Tôi không bao giờ một lần nữa nhận xét ra mã. Tôi chỉ đơn giản là xóa nó. Nó không làm lộn xộn màn hình của tôi và nó không bị mất. Tôi có thể phục hồi nó bằng cách kiểm tra một cam kết cũ.

• Bạn có thể thử nghiệm theo ý muốn. Nếu nó không giải quyết được vấn đề, hãy hoàn nguyên nó.

• Bạn có thể xem các phiên bản trước của mã để tìm ra lỗi được giới thiệu khi nào và ở đâu. git bisectlà tuyệt vời trong vấn đề đó.

• Các tính năng "nâng cao" hơn như phân nhánh và hợp nhất cho phép bạn có nhiều đường phát triển song song. Bạn có thể làm việc trong hai tính năng đồng thời mà không bị nhiễu và chuyển đổi qua lại mà không gặp nhiều rắc rối.

• Bạn có thể thấy "những gì đã thay đổi". Điều này nghe có vẻ cơ bản, nhưng đó là điều tôi thấy mình đang kiểm tra rất nhiều. Tôi rất thường xuyên bắt đầu công việc một người của mình với: hôm qua tôi đã làm gì?

Chỉ cần đi trước và thử nó. Bắt đầu chậm với các tính năng cơ bản và tìm hiểu những người khác khi bạn đi. Bạn sẽ sớm thấy rằng bạn sẽ không bao giờ muốn quay lại "thời kỳ đen tối" không có VCS.

Nếu bạn muốn có một VCS cục bộ, bạn có thể thiết lập máy chủ lật đổ của riêng bạn (những gì tôi đã làm trong quá khứ), nhưng hôm nay tôi khuyên bạn nên sử dụng git. Đơn giản hơn nhiều. Đơn giản chỉ cần cdvào thư mục mã của bạn và chạy:

git init

Chào mừng đến với câu lạc bộ.

Kiểm soát phiên bản là một công cụ hiếm hoi mà tôi muốn nói là hoàn toàn bắt buộc, ngay cả khi bạn chỉ sử dụng nó như một nhà phát triển solo. Một số người nói rằng đó là một công cụ mà bạn sống và chết theo, tôi đồng ý với khẳng định đó.

Bạn có thể sử dụng kiểm soát phiên bản ngay bây giờ, ngay cả khi bạn không biết. Bạn có bất kỳ thư mục nào nói "Mã XXX Php (tháng 12)" hoặc "XXX.php.bak.2" không? Đây là những hình thức kiểm soát phiên bản rồi. Một hệ thống kiểm soát phiên bản tốt sẽ tự động xử lý việc này cho bạn. Bạn sẽ có thể quay lại bất kỳ thời điểm nào (rằng bạn đã kiểm tra dữ liệu) và có thể thấy một bản sao chính xác của dữ liệu đó.

Hơn nữa, nếu bạn chấp nhận một hệ thống như lật đổ và sử dụng kho lưu trữ từ xa (chẳng hạn như một hệ thống trên máy chủ mà bạn sở hữu), bạn sẽ có một nơi để giữ tất cả mã của mình. Cần một bản sao mã của bạn ở một nơi khác? Không có vấn đề, chỉ cần kiểm tra nó. Tai nạn ổ cứng tại nhà? Không phải là một vấn đề (ít nhất là với mã nguồn của bạn).

Ngay cả khi bạn không sử dụng kiểm soát phiên bản ngay bây giờ, bạn có thể sẽ sử dụng nó tại một thời điểm sau này trong sự nghiệp của mình và bạn có thể hưởng lợi từ việc trở nên thoải mái hơn với các nguyên tắc ngay bây giờ.

Ngay cả làm việc một mình, điều này đã bao giờ xảy ra? Bạn chạy ứng dụng của mình và một cái gì đó không hoạt động và bạn nói "nó đã hoạt động vào ngày hôm qua và tôi thề rằng tôi đã không chạm vào lớp / phương thức đó." Nếu bạn đang kiểm tra mã thường xuyên, một phiên bản khác biệt nhanh sẽ hiển thị chính xác những gì đã thay đổi trong ngày qua.

Đây là một kịch bản có thể minh họa tính hữu ích của kiểm soát nguồn ngay cả khi bạn làm việc một mình.

Khách hàng của bạn yêu cầu bạn thực hiện một sửa đổi đầy tham vọng cho trang web. Bạn sẽ mất vài tuần và liên quan đến các chỉnh sửa cho nhiều trang. Bạn đi làm

Bạn đã hoàn thành 50% với nhiệm vụ này khi khách hàng gọi và yêu cầu bạn bỏ những gì bạn đang làm để thực hiện một thay đổi khẩn cấp nhưng nhỏ hơn cho trang web. Bạn chưa hoàn thành nhiệm vụ lớn hơn, vì vậy nó chưa sẵn sàng để phát hành và khách hàng không thể chờ đợi sự thay đổi nhỏ hơn. Nhưng anh ấy cũng muốn thay đổi nhỏ được sáp nhập vào công việc của bạn cho sự thay đổi lớn hơn.

Có thể bạn đang làm việc với nhiệm vụ lớn trong một thư mục riêng có chứa một bản sao của trang web. Bây giờ bạn phải tìm ra cách thực hiện thay đổi nhỏ theo cách có thể được triển khai nhanh chóng. Bạn làm việc giận dữ và hoàn thành nó. Khách hàng gọi lại với các yêu cầu sàng lọc thêm. Bạn cũng làm điều này và triển khai nó. Tất cả đều tốt.

Bây giờ bạn phải hợp nhất nó vào công việc đang tiến hành cho sự thay đổi lớn. Bạn đã thay đổi những gì cho công việc khẩn cấp? Bạn đã làm việc quá nhanh để ghi chú. Và bây giờ bạn không thể dễ dàng tìm thấy hai thư mục mà cả hai đều có thay đổi so với đường cơ sở mà bạn đã bắt đầu.

Kịch bản trên cho thấy kiểm soát nguồn có thể là một công cụ tuyệt vời, ngay cả khi bạn làm việc một mình.

• Bạn có thể sử dụng các nhánh để thực hiện các nhiệm vụ dài hạn và sau đó hợp nhất lại nhánh vào dòng chính khi hoàn thành.
• Bạn có thể so sánh toàn bộ các tập tin với các nhánh khác hoặc với các phiên bản trước đây để xem những gì khác nhau.
• Bạn có thể theo dõi công việc theo thời gian (rất phù hợp để báo cáo và lập hóa đơn theo cách này).
• Bạn có thể khôi phục mọi sửa đổi của bất kỳ tệp nào dựa trên ngày hoặc trên một cột mốc mà bạn đã xác định.

Đối với công việc solo, Subversion hoặc Git được khuyến khích. Bất cứ ai cũng được tự do thích cái này hay cái kia, nhưng rõ ràng là tốt hơn là không sử dụng bất kỳ điều khiển phiên bản nào. Những cuốn sách hay là " Kiểm soát phiên bản thực dụng bằng cách sử dụng Subversion, Phiên bản 2 " của Mike Mason hoặc " Kiểm soát phiên bản thực dụng bằng Git " của Travis Swicegood.

Tác giả gốc: Bill Karwin

Ngay cả khi một kiểm soát nguồn phát triển duy nhất cung cấp một lợi ích tuyệt vời. Nó cho phép bạn lưu trữ lịch sử mã của bạn và trở lại các phiên bản trước của phần mềm bất cứ lúc nào. Điều này cho phép bạn linh hoạt để thử nghiệm vì bạn luôn có thể khôi phục sang phiên bản khác của mã nguồn đang hoạt động.

Nó giống như có một nút "hoàn tác" khổng lồ hoàn toàn trở lại dòng mã đầu tiên của bạn.

Kiểm soát phiên bản gần như không thể sống mà không có sau khi bạn bắt đầu sử dụng nó. Không thể thiếu nếu có nhiều hơn một nhà phát triển đang làm việc trên cùng một cơ sở mã ... nhưng nó cũng khá hữu ích cho một nhà phát triển.

Nó theo dõi các thay đổi trong mã của bạn và cho phép bạn quay lại các phiên bản trước. Nó giải phóng bạn để thử nghiệm kiến ​​thức rằng nếu bất cứ điều gì phá vỡ bạn có thể hoàn tác các thay đổi của bạn.

Bạn có được bảo mật (theo nghĩa là sao lưu mã của bạn) và phiên bản mã của bạn (giả sử bạn có thói quen thực hiện các thay đổi thường xuyên). Cả hai đều là những điều rất tốt ngay cả khi không có ai khác làm việc với mã ...

Kiểm soát phiên bản rất tốt để kiểm tra các phiên bản trước, ngay cả khi bạn làm việc một mình. Ví dụ: nếu bạn vô tình xóa mã hoặc một tệp, bạn có thể lấy lại; hoặc bạn có thể so sánh các phiên bản trước để biết lý do tại sao một lỗi mới xuất hiện. Thật tốt nếu bạn là một người làm việc ở nhiều địa điểm.

Yêu thích cá nhân của tôi là git.

Có một số lý do để sử dụng kiểm soát phiên bản, ngay cả khi bạn là người duy nhất từng chạm vào mã.

• Sao lưu - nếu ổ cứng của bạn gặp sự cố thì sao? Bạn có một bản sao ở bất cứ đâu?
• Lịch sử sửa đổi - Hiện tại bạn có giữ các bản sao của mã trong các thư mục khác nhau không? Kiểm soát phiên bản cung cấp cho bạn khả năng theo dõi các thay đổi của bạn theo thời gian và dễ dàng tìm các bản sửa đổi khác nhau, hợp nhất, khôi phục các thay đổi, v.v. bằng cách sử dụng các công cụ.
• Chi nhánh - khả năng kiểm tra một số thay đổi, vẫn theo dõi những gì bạn đang làm và sau đó quyết định xem bạn có muốn giữ nó và hợp nhất vào dự án chính hay chỉ cần ném nó đi.

Nếu bạn giữ mã của mình dưới sự kiểm soát phiên bản, thì nó thực sự dễ dàng để xem các tệp bạn đã thay đổi (hoặc đã quên để thêm vào đường cơ sở).

Một cái gì đó mà không ai khác dường như đã đề cập rõ ràng là gắn thẻ hoặc ghi nhãn phát hành. Nếu bạn có ứng dụng khách sử dụng phiên bản 1 của phần mềm và bạn đang bận làm việc với phiên bản 2, bạn sẽ làm gì khi máy khách báo lỗi và bạn cần xây dựng phiên bản 1.1?

Một hệ thống kiểm soát nguồn sẽ cho phép bạn gắn nhãn cho mọi bản phát hành bạn thực hiện để bạn có thể quay lại sau, sửa lỗi (và hợp nhất bản sửa lỗi đó vào mã phiên bản 2 mới) và tạo một bản phát hành mới mà không lo rằng bạn có thể vô tình cung cấp thứ gì đó chưa sẵn sàng.

Kiểm soát nguồn là một phần cốt lõi của phát triển phần mềm hiện đại. Nếu bạn không sử dụng nó (ngay cả đối với các dự án cá nhân vì bạn càng có nhiều trải nghiệm tốt hơn) thì bạn đã làm sai điều gì đó.

Thông thường, một trong những câu hỏi đầu tiên tôi đặt ra khi được phỏng vấn xin việc là "Bạn sử dụng gì để kiểm soát nguồn?" Cho đến nay chỉ có một nơi đã nói "Không có gì" nhưng họ đã lên kế hoạch khắc phục rằng "Real ngay bây giờ ..."

Việc các nhà phát triển khác tham gia hay không hoàn toàn trực giao với nhu cầu của một hệ thống kiểm soát phiên bản.

Bạn có thể là nhà phát triển duy nhất nhưng vẫn sẽ được hưởng lợi từ:

• một dấu vết lịch sử của tất cả các thay đổi của bạn
• khả năng quay trở lại lịch sử đó
• khả năng thử nghiệm với nguồn và trong khi vẫn có phiên bản hoạt động (phân nhánh)
• một bản sao lưu (đặc biệt nếu bạn sử dụng một máy khác làm máy chủ kiểm soát nguồn và thậm chí nhiều hơn nếu máy đó được sao lưu thường xuyên)

Bây giờ, nếu bạn có một nhóm phát triển trên cùng một điều khiển phiên bản codebase thì vẫn cần thiết hơn

• mọi người có thể chỉnh sửa cùng một tệp cùng một lúc (tùy thuộc vào hệ thống cụ thể, nhưng hầu hết các tệp lành mạnh cho phép bạn làm điều này)
• bạn có thể cho biết ai đã làm gì với mã khi

Khi có nhiều người tham gia, nó sẽ phù hợp hơn với công cụ kiểm soát phiên bản nào bạn chọn, tùy thuộc vào phong cách phát triển.

Nó cũng là về sao lưu tập tin cũ rằng tại sao nó được gọi là "Subversion". Vì vậy, bạn có thể quản lý nhiều phiên bản công việc mà bạn có thể quay lại (hoàn nguyên) và quản lý việc triển khai khác nhau (phân nhánh).

Bạn có thể thấy rằng bạn đã có một phiên bản làm việc của chương trình của bạn.

Bạn quyết định thêm một vài tính năng mới trong một khoảng thời gian và bạn phát hành nó.

Bạn bắt đầu nhận được các báo cáo lỗi ảnh hưởng đến một số mã mà bạn nghĩ rằng bạn đã không chạm vào.

Ví dụ, bằng cách sử dụng SVN, bạn có thể quay lại phiên bản cũ hơn và kiểm tra xem lỗi mới có tồn tại không. Khi bạn tìm thấy một phiên bản giới thiệu lỗi, việc khắc phục nó sẽ dễ dàng hơn vì bạn có thể so sánh phiên bản hoạt động với những gì không hoạt động và xem những gì đã thay đổi, sau đó nó sẽ thu hẹp tìm kiếm.

Kiểm soát nguồn có nhiều cách sử dụng, ngay cả khi bạn là nhà phát triển duy nhất.

Âm thanh như bạn đang tìm kiếm một cái gì đó nhẹ hơn một chút. Kiểm tra Mercurial ( cuốn sách tham khảo tuyệt vời ). Tôi sử dụng nó cho tất cả mọi thứ, từ mã nguồn đến thư tín cá nhân.

Một số lợi ích:

• Nút Giant Undo, vì vậy bạn có thể trả lại những ngày halcyon của tuần trước khi mã thực sự chạy
• Mã vứt đi. Không chắc chắn nếu đây là cách tốt nhất để làm một cái gì đó? Tạo một nhánh và thử nghiệm. Không ai ngoài bạn phải biết về nó nếu bạn đang sử dụng DVCS như đồng bóng.
• Phát triển đồng bộ hóa. Tôi phát triển trên 4 máy tính khác nhau. Tôi đẩy và kéo giữa chúng để giữ hiện tại, vì vậy bất kể tôi đang ở phiên bản nào mới nhất.

Ngay cả khi bạn chưa ở trong tình huống cần đến phiên bản cũ hơn của chương trình, việc kiểm soát nguồn giúp bạn tự tin hơn để thực hiện các thay đổi lớn.

Tôi thấy mình thực hiện tái cấu trúc mạnh mẽ hơn sau khi sử dụng kiểm soát nguồn vì tôi luôn biết rằng phiên bản hoạt động có thể dễ dàng khôi phục.

Tôi cũng chỉ mới bắt đầu quan tâm đến việc kiểm soát phiên bản. Trong các hệ thống kiểm soát phiên bản, bạn có khái niệm về một kho lưu trữ cho mã của mình. Rất nhiều lệnh shell mới được học rất nhanh để bạn có thể tương tác với kho lưu trữ này.

Khi bạn lưu mã của mình vào một tệp, bạn có thể cam kết điều này với kho lưu trữ của dự án. Khi bạn phát triển mã của mình và cam kết thay đổi, kho lưu trữ sẽ phát triển một loạt các sửa đổi . Bạn có thể truy cập bất kỳ trong số này bằng cách kiểm tra sửa đổi. Nếu bạn làm việc một mình, bạn sẽ không thể kiểm tra nhiều trừ khi bạn mất các tệp mã hoặc muốn làm việc trên một máy khác. Trong những trường hợp này, bạn thường sẽ kiểm tra phiên bản mới nhất của tất cả các tệp.

Về phần mình, tôi không còn giữ các tệp hoặc thư mục có tên 'project_old' khi tôi quyết định cấu trúc lại một cái gì đó. Mọi thay đổi tôi thực hiện đều được lưu trữ tăng dần và tôi sẽ luôn có thể lùi lại một dự án hoạt động như một tổng thể. Tôi hiếm khi sử dụng FTP để triển khai ngay bây giờ vì tôi chỉ kiểm tra mã của mình thông qua ssh. Chỉ các tệp tôi đã thay đổi được tải xuống và nếu tôi cần tải lại trên máy chủ thì thiết bị đầu cuối đã ở đó.

Tôi thấy bài nói chuyện này trên GIT thực sự mang tính hướng dẫn; http://www.youtube.com/watch?v=4XpnKHJAok8

Đó là một cuộc nói chuyện trên google nơi Linus Torvalds đưa ra lập luận cho việc sử dụng một hệ thống kiểm soát phiên bản trên một hệ thống khác. Khi làm như vậy, ông giải thích cách họ làm việc bằng cách sử dụng các khái niệm và sau đó so sánh các cách khác nhau để thực hiện chúng.

Bạn có thể muốn một cái gì đó như lật đổ ngay cả khi bạn đang làm việc một mình để bạn có lịch sử về tất cả các thay đổi của mình. Bạn có thể muốn xem một đoạn mã trông như thế nào để nhớ tại sao bạn thực hiện một thay đổi.

Kiểm soát nguồn cũng hữu ích khi bạn đăng ký thường xuyên. Nếu bạn đăng ký thường xuyên, bạn cũng sẽ luôn ở trong trạng thái quay lại thường xuyên. Nhiều lần bạn có thể bắt đầu đi xuống một con đường để giải quyết vấn đề và sau đó nhận ra đó là con đường sai lầm để đi. Nhiều lần bạn chỉ có thể sủa xuống con đường sai lầm và cuối cùng xây dựng một giải pháp khủng khiếp - chỉ vì bạn không muốn mất tất cả công việc của mình. Bằng cách kiểm tra thường xuyên, điểm cuối cùng của "hạnh phúc" không còn xa nữa, ngay cả khi bạn đi sai đường, bạn luôn có thể quay lại và thử lại và đưa ra một giải pháp đơn giản và thanh lịch hơn. Đó luôn là một điều tốt để bạn có thể hiểu và duy trì những gì bạn đã viết trong tương lai.

Nó phụ thuộc vào quy mô của dự án và tần suất bạn thay đổi suy nghĩ về các phần của dự án. Đối với các dự án nhỏ mà bạn vừa hoàn thành công việc theo kiểu tuyến tính, kiểm soát phiên bản có thể sẽ không giúp ích nhiều (mặc dù nếu bạn vô tình xóa hoặc làm hỏng tệp mà không kiểm soát phiên bản, bạn sẽ khóc).

Nhưng một vài tuần trước, tôi đã gặp một người bạn đang tự mình viết một dự án sở thích to lớn. Anh ta có mười hoặc hai mươi bản mã của mình, với các hậu tố như "X1", "X2", "test", "nhanh hơn", v.v.

Nếu bạn đã tạo nhiều hơn hai bản sao mã của mình, bạn cần kiểm soát phiên bản . Một hệ thống kiểm soát phiên bản tốt cho phép bạn hoàn tác một thay đổi bạn đã thực hiện trước đây mà không hoàn tác những gì bạn đã làm sau khi thực hiện thay đổi đó. Nó cho phép bạn nhìn thấy khi những thay đổi nhất định được thực hiện. Nó cho phép bạn chia mã của mình thành hai "đường dẫn" (ví dụ: một để thử nghiệm một ý tưởng mới, còn lại để giữ mã "đã thử và tin cậy" của bạn cho đến khi bạn hoàn thành thử nghiệm) và sau đó hợp nhất chúng lại với nhau.

Đó là năm 2019. Tôi đang gặp phải sự phản đối, vào ngày cuối tương đối này, để sử dụng Git; phản đối tôi thấy một số nâng cao ở đây. Thảo luận này đã làm rõ rất nhiều sự bắt buộc của việc sử dụng kiểm soát nguồn thay vì chỉ đơn giản là tạo các bản sao dự phòng có tên. Một điểm quan trọng là sử dụng kiểm soát nguồn ngay cả khi chúng tôi đã phát triển các dự án duy nhất. Không ai là hoàn hảo cả. Bạn mắc lỗi. Nếu bạn đặc biệt giỏi và thông minh, bạn sẽ phát triển các ứng dụng phức tạp hơn; nhưng bạn vẫn sẽ phạm một số sai lầm và điều này xử lý nó. Ôi trời ơi! Tôi không bao giờ sử dụng Linux nhưng tôi nghĩ tất cả chúng ta đều tôn trọng trí thông minh kỹ thuật tuyệt vời của Linus Torvalds. Ông nhận ra tầm quan trọng của kiểm soát nguồn và ông đã đóng góp quan trọng cho sự ra đời của Git. Đó là một điểm tóm tắt cho tất cả các lý do được đưa ra ở đây. Torvalds hiểu điều đó: kiểm soát nguồn rất quan trọng: sử dụng kiểm soát nguồn. Cảm ơn tất cả những người đã bình luận về chủ đề dài này.