Tại sao tôi nên viết một thông điệp cam kết?

Tại sao tôi nên viết một thông điệp cam kết? Tôi không muốn và tôi nghĩ nó ngu ngốc mỗi lần.

Một giao diện GUI tôi sử dụng sẽ không được đặt tên buộc bạn phải làm điều đó. Tôi nghe thấy người khác làm điều đó mỗi lần ngay cả khi họ đang sử dụng VCS trên dòng lệnh.

Nếu tôi cam kết nhiều lần trong ngày và chưa hoàn thành một tính năng thì tôi sẽ viết về cái gì? Tôi CHỈ bao giờ viết một tin nhắn sau nhiều lần cam kết và tôi cảm thấy đã đến lúc cho một thẻ nhỏ hoặc khi tôi thực hiện một thẻ thực tế.

Tôi đúng hay tôi đang thiếu một cái gì đó? tôi cũng đang sử dụng một hệ thống phân tán

Đối với tất cả những người nói rằng "chỉ cam kết khi bạn có một thông điệp hữu ích, được suy nghĩ kỹ để viết và khi tính năng của bạn hoàn thành 100% và bạn có các bài kiểm tra đơn vị cho nó", tôi nói: Bạn vẫn còn trong suy nghĩ của SVN .

Nếu bạn đang sử dụng git , đây là thứ tôi sẽ gọi là quy trình làm việc thông minh:

1. Cam kết thường xuyên như bạn muốn . Viết bất kỳ tin nhắn nhanh cũ ở đó. Không ai sẽ nhìn thấy nó dù sao.
2. Sau khi nói, 10 lần cam kết, bạn đã hoàn thành tính năng mà bạn đang làm việc. Bây giờ viết bài kiểm tra và cam kết những bài kiểm tra. Hoặc bất cứ điều gì bạn muốn. Nếu bạn thích TDD, hãy viết bài kiểm tra trước, tôi không quan tâm, git cũng không.
3. git rebase -itừ cam kết 'lộn xộn' đầu tiên mà bạn đã thêm và sửa chữa lịch sử địa phương của mình bằng cách xóa, chỉnh sửa, bỏ qua và làm sạch lịch sử gần đây của bạn thành các cam kết sạch sẽ, hợp lý với các thông điệp tốt đẹp .
4. Sau khi dọn dẹp, hãy nhờ ai đó kéo từ bạn.
5. Rửa sạch và lặp lại.

Lưu ý rằng bước 3 là khi bạn kết thúc với những cam kết tốt đẹp đó sau đó và khi sử dụng SVN, bạn phải tránh việc cam kết cho đến khi bạn thực hiện hai bước đầu tiên, đó là điều mà hầu hết các câu trả lời khác đang đề xuất. IOW, bạn không muốn gây ra một nửa mã chưa được viết, chưa được kiểm tra cho người khác, vì vậy bạn không cam kết trong một tuần, cho đến khi tính năng của bạn được thực hiện. Bạn không sử dụng kiểm soát phiên bản cho toàn bộ tiềm năng của nó.

Cũng lưu ý rằng bất cứ nơi nào giữa các bước 1 và 3, bạn có thể git pushthay đổi gương nhân bản riêng của mình trên máy chủ để nhận bản sao lưu miễn phí nếu ổ cứng máy tính xách tay của bạn chết.

Bởi vì khi một số người bảo trì kém đang săn một lỗi và thấy rằng nó đã được thêm vào trong rev. xyz, anh ấy sẽ muốn biết rev. xyz đáng ra phải làm.

Bạn nhận xét mã nguồn của bạn, phải không?

Bạn viết những bình luận hay nhất, những người nói tại sao như mã chỉ nói thế nào ?

Thông điệp cam kết là một nhận xét như vậy, và do đó nó rất quan trọng và bạn càng nghĩ nhiều hơn để làm cho đúng, nó càng hữu ích cho người bảo trì phần mềm trong tương lai.

