Một checkin lớn hoặc một số nhỏ hơn?

Question

Hôm qua khi tôi kiểm tra phiên bản mới nhất của công cụ nội bộ của tôi, tôi đã thấy khoảng 30+ phiên bản mới. Điều này khiến tôi tò mò vì tôi nghĩ rằng ai đó cuối cùng đã sửa những lỗi gây phiền nhiễu đó và thêm vào tính năng mà tôi chờ đợi quá lâu ... và đoán xem sao? Không ai trong số này xảy ra, ai đó chỉ nghĩ rằng nó sẽ là tốt đẹp để cập nhật một số tiêu đề và làm một điều chỉnh nhỏ của hai hoặc ba chức năng. Tất cả mọi thứ trong một cam kết riêng biệt. Tuyệt quá.

Điều này đưa ra một cuộc thảo luận trong nhóm của chúng tôi - điều này có nên được coi là ok hay chúng tôi nên cấm "lạm dụng" như vậy? Có thể cho rằng điều này thực sự có thể phù hợp trong một hoặc hai cam kết, nhưng 30 dường như nhiều. Làm thế nào điều này nên được xử lý - thực hành tốt nhất là gì?

Answer 1

Bạn nên cam kết bất kỳ lúc nào bạn thực hiện thay đổi và sắp chuyển sang bước tiếp theo.

Bạn không nên cam kết bất kỳ điều gì khiến dự án không thể xây dựng.

Bạn nên điền thông điệp cam kết để mọi người biết những thay đổi đã được thực hiện.

Điều đó sẽ làm cho tôi .. Tôi không cho rằng một cái gì đó đã được thực hiện, trừ khi tôi nhìn thấy nó trong thông điệp cam kết ...

Answer 2

tôi sẽ không quan tâm đến số lượng cam kết như từng cam kết giữ sự nhất quán của dự án (xây dựng sẽ vẫn thành công). Đây là một số tính nội bộ mà không nên làm phiền bạn. Nếu bạn muốn thay đổi một cái gì đó ở đây, tốt hơn hãy nói với mọi người sử dụng một số thông điệp cam kết có cấu trúc (như "[bugfix] ...", "[feature] ...", "[minorfix]").

Nhân tiện, nếu bạn muốn biết nếu lỗi đã được khắc phục hay chưa, tính năng này sẽ tốt hơn rất nhiều so với kiểm tra các cam kết trong một công cụ giống như SVN.

Answer 3

Nói chung, tôi cho rằng cam kết phải liên quan đến một nhiệm vụ logic, ví dụ: sửa lỗi # 103 hoặc thêm chức năng in mới. Đây có thể là một hoặc nhiều tệp, theo cách đó bạn có thể thấy tất cả các thay đổi được thực hiện cho một tác vụ cụ thể. Nó cũng dễ dàng hơn để quay trở lại thay đổi nếu cần thiết.

Nếu mỗi tệp được kiểm tra từng cái một, không dễ thấy các thay đổi được thực hiện cho một bản cập nhật/nhiệm vụ cụ thể.

Ngoài ra nếu nhiều tác vụ được hoàn thành trong một lần commit, không dễ để xem những thay đổi nào thuộc về nhiệm vụ nào.

Answer 4

Cuộc chiến chống entropy mã là một nỗ lực của nhóm liên tục. Kiểm tra nhỏ, nơi một trong những chỉ 'sửa chữa cửa sổ bị hỏng' cùng một cách nên được khuyến khích, không cau mày. Kho lưu trữ nguồn là công cụ không đúng để theo dõi các sửa lỗi - đó là điều mà trình theo dõi lỗi là - vì vậy sự bất tiện trong việc định vị các sửa lỗi khi quét kho lưu trữ mã và không phải kho lưu trữ lỗi dường như hoàn toàn không đáng kể đối với tôi.

Tôi làm việc trong nhóm có kích thước vừa phải trên cơ sở mã lớn (~ 1M LOC) với lịch sử lớn (~ 20Y). Rất nhiều mã là một đống lộn xộn - thối chi nhánh logic, API không dùng nữa, quy ước đặt tên, thậm chí thụt đầu dòng ngẫu nhiên thường làm cho nó trở thành một nỗi đau để đọc. Tôi bắt đầu một thói quen cải tiến khả năng đọc "lái xe" nhỏ, để thử và chống lại sự thối nát mã hoàn toàn, và tôi đang cố gắng hết sức để có được đồng đội chấp nhận cùng một thói quen.

Trừ khi hoàn cảnh của bạn hoàn toàn khác nhau, tôi sẽ cố gắng và suy nghĩ thuận lợi về bất kỳ sáng kiến ​​nào như vậy. Sự thay thế (mà tôi quen thuộc với tất cả là tốt) là trì trệ sợ hãi, mà nguyên nhân bất kỳ mã nào để thối.