개발자

issue 생성 없이 pullrequest

2024년 05월 13일조회 58

정말 잘 사용하고 있는 라이브러리의 readme 의 예시가 실제 사용예와 맞지 않는 것을 발견하여 수정을 제안하고자 합니다. issue로 소통 및 수정 제안 없이 바로 pull request를 남기면 해당 프로젝트 소유자에게 매너가 아닌 것 같아 이슈를 먼저 남겨야 할지 궁금하여 질문드립니다. 읽어주셔서 감사합니다!

이 질문이 도움이 되었나요?
'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.

답변 1

용용님의 프로필 사진

네 일반적인 순서가 1. 동일한 issue 또는 PR이 올라와 있는지 확인 2. issue 등록 3. 이후 답변이 달리면 여부에 따라 본인이 진행 가능한지 확인 받기 4. 작업 진행 후 PR 위 순서로 진행됩니다 사실 해당 라이브러리에서 정해놓은 규칙이 없으면 정말 찾고 없는 경우, 코드 베이스를 건드리지 않는 경우 PR 먼저 올리는 경우도 있는데 위 순서가 일반적이긴 합니다 그리고 issue를 등록하고 진행할 때에는 본인이 맡아서 하고 있다고 알려주면 더더욱 좋습니다

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

AI 답변
커리어리 AI 봇 프로필 이미지

커리어리 AI 봇

GPT가 달아주는 답변입니다.

2024년 05월 13일

코드 수정 제안을 직접 pull request로 제출하는 것이 매너없는 행동은 아닙니다. 실제로 Github에서는 이를 "drive-by" pull request라고 부르며, 어떤 개발자가 프로젝트에 직접적으로 참여하지 않더라도 소프트웨어의 특정 부분을 수정할 수 있게 하는 기능입니다. 그러나 이렇게 하기 전에 몇 가지 고려해야 할 사항들이 있습니다. 프로젝트 소유자가 pull request를 사용하여 작업을 수용하길 선호하는지 먼저 확인해 보는 것이 좋습니다. 또한, 이미 같은 문제에 대한 수정이 진행 중인지, 혹은 다른 사용자가 이미 동일한 변경을 제안하였는지 확인하기 위하여 open된 issue들과 pull request들을 검색해 보는 것도 필요합니다. 따라서 많은 오픈 소스 프로젝트에서는 먼저 issue를 생성해서 문제를 제기하고 토론한 후, 그 결과에 따라 적합한 해결책을 pull request로 제출하는 것을 선호합니다. 이런 접근 방식은 코드 변경의 필요성에 대한 합의를 이루고, 모든 관련자들이 변경사항을 이해하고 받아들이는데 도움을 줍니다. 결론적으로, pull request를 바로 제출하는 것은 강력한 기능이지만, 그것이 항상 적절한 접근 방식은 아닙니다. 이러한 결정은 프로젝트의 커뮤니티에 따라 다르므로, 언제나 프로젝트의 문서화 된 가이드라인과 컨트리뷰션 가이드라인을 참고하는 것을 추천드립니다.

목록으로

지금 가입하면 모든 질문의 답변을 볼 수 있어요!