Đối với bất kỳ phần mềm hoạt động nào, bình luận cụ thể này cuối cùng sẽ được hiển thị trong một cái gì đó như

(tìm thấy tại http://longair.net/blog/2009/04/25/a-few-git-tips/ ). Điều này cho phép một cái nhìn của loài chim về những người đã làm việc trên phần mềm khi nào và những gì họ đã làm.

Lưu ý rằng đây là mục tiêu cuối cùng cho nhận xét cam kết, cụ thể là hiển thị trong danh sách như vậy nói " cái gì " với bản thân tương lai của bạn hoặc đồng nghiệp của bạn, và đó là lý do tại sao bạn nên cẩn thận khi viết tin nhắn cam kết tốt.

Nếu thông điệp cam kết có vẻ ngu ngốc đối với bạn thì có vẻ như bạn đang sử dụng sai.

Các cam kết nên được thực hiện vì lý do chính đáng - chúng nên liên quan đến các nhiệm vụ bạn đã chia nhỏ cho tính năng bạn đang làm việc. Cho dù những nhiệm vụ đó là chính thức hay chỉ là trong tâm trí của bạn, mỗi thay đổi bạn cam kết sẽ ít nhiều hoàn thành một nhiệm vụ và do đó có chức năng theo một cách nào đó.

Sau đó, tin nhắn cam kết của bạn phục vụ một mục đích tốt hơn nhiều. Mô tả nhiệm vụ bạn đã hoàn thành và nếu nó không được theo dõi ở nơi nào khác, tại sao nhiệm vụ đó lại cần thiết hoặc mục đích của nó là gì:

• Tái cấu trúc lớp người dùng để đóng gói tốt hơn
• Sơ khai API đã tạo để giao diện có thể được sử dụng trong lớp trình điều khiển
• Chuyển đổi lớp cơ sở dữ liệu thành một lớp trừu tượng để có thể sử dụng cơ sở dữ liệu giả trong các trường hợp thử nghiệm

Sau đó, bạn hoặc các nhà phát triển khác có thể duyệt qua kho lưu trữ hoặc lịch sử tệp và khá dễ dàng xem nơi diễn biến nhất định đã xảy ra và tại sao. Hoặc, nếu một bản sửa đổi cụ thể bị coi là có lỗi, thông báo cam kết sẽ đưa ra manh mối về lý do tại sao dòng đó được đưa vào, để bạn không xé nó ra và có thể từ chối một thứ được cho là đã sửa, và thay vào đó bạn có thể sửa nó đúng cách.

Cam kết không giải quyết mọi thứ. Luôn có cơ hội họ có thể đánh lừa nhiều như họ giúp đỡ - đặc biệt là khi các nhà phát triển tức giận về việc phải nhập chúng. Hãy thử điều này: coi chúng giống như một vệt bánh mì trong rừng hoặc một điểm tham quan leo núi hoặc đạn đánh dấu. Thực hiện đúng, họ có thể phác thảo một con đường khó hiểu khác.

Đừng làm to chuyện ra khỏi chúng. Hãy trung thực:

• "Đã chỉnh sửa các thực thể chỉ mục không gian, Dao và UI để xử lý tính năng X"
• "Đăng ký gia tăng cho yêu cầu tính năng # 1234 và lỗi # 5678"
• "Tôi đã phá vỡ bản dựng cuối cùng. Đây là những tệp tôi đã bỏ lỡ."

Giữ nó ngắn và "bức tranh lớn". Nếu có thể, hãy tham khảo một số vấn đề trong hệ thống tính năng / lỗi của bạn. Một số UI kiểm soát phiên bản bao gồm một trường cho loại điều này.

Nó giảm số lượng WTF / phút;)

điều này chuyển thành một nhóm hạnh phúc hơn (người không ghét bạn) và đầu ra nhóm tốt hơn có khả năng với chi phí thấp hơn

Vì vậy, phần còn lại trong nhóm của bạn biết WTF bạn đang kiểm tra các thay đổi đối với cây dự án.

