깃허브 풀리퀘스트 질문입니다. (제출한 PR에 원치 않은 내용도 포함되는 문제)

이건 개념적인 설명도 좀 필요할 것이라고 생각하는데 말씀하신 부분은 Git의 특성과 Pull Request를 이용한 협업의 특성이 조합되어서 발생하는 부분입니다. 머지할 브랜치가 main이라고 했을 때 각 브랜치는 따로 움직이므로 5week 브랜치도 main에 머지하려고 PR을 올리고 5week 브랜치위에 쌓아올린 6week 브랜치도 PR을 올리면 main 브랜치 입장에서는 6week PR에는 당연히 5,6주차 커밋이 모두 포함됩니다. 과제를 하시는 입장에서는 협업 상황과는 좀 다르긴 합니다만 실제로 협업을 한다고 하면 5week PR은 리뷰를 받다가 리젝을 당하거나 설계 자체가 달라질 수 있습니다. 그렇다면 그 위에서 작업한 6week에 대한 작업도 다시 재작업이 필요하게 됩니다. 그러므로 5week PR을 올린 상태에서 6week PR을 올린다는 것은 이런 재작업의 리스크가 있을 수 있다는 것을 인지하고 작업해야 하는 부분입니다. 과제에서는 그럴 수 없겠지만 저같은 경우는 그런 일이 최소한으로 발생하게 PR을 작업하는 편입니다. 서로간의 연결이 되지 않게 PR 단위를 잘게 나누어서 작업 단위를 나누어서 PR을 올리거나 다른 작업을 교차적으로 진행하곤 합니다. 그럼에도 말씀하신 상황은 실제로도 많이 발생하는 상황이고 기술적(?)으로는 stacked changes 혹은 stacked PR이라고 부릅니다. 관련해서는 https://www.youtube.com/watch?v=XRZPkYnWa48 발표를 참고해 보시는 것도 도움이 될 것 같습니다. GitHub의 PR 구조는 stacked Pull Request를 서비스 차원에서 권장하지 않기 때문에 말씀하신 형태의 PR을 올리기거나 리뷰하기가 쉽지 않은 구조이긴 합니다. 그래서 6week PR은 커밋이 섞여있어서 리뷰어 입장에서는 꽤 괴로운데 질문하신 거 보면 이부분은 이해하시고 계시다고 생각합니다. 반면 Facebook은 stacked changes를 꽤 적극적으로 사용하는 내부 시스템을 가지고 있습니다. 위에 링크 드렸던 영상에도 나올텐데 https://graphite.dev/ 라는 서비스가 stacked changes를 GitHub에서 잘 쓰게 하기 위한 서비스입니다. 물론 Graphite는 forked 저장소 보다는 저장소에 쓰기 권한은 있지만 Pull Request 기반으로 협업하는 구조에 더 맞다고 생각합니다.(forked 저장소도 지원하는지는 제가 정확히 모르겠습니다.) git 시스템 적으로 질문하셨던 "머지되지 않았음에도 PR들을 분리할 수 있는 방법"은 main 브랜치에서 5week 브랜치를 만들어서 작업하고 PR을 올리고 5week 브랜치에서 6week 브랜치를 만들어서 작업해서 PR을 올릴 때 PR의 타겟 브랜치를 5week으로 올리면 됩니다. 이 타켓 브랜치를 지정하려면 PR을 올리는 브랜치에 있어야 하므로 forked 저장소로 협업하는 구조가 아닌 같은 저장소에서 브랜치를 분리해서 PR로 협업하는 구조를 얘기했던 것입니다. 이렇게 작업하면 6week PR에는 당연히 6week만의 커밋이 포함되고 PR 본문에 다른 PR의 링크를 준다면 그 작업 위해서 이뤄진 것임을 리뷰어도 인지할 수 있습니다. 이후 5week가 머지 된다면 6week 브랜치도 main을 기준으로 rebase를 하고 PR의 타켓 브랜치를 main으로 바꾸어 주면 됩니다. 이 수동 과정이 꽤 복잡하고 귀찮은데 Graphite라는 서비스는 이를 쉽게 자동으로 해준다고 생각하시면 될 것 같습니다. 좀 복잡한 과정이라서 글로 잘 전달되었을지 모르겠습니다.

Fetch하셔서 최신화 하시고 합치고자하는 타겟 브런치(ex. origin/main)를 타겟으로 리베이스 후에 작업하신 브런치로 강제 푸시 하시면 될것 같습니다.

Week6 브랜치를 따로 두어 PR의 베이스 브랜치를 Week5로 변경하게 되면, Week5와 Week6의 사이의 변경분만 PR에 표시되게 됩니다. Week5가 머지되기 전에 잠시 베이스 브랜치를 변경하여 작업하시는 것은 어떨까요~?

안녕하세요! 깃허브의 풀 리퀘스트(PR)에서 원하지 않은 내용이 포함되는 문제에 대해 안내해 드리겠습니다. 일반적으로 PR은 특정한 기능이나 수정 사항에 대한 변경을 다른 사람들과 공유하고 검토받기 위한 용도로 사용됩니다. 따라서 하나의 PR에는 해당 기능 또는 수정 사항과 관련된 커밋들이 포함되어야 합니다. PR이 머지되기 전에 다른 작업을 진행하면 해당 작업 역시 PR에 포함되게 됩니다. 하지만 만약 특정 PR에서 원치 않은 내용이 포함되었다면, 다음과 같은 방법을 고려할 수 있습니다: 1. 새로운 브랜치 생성: 이전 PR과는 별개로 새로운 브랜치를 생성하여 추가 작업을 진행한 후 새로운 PR을 작성할 수 있습니다. 이를 통해 이전 PR과는 분리된 형태로 작업을 진행할 수 있습니다. 2. 커밋 수정 및 강제 푸시: 원치 않은 내용이 포함된 커밋을 수정하고 해당 브랜치에 강제로 푸시하여 PR에 반영되지 않도록 할 수 있습니다. 이를 위해 'git commit --amend' 명령을 사용하여 커밋을 수정하고, 'git push --force' 명령을 사용하여 브랜치에 강제로 푸시합니다. 그러면 이전 PR에는 수정된 내용이 반영되지 않게 됩니다. 다만, 이러한 작업은 기존의 커밋 기록을 변경하므로 주의가 필요합니다. 특히 이미 PR을 생성한 후에는 커밋을 수정하고 푸시하는 것은 다른 협업자들에게 혼란을 줄 수 있으므로, 신중하게 판단하고 진행해야 합니다. 결론적으로, PR이 머지되지 않은 상태에서도 다른 작업을 진행하고 싶다면 새로운 브랜치를 생성하거나 커밋을 수정하여 추가 작업을 진행하는 방법을 고려해보시기 바랍니다. 이를 통해 PR의 내용을 명확하게 유지하고 관리할 수 있습니다.