Làm thế nào để các nhà phát triển ứng dụng chuyên nghiệp sử dụng các hệ thống kiểm soát phiên bản, như GIT và Subversion?


9

Tôi là một nhà phát triển mới bắt đầu và tôi đã tự hỏi từ đầu, làm thế nào để sử dụng các công cụ chuyên nghiệp như GIT và Subversion (Tôi không hiểu rõ về các công cụ này), để đáp ứng nhu cầu của dự án của họ. Nếu họ sử dụng nó, làm thế nào tôi có thể thiết lập một cái gì đó như thế?

Các ứng dụng của tôi không quá lớn và tôi chưa làm việc trong một nhóm, chúng có giúp ích gì cho tôi không?

Có những câu hỏi trên trang web này về cách sử dụng các công cụ, nhưng tôi cần hỗ trợ cho người mới bắt đầu.


5
Git và Subversion đi kèm với hướng dẫn; về cơ bản chúng là một kho lưu trữ mã phát triển theo cách có cấu trúc. Các nhà phát triển cá nhân được hưởng lợi từ việc có một bản ghi đầy đủ các thay đổi mã và một cơ sở sao lưu mạnh mẽ. Các nhóm dự án được hưởng lợi từ khả năng chia sẻ cùng một kho lưu trữ mã nguồn, giữ các thay đổi đồng bộ giữa các máy trạm.
Robert Harvey

Câu trả lời:


13

Kiểm soát nguồn rất phổ biến - người ta thậm chí có thể nói rằng bạn không thể tự gọi mình là nhà phát triển chuyên nghiệp nếu bạn không sử dụng nó. Ngay cả khi phát triển một mình, kiểm soát nguồn vẫn cung cấp khá nhiều lợi ích. Cuối cùng, nó cung cấp cả một lịch sử và một con đường hoàn tác rộng lớn. Nó cũng giải phóng bạn để thử nghiệm nhiều hơn nữa, an toàn với kiến ​​thức rằng nếu bạn không thích phiên bản mới, bạn luôn có thể chuyển về những gì bạn đã có trước đây.

Điều đó nói rằng, quy trình làm việc, ngay cả trong một hệ thống kiểm soát nguồn như Subversion hoặc Git, rất khác nhau giữa các nhóm. Nơi tốt nhất để bắt đầu có lẽ là chọn một hệ thống kiểm soát nguồn và làm quen với quy trình làm việc tiêu chuẩn của nó (giữ trong đầu rằng bạn sẽ phải chuyển đổi quy trình công việc trong suốt cuộc đời chuyên nghiệp của mình).

Để bắt đầu, tôi muốn giới thiệu Git. Tôi là một người hâm mộ Git, nhưng cụ thể hơn là chọn Git cho phép bạn bắt đầu bằng cách làm việc không có máy chủ và chỉ thiết lập một máy chủ khi nó có ý nghĩa với bạn. Subversion, mặt khác, yêu cầu một máy chủ và thiết lập một, trong khi không phải là cực kỳ khó khăn, là khó khăn khi bạn không quen thuộc với loại điều đó.

Dưới đây là một tổng quan tốt về một số quy tắc tốt về kiểm soát nguồn nói chung: http : // sc Bông Writing.net/sowblog/archive/2008/11/13/163320.aspx

Khi làm việc một mình, bạn không cần nhiều quy trình làm việc. Cam kết sớm, cam kết thường xuyên. Nếu bạn bắt đầu tung ra các phiên bản, hãy gắn thẻ bản phát hành của bạn. Tạo các nhánh cho các thử nghiệm hoặc công việc phân kỳ dài (Git làm cho việc này rẻ hơn và đơn giản hơn Subversion không).


1
Câu trả lời tốt ngoại trừ một điểm. Tôi chắc chắn sẽ không chọn máy chủ cần lật đổ vì đó là nhược điểm lớn nhất, một phần vì tôi thực sự đã sử dụng nó mà không thường xuyên sử dụng nó; kho lưu trữ có thể sống trong thư mục cục bộ và hơn thiết lập là một lệnh đơn. Sự khác biệt chính giữa Git và Subversion là các hệ thống phân tán như Git linh hoạt hơn nhiều so với các hệ thống tập trung như Subversion.
Jan Hudec

5

Các hệ thống kiểm soát nguồn (SVN, Git, v.v.) ở mức độ rất đơn giản cho phép bạn giữ lịch sử thay đổi của các tệp. Điều này cho phép bạn xem cách mã của bạn thay đổi theo thời gian và khôi phục các thay đổi mà bạn có thể không muốn (ví dụ: thay đổi không hoạt động như mong đợi, bạn có thể hoàn nguyên mã về trạng thái đã biết trước đó). Đây là thứ mà thậm chí tự phát triển sẽ trở nên vô giá đối với bạn một khi bạn bắt đầu sử dụng nó.