bởi vì nếu bạn không thực hành nhập tin nhắn cam kết đàng hoàng, bạn sẽ kết thúc giống như đồng nghiệp của tôi, người nhập tin nhắn như

no changes

hoặc là

testing

cho các cam kết với hơn một trăm tệp đã thay đổi (không đùa ở đây !!).

Nếu bạn trở thành nhà phát triển như vậy, bạn sẽ trông thật ngu ngốc trong mắt phần còn lại của thế giới, bất kể bạn nghĩ nó ngu ngốc đến mức nào khi chỉ cần nhập một tin nhắn.

Tại sao bạn cam kết nếu những thay đổi không có ý nghĩa?

Chỉ cần cam kết thay đổi có ý nghĩa. Ví dụ, tôi đã thực hiện tái cấu trúc khá lớn vào tuần khác, tôi mất khoảng 3 ngày. Tôi sẽ có hàng tấn cam kết trong thời gian đó. Một số thay đổi khá nhỏ ('đổi tên lớp X thành Y để phản ánh trách nhiệm mới' hoặc 'chuyển phương thức Z () sang lớp Q') và các thay đổi khác thực sự lớn. Khi tôi hoàn thành một tính năng / tái cấu trúc, tôi kiểm tra xem một số cam kết có thể bị xóa (ít nhất là git hỗ trợ điều đó, không biết về các công cụ khác), nhưng tôi thường để chúng như vậy vì nó sẽ giúp ích sau này.

Tôi đoán bạn sẽ không cam kết ở giữa chỉnh sửa một dòng, vì vậy nó nên có ý nghĩa. Chỉ cần mô tả những gì bạn đã làm kể từ lần cam kết cuối cùng.

hãy tưởng tượng một điều kiện khi bạn phá vỡ hệ thống của mình bằng cách thực hiện một số thay đổi và nhận ra điều này sau một vài lần cam kết theo nhóm. Bạn không nhớ thay đổi là gì nhưng bạn nhớ có thể có lỗi xảy ra khi bạn tăng cường tính năng X hoặc xóa tệp khỏi mô-đun Y.

Nhưng thật không may, số sửa đổi không cho bạn biết khi bạn thay đổi X hoặc Y. Vì vậy, lựa chọn của bạn là đọc tất cả các mã được cam kết trong N ngày qua hoặc chỉ đọc các thông báo cam kết chi tiết bạn đã viết (dễ đọc hơn nhiều so với mã).

Vì vậy, nếu bạn viết cùng một văn bản nhàm chán, vô dụng, không liên quan trong thông điệp cam kết, bởi vì bạn phải, có hại hơn là có thông điệp cam kết. Bởi vì thay vì tìm lỗi root, thông báo sai sẽ khiến bạn hiểu lầm.

Vì vậy, hãy cố gắng viết thông điệp cam kết có ý nghĩa mỗi khi bạn cam kết có thể giúp bạn và duy trì.

Nếu bạn đang làm việc với người khác, thì các thông điệp cam kết rất quan trọng để thực sự thấy những gì người khác đã làm: tìm kiếm sự khác biệt cho mỗi người trong số họ là công việc nhiều hơn và bạn có thể không hiểu tại sao ai đó đã làm điều đó. Nếu bạn làm việc với người khác và ai đó (có lẽ không phải bạn) phải thực sự nhìn lại, ví dụ để theo dõi hành vi đã thay đổi như thế nào từ phiên bản trước theo cách không mong muốn ... bạn thực sự gây khó khăn cho cuộc sống bằng cách không sử dụng một gợi ý hữu ích trong cam kết thông điệp.

