Quy ước đặt tên tốt cho các chi nhánh được đặt tên trong {DVCS} theo lựa chọn của bạn


16

Chúng tôi đang tích hợp Mercurial từ từ trong văn phòng của chúng tôi và thực hiện phát triển web, chúng tôi bắt đầu sử dụng các chi nhánh được đặt tên.

Chúng tôi đã không tìm thấy một quy ước tốt như đặt tên các chi nhánh của chúng tôi mặc dù.

Chúng tôi đã cố gắng:

  • FeatureName (Có thể thấy điều này gây ra sự cố xuống dòng)
  • DEVInitial_FeatureName (Có thể gây nhầm lẫn khi nhà phát triển đến và đi xuống dòng)
  • {uniqueID (int)} _ Tính năng

Cho đến nay, uniqueID_featureName đang chiến thắng, chúng tôi đang nghĩ đến việc duy trì nó trong một DB nhỏ chỉ để tham khảo.

Nó sẽ có: BranchID (int), FeatureName (varchar), FeatureDes mô tả (varchar), ngày, ai v.v ...

Điều này sẽ cung cấp cho chúng tôi các nhánh như: 1_NewWhizBangFeature, 2_NowWithMoreFoo, ... và chúng tôi sẽ có một tài liệu tham khảo dễ dàng về những gì chi nhánh đó làm mà không phải kiểm tra nhật ký.

Có giải pháp nào tốt hơn không?

Câu trả lời:


14

Nếu bạn không có trình theo dõi sự cố, tôi khuyên bạn nên thiết lập một trình theo dõi và sau đó sử dụng {tên trình theo dõi vấn đề} _ {số vé}. Khi một người nào đó từ bây giờ phát sinh lỗi và bạn không biết chính xác tính năng này hoạt động như thế nào, bạn sẽ dễ dàng chú thích tệp và quay lại nơi người dùng có thể đã yêu cầu chức năng chính xác đó.


Đồng ý rằng chúng tôi có một bugtracker và đang có kế hoạch sử dụng bugID trong tên chi nhánh để sửa lỗi. Câu hỏi của tôi là nhiều hơn cho sự phát triển hoàn toàn mới, khi bạn không sửa chữa bất cứ điều gì ngoài việc thêm một cái gì đó hoàn toàn mới. Tôi cho rằng chúng ta có thể tạo ra một vé tăng cường câm và đi từ đó.
jfrobishow

5
Bạn hoàn toàn nên tạo vé cho các tính năng mới. Các công việc được theo dõi quá. +1 để yêu cầu id duy nhất.
HỎI

Nếu bạn đảm bảo đưa tất cả các chi tiết của các tính năng mới vào trình theo dõi, sau đó ai đó có thể xác minh xem nó có hoạt động như thiết kế không hoặc có thực sự có lỗi hay không. Tôi làm việc trong một nhóm phát triển duy trì chương trình trên 5 tuổi. Đôi khi khách hàng báo lỗi và khi chúng tôi nghiên cứu, chúng tôi thấy rằng nó đang hoạt động như thiết kế và nhà phát triển ban đầu và người yêu cầu ban đầu đều biến mất. Chúng tôi có những tình huống tương tự mà chúng tôi không biết tại sao lại có thứ gì đó như vậy và nếu các tính năng không có trong trình theo dõi, chúng tôi sẽ không có cách nào để tìm hiểu.
Asa Ayers

2

Tôi đề nghị giữ cho nó đơn giản và đặt tên các nhánh theo quy ước FeatureName(hoặc feature-name). Vâng, điều này có nghĩa là một không gian tên được chia sẻ, nhưng điều này hiếm khi là một vấn đề trong thế giới thực. Khi một tính năng được thực hiện và sáp nhập hoàn toàn vào dòng chính, chi nhánh có thể được xóa một cách an toàn.

Ý tưởng chính của kiểm soát phiên bản phân tán là nó phải dễ dàng phân nhánh, giới thiệu thêm bộ máy quan liêu, như id duy nhất bắt buộc, sẽ chỉ làm cho điều này trở nên khó khăn hơn.


1
Tôi đồng ý, đây là con đường để đi. Trong thế giới nào bạn sẽ có rất nhiều chi nhánh mà bạn không thể tránh va chạm?
thay thế

Đủ công bằng, nhận được một mô tả gắn liền với tên tôi đoán là quan trọng hơn đối với chúng tôi ... cam kết ban đầu nên chứa nó, nhưng tôi không biết cách nào để trích xuất nó nhanh chóng.
jfrobishow

1
Trong một môi trường doanh nghiệp lớn, việc để các nhà phát triển tạo nên tên cho các tính năng sẽ gây ra đau đầu sớm hay muộn.
HỎI

1
Tôi thấy, bởi vì trong môi trường "công ty lớn", các nhà phát triển không thể tin tưởng được. Nhưng chờ đã, họ cũng tạo nên tên cho các biến, hàm và tệp. Chúng ta cũng nên thành lập một ủy ban để kiểm soát điều đó! (trớ trêu)
Adam Byrtek

2

Tôi khuyên bạn nên sử dụng hình thức như vậy (ví dụ):

BUG_ID
BUG # ID
VÉ
VÉ # ID
tính năng_bla-bla-bla
phát hành-x.xx.xx
phát hành_x.xx.xx
bản dựng_2010-20-12
bản dựng_4565
BRUC_x.xx.xx

Chỉ cần chọn các tiền tố tốt (để cho phép đầu ra bộ lọc từ các nhánh hg ), quy tắc viết hoa và dấu phân cách giữa tiền tố và ID / tên.


+1 chúng tôi đã đi với BUGID_ {freeCamelCasingTextDescription} cuối cùng.
jfrobishow
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.