Ngay khi bạn làm việc với những người khác trong một nhóm, lợi ích sẽ tăng lên nhiều hơn vì nhiều người có thể thay đổi cùng một tệp và nếu các thay đổi không xung đột (ví dụ: 2 người thay đổi các phần khác nhau của tệp), các thay đổi sẽ được hợp nhất tự động. Nếu có bất kỳ xung đột nào thì bạn sẽ có thể thấy những thay đổi của mình bên cạnh đồng nghiệp và thảo luận với họ về cách hợp nhất các thay đổi.

Bạn cũng có thể tạo ảnh chụp nhanh của cơ sở mã (thường được gọi là thẻ) khi phát hành phiên bản mã để bạn có thể dễ dàng gỡ lỗi các vấn đề ngay cả khi nguồn chính đã chuyển sang các tính năng mới chưa được phát hành.

Dưới đây là một vài tài nguyên hữu ích:

Bắt đầu và chạy Subversion và Rùa SVN với Visual Studio và .NET

Kiểm soát phiên bản với Subversion


1
Không cho +1, vì học Subversion như hệ thống đầu tiên là loại hình trái ngược với những ngày này khi mọi người đang chuyển sang hệ thống phân tán.
Jan Hudec

3

Hướng dẫn cho người mới bắt đầu

Có những hướng dẫn tuyệt vời (video và văn bản) có thể giúp bạn bắt đầu từ cấp độ rất cơ bản. Git dường như có một cách tiếp cận tuyệt vời để giới thiệu chủ đề một cách nhẹ nhàng cho người mới bắt đầu, cho bạn biết lý do tại sao trước tiên và sử dụng sự lặp lại, định nghĩa và đồ họa để giúp bạn nhớ tên và chức năng của các lệnh chính.

SVN

SVN dự định là CVS được thực hiện tốt hơn. CVS (Hệ thống phiên bản đồng thời) hoạt động trên những thứ một tệp tại một thời điểm, SVN thường làm việc trên những thứ mà một thư mục hoặc cây thư mục tại một thời điểm. SVN (và CVS hoặc các hệ thống khác) có thể quan trọng nếu bạn đang sử dụng nó tại nơi làm việc, nhưng ý kiến ​​của tôi là chúng tôi cải thiện đáng kể sự hiểu biết của chúng tôi về việc kiểm soát nguồn mỗi vài năm, vì vậy bạn sẽ thích mô hình muộn hơn máy tính, bạn nên thích một công cụ kiểm soát nguồn mô hình muộn. Đó là một khoản đầu tư lớn để thay đổi hệ thống và lịch sử mã có thể bị mất, mặc dù đối với nhiều hệ thống, có các bộ chuyển đổi cho phép bạn di chuyển mã của mình cũng như lịch sử và các tạo phẩm khác do hệ thống tạo ra.

Kiểm soát nguồn chuyên nghiệp Đáp ứng nhu cầu chuyên nghiệp

Câu hỏi của bạn "Làm thế nào để sử dụng các công cụ chuyên nghiệp như GIT và Subversion để đáp ứng nhu cầu của dự án của họ?" liên quan chặt chẽ đến câu hỏi "Làm thế nào để các nhóm làm việc cùng nhau mà không gặp nhau trong khi vẫn làm việc nhanh nhất có thể?"

Mã đang thay đổi thường xuyên với một số nhà phát triển tạo mã mà các nhà phát triển khác sẽ sử dụng và với nhiều bên liên quan cần mức độ ổn định khác nhau so với đổi mới. Các hệ thống kiểm soát nguồn giúp đỡ bằng cách lưu trữ mã để nhóm sử dụng, giữ cho mỗi thay đổi trong bối cảnh với các phiên bản thay đổi theo thời gian và thường với các nhánh được kiểm soát các bản sao của mã phục vụ để tách các nhóm thay đổi khỏi các nhóm thay đổi khác.

Mang mọi thứ lại với nhau, hợp nhất công việc của nhiều thành viên trong nhóm là một việc vặt trong SVN và các hệ thống cũ hơn là tập trung và khó khăn. Đối với các nhóm sử dụng Git, việc hợp nhất trở nên đơn giản và dễ tiếp cận hơn với ảnh hưởng của toàn đội thay vì một vài chuyên gia. Ở SVN, việc phân nhánh có thể là vấn đề cá nhân, nhưng việc sáp nhập thường gây ra những tác động đau đớn cho đội và việc chuyển mã trở lại dòng chính có thể gây đau đớn từ góc độ xin phép, tránh bị phá vỡ và mức độ nỗ lực cần có nhiệm vụ .

