Vô tình bao gồm các thay đổi không liên quan trong các cam kết

Cách tiếp cận cá nhân của tôi đối với một cam kết git là mọi cam kết nên bao gồm một đơn vị thay đổi , trong tính đầy đủ của nó.

Khi tôi phát triển, tôi thường tập trung vào các đơn vị như vậy. Nhưng đôi khi, sự chú ý của tôi đi lạc ở một nơi khác và tôi làm việc một lúc trên một đơn vị khác. Điều này có lẽ không tối ưu, nhưng tôi đã học được cách cam kết cẩn thận ( git add --interactivelà một người bạn tốt của tôi).

Tuy nhiên, điều có thể xảy ra là tôi quên chọn lọc các thay đổi của mình và thay vào đó là cam kết toàn bộ tệp, tin rằng tất cả các thay đổi tôi thấy trong diff thực sự có liên quan đến cùng một đơn vị, mặc dù có thể có một hoặc hai thay đổi hoàn toàn không liên quan.

Rồi tôi git push.

Điều này có nguy hiểm không? Tôi có nên nỗ lực sửa đổi cam kết để nó chỉ bao gồm các thay đổi dự định không? Mối quan tâm chính của tôi là bất cứ ai khác nhìn vào lịch sử sẽ thấy sự thay đổi và có thể sẽ gãi đầu trong vài phút trước khi nhận ra đó rất có thể là một sai lầm. Tệ hơn nữa, tôi có thể tưởng tượng rằng sự thay đổi thậm chí sẽ có vẻ liên quan và lập trình viên có thể không nhận ra lỗi.

Vấn đề là, vì tôi đã đẩy, tôi không thể viết lại lịch sử của máy chủ một cách an toàn , vì vậy trước tiên tôi có thể phải hoàn nguyên lại cam kết, phân tách đúng và cam kết lại. Ngoài ra, tôi chỉ có thể sửa đổi cam kết với một thông điệp cam kết tốt hơn, nhưng tôi sẽ phải thực sự rất nhanh vì nó cũng yêu cầu viết lại lịch sử. Như một phương sách cuối cùng, tôi có thể chỉ đơn giản là cam kết đơn vị tôi đang làm việc tiếp theo, để lại một lưu ý rằng có một thay đổi liên quan trong lần xác nhận trước đó (nhưng điều này cảm thấy sai).

Tôi hiểu rằng trong một thiết lập nhiều nhà phát triển với quy trình xem xét mã phù hợp, điều này có thể sẽ không xảy ra. Tôi cũng hiểu rằng nếu tôi là nhà phát triển duy nhất trong một dự án, thì viết lại lịch sử là giải pháp tốt nhất cho việc này.

Lịch sử cam kết là cực kỳ quan trọng, nhưng vì 3 lý do:

1. sáp nhập vào một nơi khác. Bạn cần chọn các mảnh ra khỏi cành cây và dán chúng ở nơi khác, điều quan trọng là phải có tất cả các mảnh bạn muốn trong đó và không có gì bạn không muốn. Vì vậy, nếu cam kết 'lộn xộn' của bạn chứa các thay đổi dành cho tính năng bạn đang làm việc (chứ không phải, hãy nói một cam kết vô tình của một thứ khác) thì bạn vẫn ổn.
2. Kiểm tra những gì đã xảy ra sau đó - thường để xác định khi nào một lỗi hoặc tính năng cụ thể được đưa ra. Trong trường hợp này, không có vấn đề gì trong các cam kết miễn là bạn có thể xác định chính xác sự thay đổi mà bạn quan tâm.
3. Xem lại mã. Các đánh giá ngang hàng tốt được cam kết và sau đó được xem xét (không giữ quy trình phát triển / cam kết bằng cách chờ người đánh giá!) Và trong những trường hợp này, người đánh giá sẽ muốn hiểu những thay đổi đã được thực hiện. Tuy nhiên, nhìn chung, một người đánh giá sẽ quan tâm nhiều hơn đến những thay đổi tổng thể - cố gắng xem xét các cam kết đã được thực hiện, hoàn nguyên, thực hiện lại là một bài tập lãng phí thời gian so với việc xem xét cả 3 cam kết cùng một lúc.

Vì vậy, mặc dù đơn vị công việc cam kết nghe có vẻ lý tưởng, nhưng chúng không phải là bất cứ điều gì để khẳng định trong điều kiện thực tế. Tôi sẽ cố gắng giữ cho các cam kết hợp lý và đơn vị công việc là một cách tốt để giữ cho các cam kết lành mạnh, nhưng đừng bận tâm cố gắng tìm hiểu lịch sử cam kết chỉ để giữ cho các cam kết gọn gàng. Điều đó giống như cập nhật một tệp mã để làm cho tất cả các dấu ngoặc thẳng hàng theo cách bạn thích - đẹp, nhưng vô dụng.

Bây giờ, nếu bạn đã cam kết một chút công việc dành cho một chi nhánh khác, hãy hoàn nguyên nó và cam kết nó đúng với chi nhánh bên phải. Điều đó rất quan trọng, nhưng nếu bạn đã cập nhật một chút mã máy chủ khi bạn đang làm việc trên GUI .. thì không cần phải lo lắng về điều đó.

Khi điều này xảy ra, nó không phải là một thỏa thuận lớn để chỉ đơn giản là hoàn nguyên thay đổi trong lần cam kết tiếp theo. Thêm một thông điệp cam kết thích hợp ( Removing the XYZ that I accidentally added in C92A891) sẽ đủ để các nhà phát triển khác hiểu trong đánh giá mã.

Thay vì lo lắng về việc khắc phục bất kỳ sự cố cụ thể nào, hãy cố gắng tránh tình huống này ngay từ đầu.

Đây là vấn đề thực sự:

Tuy nhiên, điều có thể xảy ra là tôi quên chọn lọc các thay đổi của mình và thay vào đó là cam kết toàn bộ tệp

Bạn nên tập thói quen không bao giờ cam kết toàn bộ tệp (hoặc tệ nhất là toàn bộ không gian làm việc của bạn!). Luôn cam kết từng dòng hoặc bởi toàn bộ Hunk mà bạn đã kiểm tra.

Khi thực hiện theo cách này (có vẻ như bạn đang làm hầu hết thời gian), những thay đổi vô tình ít có khả năng lẻn vào các cam kết của bạn.

Dường như bạn có một kho lưu trữ cục bộ trên máy tính của mình và một kho lưu trữ được chia sẻ với đồng nghiệp trên máy chủ. Tại sao bạn chỉ có một kho lưu trữ trên máy tính cục bộ của bạn? Tôi thường có ít nhất năm, vì vậy tôi có thể làm việc trên một thứ trong một kho lưu trữ, sửa một lỗi trong một kho khác mà không cần chạm vào repo đầu tiên, có thể ở trạng thái không hoàn chỉnh, v.v.