Một nhà phát triển đã tạo ra một tiện ích Git mới có tên what-changed-twice để giúp quản lý lịch sử commit rối rắm, nhưng cái tên khó hiểu của công cụ này đã gây ra một cuộc thảo luận thú vị trong cộng đồng về quy ước đặt tên và các công cụ tương tự hiện có.
Vấn đề mà công cụ này giải quyết
Tiện ích này giải quyết một vấn đề quy trình làm việc phổ biến của nhà phát triển. Nhiều lập trình viên thực hiện commit thường xuyên trong quá trình phát triển, tạo ra chuỗi các thay đổi liên quan rải rác qua nhiều commit. Ví dụ, bạn có thể sửa đổi một tệp vào thứ Hai, thêm nhiều thay đổi hơn vào thứ Ba, và sửa lỗi chính tả vào thứ Tư. Khi đến lúc dọn dẹp lịch sử commit, việc xác định những tệp nào đã được sửa đổi nhiều lần trở nên quan trọng để tổ chức hợp lý.
Công cụ này phân tích đầu ra của Git log và tạo ra một báo cáo hiển thị các tệp đã thay đổi trong nhiều hơn một commit, cùng với các ID commit viết tắt nơi những thay đổi đó xảy ra. Điều này giúp các nhà phát triển quyết định commit nào nên gộp lại với nhau trong quá trình rebasing.
Chức năng của Công cụ: Phân tích đầu ra của Git log để xác định các tệp được sửa đổi trong nhiều commit, xuất ra các ID commit được rút gọn và đường dẫn tệp để dễ dàng tham khảo trong quá trình thực hiện các thao tác rebase
Cộng đồng cân nhắc về việc đặt tên
Cuộc thảo luận về đặt tên đã tiết lộ những quan điểm thú vị từ cộng đồng nhà phát triển. Một số người dùng bảo vệ tên gốc, lập luận rằng nó mô tả rõ ràng chức năng của công cụ. Những người khác đề xuất các lựa chọn thay thế như git-repeatedly-changed theo quy ước đặt tên của Git , hoặc các tùy chọn sáng tạo hơn như squash-what và git-delta-delta.
Một thành viên cộng đồng đã đưa ra một quan điểm đặc biệt sâu sắc về quy ước đặt tên của Git :
Nếu bạn có git-foo trong PATH, bạn có thể thực hiện git foo và nó sẽ tự động chọn chương trình của bạn.
Điều này làm nổi bật cách đặt tên phù hợp có thể tích hợp liền mạch với cấu trúc lệnh hiện có của Git .
Đề xuất đặt tên từ cộng đồng:
- git-repeatedly-changed
- squash-what
- git-delta-delta
- Double Jeopardy
- FlipFlopStop (FFS)
Các công cụ hiện có và lựa chọn thay thế
Cuộc thảo luận cũng đã thu hút sự chú ý đến các công cụ tương tự hiện có. Một số thành viên cộng đồng đã đề cập đến git-absorb, công cụ đưa khái niệm này đi xa hơn bằng cách tự động tìm ra những thay đổi nào nên được hợp nhất vào các commit trước đó. Công cụ này tồn tại cho cả hệ thống kiểm soát phiên bản Git và Jujutsu và có sẵn trong hầu hết các kho lưu trữ phân phối.
Cuộc trò chuyện tiết lộ rằng trong khi công cụ của nhà phát triển tập trung vào việc xác định và phân tích, các giải pháp khác như git-absorb cung cấp khả năng sửa chữa tự động.
Các Công Cụ Thay Thế Được Đề Cập:
- git-absorb: Tự động đẩy các thay đổi vào các commit trước đó phù hợp
- Jujutsu absorb: Chức năng tương tự trong hệ thống kiểm soát phiên bản Jujutsu
- Có sẵn trong hầu hết các kho lưu trữ bản phân phối Linux
Các cân nhắc kỹ thuật và hạn chế
Các thành viên cộng đồng cũng đã nêu ra những điểm kỹ thuật quan trọng về hạn chế của công cụ. Mặc dù nó có thể xác định các commit không gây ra xung đột văn bản khi được sắp xếp lại, nhưng nó không thể dự đoán các xung đột ngữ nghĩa có thể phá vỡ các bài kiểm tra hoặc chức năng. Sự phân biệt này rất quan trọng đối với các nhà phát triển cần duy trì các commit trung gian hoạt động so với những người chỉ quan tâm đến kết quả cuối cùng tại điểm merge.
Cuộc thảo luận đã làm nổi bật các triết lý khác nhau xung quanh việc quản lý lịch sử commit, với một số nhà phát triển ưa thích các commit nguyên tử luôn vượt qua các bài kiểm tra, trong khi những người khác tập trung vào kết quả cuối cùng sạch sẽ tại các điểm merge.
Tham khảo: My new git utility 'what-changed-twice` needs a new name