Từ một kho lưu trữ kiểm soát nguồn được thiết lập, các chuyên gia có thể đáp ứng các nhu cầu khác như chẩn đoán các vấn đề cho nguyên nhân gốc rễ của họ. Nếu có các phiên bản mã đã từng hoạt động và các sự cố mới được tìm thấy xảy ra trong phiên bản hiện tại, có thể bước tới và lùi lại trong lịch sử để xác định chính xác khi sự cố xảy ra. Trong SVN, khả năng này là chưa trưởng thành, nhưng trong Git, việc tìm kiếm phiên bản làm việc / thất bại đầu tiên cuối cùng được hỗ trợ bởi một lệnh gọi là git bisect. Vấn đề sẽ được gây ra bởi một trong những thay đổi nguồn giữa hai phiên bản có khả năng chẩn đoán dễ dàng hơn nhiều so với tìm kiếm toàn bộ cơ sở mã.

Xin lỗi để lan man, hy vọng điều này sẽ giúp bạn trên con đường sử dụng kiểm soát nguồn.


0

Nhóm của tôi sử dụng hệ thống kiểm soát phiên bản nhóm phát triển tại nhà. (Đáng buồn thay, Git dường như chưa hoạt động trên các tệp nguồn "i" bản địa của IBM) đội VCS.

Như họ nói trong việc bỏ phiếu ... cam kết sớm, cam kết thường xuyên. Khi tôi làm việc trên các tính năng mới, tôi cam kết. Tôi cam kết giữa các biên dịch và tại mỗi lần thử sửa lỗi trình biên dịch, mỗi lần tôi thực hiện các thay đổi trong quá trình kiểm tra và gỡ lỗi. Điều này cho phép đơn giản hơn để thử một số biến thể trên một chủ đề và dễ dàng thoát ra khỏi nó nếu cần, đặc biệt là khi một thay đổi được phối hợp trên một số tệp.

Git đã cải thiện cách tôi tiếp cận phát triển.


'Git dường như chưa hoạt động trên các tệp nguồn i "gốc" của IBM)' - Git nên hoạt động trên bất kỳ tệp nào. Vấn đề ở đây là gì?
Marnen Laibow-Koser

@ MarnenLaibow-Koser Hầu hết các nhà phát triển IBM i đang làm việc với các tệp nguồn với cái mà chúng ta có thể gọi là hệ thống tệp gốc (di sản) QSYS, nơi các tệp nguồn có định dạng độ dài cố định tích hợp. Mỗi dòng bắt đầu bằng một số thứ tự 6 chữ số, ngày thay đổi 6 chữ số, sau đó là dòng văn bản mã nguồn. Trình tự và ngày thay đổi có thể thay đổi ngay cả khi mã nguồn trên một dòng không thay đổi. Các giải pháp có thể đã được phát triển gần đây. IBM và những người khác hiện đang hỗ trợ git trên IBM i. Và nó không phải là một vấn đề với nguồn trong các tệp luồng "bình thường" trong các hệ thống tệp IFS khác trên IBM i.
WarrenT

Ôi Chúa ơi, tôi mơ hồ nhớ rằng từ việc phát triển AS / 400 cách đây 20 năm. Nhưng tôi không có lý do, tôi nghĩ rằng Git sẽ không hoạt động với các tệp như vậy. Bạn có thể cần phải viết trình điều khiển hợp nhất giảm giá các số dòng, nhưng điều đó rất dễ thực hiện. (Tôi tự hỏi nếu đó là những gì IBM đã làm ...)
Marnen Laibow-Koser

Nhưng, nếu bạn loại bỏ số dòng và ngày thay đổi dòng, thì bạn đã mất chúng khi bạn kiểm tra lại một cái gì đó từ Git. Không dễ để thuyết phục một số người rằng họ không còn cần những cuộc hẹn hò đó nữa, sau khi dựa vào họ trong khoảng 3 thập kỷ. Vâng, tôi biết Git đổ lỗi cung cấp điều tương tự, nhưng mọi người không muốn từ bỏ thứ gì đó mà họ đã phụ thuộc quá lâu, ngay cả khi đó không nhất thiết là một lập luận hợp lý.
WarrenT

Bạn thực sự có thể tạo bộ lọc Git sạch / smudge để khôi phục ngày từ đổ lỗi Git. :)
Marnen Laibow-Koser
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.