Tôi đang bắt đầu với SVN. Tôi biết các lệnh cơ bản và hiểu các nguyên tắc cơ bản. Tôi đã tự hỏi liệu có ai có bất kỳ mẹo hoặc phương pháp hay nhất nào để làm việc với Subversion trong môi trường nhóm không.
Tôi có thể thấy lợi ích của việc thêm các thông báo dài hợp lý khi cam kết mã, nhưng có những điều nào khác mà tôi nên lưu ý không?
Cảm ơn vì tất cả những câu trả lời tuyệt vời - họ đã giúp ích rất nhiều.
Câu trả lời:
Khuyến khích cam kết thường xuyên. Các đồng đội mới sử dụng quyền kiểm soát phiên bản có thể cảm thấy như họ cần giữ mã ngoài kho lưu trữ cho đến khi "nó hoạt động bình thường". Hướng dẫn mọi người cam kết sớm và thường xuyên để tìm ra vấn đề càng sớm càng tốt. Thay vì giữ mã 'cho đến khi nó hoạt động, hãy đề xuất đồng đội của bạn tạo các nhánh cho tính năng có thể phá vỡ thân cây. Dẫn đến...
Thiết lập thực hành phân nhánh và gắn thẻ. Ngoài các nhánh cho các tính năng, hãy khuyến khích đồng đội của bạn sử dụng các nhánh để sửa các lỗi lớn. Gắn thẻ các bản sửa lỗi chính vào đầu và cuối tác phẩm. Duy trì các thẻ (và có thể là các chi nhánh) cho các bản phát hành sản xuất / qa.
Thiết lập một chính sách cho thân cây và bám sát nó. Một ví dụ có thể là, "thân cây phải luôn được xây dựng mà không có lỗi." hoặc "thân cây phải luôn vượt qua tất cả các bài kiểm tra đơn vị". Bất kỳ công việc nào chưa thể đáp ứng các tiêu chuẩn của thân cây phải được thực hiện trong một chi nhánh.
Không cam kết thay đổi định dạng với thay đổi mã
Nếu bạn muốn cấu trúc lại khoảng trắng của một tệp khổng lồ (Control + K+ D), tốt thôi. Cam kết thay đổi định dạng tách biệt với thay đổi logic thực tế. Tương tự nếu bạn muốn di chuyển các chức năng trong tệp. Cam kết việc di chuyển tách biệt với việc chỉnh sửa thực tế.
Một trong những khái niệm chính mà tôi luôn gắn bó là thực hiện các thay đổi mã liên quan cùng nhau . Hệ quả tất yếu là đừng commit những thay đổi mã không liên quan trong cùng một commit . Điều này có nghĩa là không sửa 2 lỗi trong một lần cam kết (trừ khi đó là cùng một bản sửa lỗi) và không sửa một nửa lỗi trong mỗi 2 lần cam kết. Ngoài ra, nếu tôi cần thêm một số cải tiến mới hoặc thứ gì đó vào một phần không liên quan của hệ thống mà sau đó tôi cần cho một số công việc khác, tôi cam kết cải tiến riêng (và trước tiên). Ý tưởng là bất kỳ thay đổi nào mà bất kỳ ai cũng có thể hình dung muốn tự thực hiện (hoặc tự quay trở lại) phải là một cam kết riêng. Nó sẽ giúp bạn đỡ phải đau đầu khi cần hợp nhất hoặc khôi phục các tính năng bị hỏng.
Rất nhiều thứ đã được đề cập và đây là một số khác:
Nếu bạn có các tệp mà bạn không muốn trong kiểm soát nguồn (ví dụ: cấu hình, tệp đã biên dịch, v.v.), hãy thêm chúng vào danh sách bỏ qua . Bằng cách này, bạn sẽ nhận thấy bất kỳ tệp nào mà bạn quên thêm vào bằng cách luôn mong đợi một danh sách trống các tệp hiển thị là không xác định cho SVN.
Thêm một sự kiện cam kết đăng sẽ gửi email đến danh sách gửi thư nhà phát triển của bạn (hoặc một sự kiện cụ thể cho mục tiêu này) liên quan đến thay đổi đã cam kết và lý tưởng là bản vá cho nó.
Tích hợp với trình theo dõi lỗi của bạn để các tham chiếu đến cam kết hiển thị trên các yêu cầu về lỗi / tính năng với các liên kết đến các điểm khác biệt. Các trình theo dõi lỗi như MantisBT hỗ trợ điều này.
Cân nhắc tích hợp với tích hợp liên tục (ví dụ: CruiseControl.NET ), NAnt cho Bản dựng và NUnit / VS cho các bài kiểm tra đơn vị. Bằng cách này sau khi người dùng đăng ký mã hoặc trong một khoảng thời gian đã lên lịch, mã được biên dịch, các bài kiểm tra đơn vị được chạy và nhà phát triển nhận được phản hồi về quy trình. Điều này cũng sẽ cảnh báo cho phần còn lại của nhóm nếu kho lưu trữ bị hỏng (tức là không xây dựng).
Vâng, những điều cơ bản:
Những câu trả lời mà mọi người đang đưa ra rất tuyệt vời. Phần lớn nội dung này được tóm tắt trong tài liệu người dùng svn để biết các phương pháp hay nhất cho SVN .
Lặp lại:
Tôi muốn tóm tắt các phương pháp hay nhất mà tôi tuân thủ:
Cần có cấu trúc kho lưu trữ . Cá nhân tôi sử dụng cấu trúc kho lưu trữ sau:
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
PA(pre-alpha), A(alpha), B(beta), AR(alpha-release), BR(beta-release), RC(phát hành ứng viên), ST(ổn định).Bạn có thể tìm thấy phác thảo về các phương pháp hay nhất về lật đổ của tôi dưới dạng sơ đồ minh họa các nguyên tắc chính của phương pháp quản lý cấu hình phần mềm mà tôi sử dụng.
Một điều tôi thấy rất hữu ích là thuộc tính svn: external có nghĩa là bạn có thể tham chiếu các thư mục từ các kho khác thành của riêng bạn. Nó cung cấp những cách thực sự tốt để tổ chức mã và dữ liệu của bạn. Một số ví dụ:
Sử dụng tích hợp với phần mềm theo dõi lỗi của bạn. Nếu bạn sử dụng Bugzilla , bạn có thể thiết lập nó để nếu nhận xét của bạn bắt đầu bằng "Lỗi XXXX", nhận xét SVN của bạn sẽ tự động được thêm vào dưới dạng nhận xét cho lỗi đã cho, bao gồm một liên kết đến giao diện web SVN của bạn tới bản sửa đổi đó.
Tìm hiểu về các công cụ và quy ước phân nhánh và hợp nhất của SVN.
Cách tốt nhất để làm việc với các thành viên khác trong nhóm là chia nhỏ công việc thành các bản sửa lỗi / tính năng phát triển hoàn chỉnh, sau đó thực hiện các thay đổi riêng lẻ, mỗi người trong một nhánh. Sau đó hợp nhất các thay đổi trở lại chi nhánh / đường trục chính khi hoàn thành / sẵn sàng / được chấp thuận để được hợp nhất.
Bằng cách này, các cá nhân có thể hướng tới một mục tiêu chung (trên cùng một nhánh hoặc các nhánh riêng biệt) mà không bị ảnh hưởng bởi những thay đổi khác.
Số dặm của bạn có thể thay đổi và điều này có thể quá mức cần thiết đối với chỉ hai người hoặc lâu hơn.
Nó sẽ dễ dàng hơn nhiều nếu bạn đang sử dụng các công cụ tốt tích hợp tốt với SVN. Những điều này giúp bạn dễ dàng xem những gì đã được thay đổi và sau đó cam kết tất cả hoặc một phần các thay đổi của bạn và thường xuyên cập nhật bản sao làm việc của bạn lên phiên bản mới nhất trong SVN.
Tôi đề xuất Tortoise SVN (Nếu bạn đang sử dụng Windows) và Visual SVN (nếu bạn đang sử dụng VS).
Ngoài ra, hãy xem liệu bạn có thể thiết lập nó để bạn nhận được e-mail hoặc thông báo tương tự bất cứ khi nào có thay đổi được cam kết hay không (thường cũng bao gồm thông báo cam kết và danh sách các tệp đã thay đổi). Các dịch vụ như CVSDude cung cấp điều này. Tôi thấy hữu ích khi biết cả bản cập nhật đã được thực hiện và sau đó có một số ý tưởng về những gì có trong bản cập nhật đó trước khi cập nhật bản sao làm việc của tôi.
Bên cạnh các chính sách phân nhánh et al. (trong đó một kích thước chắc chắn không phù hợp với tất cả), bạn nên có cam kết tốt:
Quy tắc vàng để kiểm soát nguồn: Đăng ký sớm, Đăng ký thường xuyên
Để biết các mẹo về cách tổ chức kho lưu trữ của bạn:
Tham khảo ý kiến với nhóm của bạn về các thay đổi của họ hoặc ít nhất là xem xét sự khác biệt rất cẩn thận, trước khi khắc phục bất kỳ xung đột hợp nhất nào. Yêu cầu họ tự xem lại mã đã hợp nhất để đảm bảo rằng phần bổ sung của họ không bị mất trong quá trình hợp nhất.
Một điều mà tôi đã thấy rằng làm giảm các cam kết bị hỏng là có các tập lệnh pre-commit tốt. Ví dụ: bạn có thể chạy bất kỳ bài kiểm tra đơn vị nào trước khi thay đổi được cam kết. Điều này sẽ khiến việc cam kết bị chậm lại một chút, nhưng bạn tiết kiệm thời gian bằng cách tránh dẫm lên chân người khác và phải xin lỗi. Tất nhiên điều này sẽ trở nên khó quản lý hơn rất nhiều khi bạn có một nhóm phát triển lớn và cam kết rất thường xuyên.
Một trong những ví dụ về tích hợp với trình theo dõi lỗi và thực thi chính sách cam kết có thể là tập lệnh hook trước / sau cam kết của Trac 's svn, có thể từ chối cam kết nếu thông báo cam kết không tham chiếu đến bất kỳ vé nào trong trình theo dõi lỗi và thêm nhận xét vào hiện có vé dựa trên nội dung tin nhắn (tức là tin nhắn cam kết có thể chứa những thứ như "Bản sửa lỗi # 1, # 2 và # 8", trong đó # 1, # 2, # 8 là số vé).
Phương pháp hay nhất để sử dụng SVN :
Khi lần đầu tiên bạn đến văn phòng và mở dự án Eclipse của mình , bước đầu tiên phải thực hiện là cập nhật dự án của bạn.
Sau khi cập nhật, hãy bắt đầu công việc của bạn. Khi bạn hoàn thành quá trình viết mã của mình, hãy kiểm tra xem ứng dụng của bạn có chạy đúng cách hay không mà không có bất kỳ ngoại lệ nào. Một khi bạn chắc chắn rằng mã của mình đang hoạt động tốt, đã đến lúc bạn cần xác nhận mã.
Lưu ý: Trong khi cam kết mã, không cam kết trực tiếp. Thực hiện đồng bộ hóa với máy chủ và kiểm tra tất cả những gì cần được cam kết. Lưu ý: Không cam kết toàn bộ thư mục một lần. Bởi vì bạn có thể đã thực hiện một số thay đổi đối với tệp theo yêu cầu của mình hoặc bạn có thể đã xóa một số tệp trong hệ thống cục bộ của mình. Nhưng các cài đặt khác nhau trên máy chủ. Vì vậy, hãy kiểm tra các tệp riêng lẻ và cam kết mã.
Không cam kết / cập nhật trực tiếp các tệp xung đột.
Khi nào cần ghi đè và cập nhật?
Khi bạn chắc chắn rằng bạn không cần bất kỳ thay đổi cục bộ nào và muốn cập nhật toàn bộ bản sao máy chủ. Lưu ý rằng một khi nếu bạn thực hiện ghi đè và cập nhật, bạn sẽ không nhận được bất kỳ thay đổi cục bộ nào của mình.
Lưu ý: Đừng giữ dự án mà không cập nhật trong hơn một ngày. Cũng đừng giữ mã mà không cam kết trong nhiều ngày.
Giao tiếp với những người đang làm việc trong cùng một bộ phận và thảo luận về những thay đổi họ đã thực hiện hàng ngày.
Không cam kết các thuộc tính và tệp cấu hình trừ khi có lý do nào đó. Vì cài đặt sẽ khác nhau trên máy chủ và trên đám mây.
Không đưa các thư mục đích vào SVN, chỉ mã nguồn và các thư mục tài nguyên phải được duy trì trong kho lưu trữ SVN.
Khi bạn bị mất mã, đừng hoảng sợ! Bạn có thể lấy lại bản sao trước đó từ lịch sử SVN.
Đừng kiểm tra dự án vào nhiều nơi trên đĩa của bạn. Kiểm tra nó ở một vị trí và làm việc với nó.
Bản thân SVN là một khởi đầu tốt và một số áp phích khác đã đưa ra một số gợi ý tuyệt vời về các phương pháp hay nhất.
Điều duy nhất tôi muốn nói thêm là bạn nên kết nối SVN với CruiseControl hoặc TeamCity để thúc đẩy quá trình Tích hợp liên tục. Thao tác này sẽ gửi email bản dựng và cho mọi người biết khi ai đó đã phá bản dựng.
Nó sẽ sớm cho biết ai đang theo dõi quy trình của bạn và ai không. Có thể dẫn đến một số xích mích nhưng nhóm của bạn sẽ tốt hơn về lâu dài.
Nhận xét chính xác cho mọi cam kết
Đừng phá vỡ cấu trúc (dòng chính)!
Cam kết ngay sau khi một đơn vị logic thay đổi
Tránh sử dụng Subversion làm công cụ sao lưu
Phân nhánh / hợp nhất một chút càng tốt
.
Có thể tìm thấy thêm chi tiết trong các phương pháp hay nhất của SVN .
Hãy nhớ rằng bạn thực hiện cam kết càng gia tăng, theo mô-đun, rời rạc và ngắn gọn, bạn (hoặc có thể là những người khác) càng dễ dàng:
Sử dụng cái này cho mẫu nhận xét:
[nhiệm vụ / câu chuyện xxx] [nhỏ / lớn] [bình luận] [theo dõi bình luận] [URL đến lỗi]