Nếu bạn đang làm việc một mình ... trong một dự án chủ yếu được mã hóa 'như hiện tại' (ví dụ: một trang web hoặc tập lệnh đơn giản) tôi có thể ít nhiều thấy bạn đến từ đâu. Nếu tôi làm việc trên một cái gì đó như thế, tôi chỉ quan tâm đến ngày / thời gian hoặc những thay đổi gần đây nhất khi tiếp tục làm việc gì đó (bạn có một điểm cần khôi phục, nhưng điều đó chỉ quan trọng trong quá trình phát triển, không phải sau khi bạn triển khai nó). Kiểm soát phiên bản chỉ là một cách tạo bản sao lưu với một vài kìm - tôi hoàn toàn đồng ý rằng việc không sử dụng hoàn toàn hệ thống - nhưng trên một số dự án quy mô nhỏ, điều đó có thể không cần thiết.

Ý nghĩ đã xảy ra với tôi trước đó rằng Control Control đang được sử dụng theo hai cách phân tách, một trong những thay đổi tài liệu trong dự án và khác là giúp đỡ cho các nhà phát triển tại chỗ ... và hai điều đó hoàn toàn khác nhau. Thông điệp cam kết rất quan trọng theo một cách, và có thể hầu như vô dụng theo cách khác.

Bạn đang thiếu một cái gì đó. Có phải là một lý do để thực hiện một cam kết nếu không bạn sẽ không được làm việc đó.

Tất cả những gì bạn cần làm trong bình luận là đưa lý do thành lời, ngay cả khi đó chỉ là wip: adding new state objects

Giống như nhiều người khác, tôi thực hiện một chút mã hóa trong thời gian rảnh rỗi và sử dụng hệ thống kiểm soát sửa đổi để theo dõi cả sự phát triển và thay đổi của tôi. Lượng thời gian rảnh rỗi tôi có sẵn thay đổi rất nhiều từ tuần này sang tuần khác và tháng này sang tháng khác. Nhiều lần tôi đã không có thời gian để viết mã cho một dự án trong nhiều tuần hoặc thậm chí nhiều tháng, và thời gian như vậy tôi thường sẽ dao động từ 10 phút (ngày thông thường) đến 40 phút (ngày tốt). Những điều đó chắc chắn không phải là điều kiện tuyệt vời - đặc biệt là cho các vấn đề gỡ lỗi.

Điều cần thiết là giữ các ghi chú mà cả hai sẽ không bị mất, và có thể dễ dàng lấy lại được. Vào cuối mỗi phiên, công việc của phiên sẽ được cam kết với một thông báo chi tiết. Sau đó tôi có thể đi qua lịch sử cam kết và theo dõi tiến trình và quá trình suy nghĩ của mình. Điều này cho phép tôi chọn nơi tôi đã ở tuần trước hoặc tháng trước với ít thời gian quý giá nhất bị mất.

Điểm mà tôi đang cố gắng minh họa là các thông điệp cam kết tốt sẽ giúp bạn (và bất kỳ ai khác đến sau bạn) để tìm ra điều gì đã xảy ra, điều gì đang xảy ra, nơi mọi thứ đang diễn ra và trên hết là tại sao.

Hãy suy nghĩ về nó một cách logic trong một phút. Khi bạn đang cam kết điều đó có nghĩa là một cái gì đó đã được thực hiện. Nếu bạn không để lại tin nhắn, làm thế nào người khác biết những gì đã được thực hiện?

Nếu bạn không bình luận về cam kết của mình, bạn có thể muốn bình luận về sự thay đổi trong nguồn. Trong thời gian, điều đó có thể làm lộn xộn nguồn.

Thông báo cam kết là một cách nhanh chóng để biết những gì đang diễn ra trong lần đăng ký đó và sẽ giúp các nhà phát triển khác trong nhóm của bạn khi họ muốn biết khía cạnh nào của mã đã thay đổi trong lần sửa đổi nào (vì lý do có thể).

Trong một lưu ý liên quan, tôi sẽ đề nghị chỉ định số trường hợp theo dõi lỗi (tôi hy vọng bạn đang sử dụng một) trong thông báo cam kết, để nó có ích cho tương lai để dễ dàng theo dõi mọi thứ.

Vì vậy, người duy trì mã đó 1 năm sau biết ai sẽ săn lùng mã đó. :)