Người bảo trì github có nên viết lại tác giả trong các yêu cầu kéo không?

Tôi không phải là một lập trình viên chuyên nghiệp, nhưng tôi làm một số mã hóa và đã sử dụng một số github. Tôi đã chạy qua những gì tôi thấy là một tình huống đáng ngạc nhiên. Tôi rất quen thuộc với git.

Có một dự án mà tôi tìm thấy một lỗi (nhỏ) đang ảnh hưởng đến tôi. Tôi đã dành một buổi chiều để tìm và sửa nó. Tôi rẽ nhánh kho lưu trữ, cam kết thay đổi và đưa ra yêu cầu kéo. Sau khi thấy rằng nó đã bị đóng cửa khi "Sáp nhập vào nhánh phát triển", tôi thấy tất cả đều ổn.

Tôi đã duyệt repo hôm nay để sẵn sàng gỡ bỏ chi nhánh của mình và tôi không thể tìm thấy nơi cam kết được hợp nhất vào repo của người bảo trì. Sau một thời gian tôi nhận ra nó đã được thêm vào như một cam kết, nhưng tác giả không còn là tôi nữa.

Theo như tôi có thể nói cách duy nhất để làm điều đó là sử dụng cụ thể một cuộc nổi loạn, sửa đổi hoặc viết lại lịch sử khác để xóa tác giả gốc.

Điều này có vẻ rất sai với tôi. Tốt nhất là khó hiểu, tệ nhất là tác giả của repo này đang lấy tín dụng cho các cam kết của mọi người và sau đó lịch sử của người đóng góp ban đầu bị mất. Một lần nữa, đó là một lỗi nhỏ, tôi không sử dụng nó cho sơ yếu lý lịch chuyên nghiệp của mình, nó có vẻ không trung thực.

Điều này có bình thường không? Tôi có nên nói điều gì về nó?

Chỉnh sửa: Cảm giác chung dường như là tôi nên đi hỏi, vì vậy tôi sẽ làm điều đó vào sáng nay.

Theo yêu cầu dưới đây. Tôi đã kiểm tra và mã của tôi tồn tại và được áp dụng chính xác khi tôi viết nó (bao gồm cả nhận xét). Tôi xác nhận rằng cả người đi làm và tác giả đã được thay đổi. Có một thay đổi bổ sung cũng được thêm vào cùng lúc với những thay đổi của tôi. Đó là một dòng duy nhất, sẽ ảnh hưởng đến bản vá cũng như các mã khác trước nó. IE bổ sung một dòng không liên quan đến lỗi tôi đang sửa.

Cập nhật Có vẻ như câu trả lời là tác giả duy trì một nhánh phát triển và không muốn hợp nhất từ ​​nhánh chính của mình vào nó. Ông tái tác giả cam kết của tôi để tránh hợp nhất. Tôi không quan tâm đến chi nhánh ban đầu của b / c git rất mạnh mẽ để chọn cherry, rebase và hợp nhất các cam kết xung quanh khi cần thiết.

Đây có phải là điển hình trên github?
Tôi có nên liên hệ với người bảo trì dự án để hỏi chi nhánh nào nên áp dụng bản vá?

Không, họ không nên, nếu có thể tránh được. Đó là một vấn đề mà theo kinh nghiệm của tôi xảy ra quá thường xuyên. Tuy nhiên tôi tin rằng nó liên quan nhiều hơn đến việc không biết cách sử dụng git một cách chính xác hơn là ai đó muốn đánh cắp tín dụng.

• Nếu họ muốn sửa đổi thay đổi của bạn trước khi áp dụng nó cho chi nhánh chính của họ, họ có thể dễ dàng tạo một chi nhánh cho thay đổi của bạn. Sau đó, họ có thể thêm cam kết của riêng mình sau của bạn và sau đó hợp nhất chi nhánh.
• Nếu yêu cầu kéo của bạn không dựa trên phiên bản mới nhất của chi nhánh chính của họ, thì họ có thể đưa ra a git rebase master. Nếu có xung đột, họ có thể chọn tự khắc phục xung đột (không thay đổi tác giả) hoặc cho bạn cơ hội khắc phục.

Tôi nghĩ rằng Github có thể và nên tìm kiếm loại đánh cắp tín dụng tình cờ này và giáo dục những người duy trì cách thực hành tốt nhất khi thích hợp.

Bạn đã bỏ qua một số chi tiết quan trọng ở đây.

• Nếu cách bạn "sửa" lỗi không phải do người bảo trì thích, hoặc thậm chí không chính xác ở chỗ nó đã đưa ra lỗi riêng của mình, thì người bảo trì có thể đã phải chỉnh sửa công việc của bạn trước khi cam kết. Trong trường hợp đó là dễ hiểu để thay đổi tác giả.

• Như những người khác đã đề cập, tác giả khá khác biệt với người đi làm . Như bạn có thể đã biết tác giả là người thực sự đã tạo ra cam kết, trong khi đó, người ủy quyền sẽ là người áp dụng nó.

Bạn nên xem xét kỹ cam kết và cập nhật câu hỏi của bạn với những phát hiện của bạn.

Có vẻ như câu trả lời là tác giả duy trì một nhánh phát triển và không muốn hợp nhất từ ​​nhánh chính của mình vào nó. Ông tái tác giả cam kết của tôi để tránh hợp nhất.

Để trả lời câu hỏi cập nhật của bạn:

Thật khó để nói những gì là điển hình trên github, ngoài việc nói rằng thông thường mỗi dự án là khác nhau và mỗi dự án có quy trình làm việc ưa thích của riêng họ. Nói chung, cách tiếp cận tốt nhất trước khi gửi yêu cầu kéo là hỏi quy trình công việc của họ là gì hoặc thử xem bạn có thể cho biết dựa trên các yêu cầu kéo đóng trước đó không.

Kinh nghiệm cá nhân của tôi là nếu bạn không hỏi, nói chung họ sẽ đóng yêu cầu kéo mà không cần bình luận (trường hợp xấu hơn) hoặc tốt nhất là họ để lại bình luận giải thích thủ tục yêu cầu bạn cập nhật yêu cầu kéo của bạn. Tôi sẽ nói nó có vẻ kỳ quặc theo cách mà người bảo trì trong trường hợp của bạn xử lý nó, nhưng nó có thể chỉ là con đường ít kháng cự nhất đối với họ. Tôi nghi ngờ rằng nó đã cố ý để ăn cắp tín dụng mặc dù.

Tôi sẽ đề nghị bạn yêu cầu người bảo trì thêm tài liệu giải thích cách họ muốn nhận yêu cầu kéo và chống lại chi nhánh nào để tránh nhầm lẫn và thiếu tín dụng trong tương lai. Tôi muốn nhiều dự án cung cấp tài liệu này, vì tôi nghĩ nó sẽ khiến mọi người có xu hướng tham gia vào dự án nhiều hơn.