깃허브 사용 패턴에 대해서 질문드립니다! (Issue , PullRequest)

Question

깃헙 Issue와 PR에 대해서 공부하던 도중 블로그마다 설명이 다른 부분이 와서 혼동이 되는게 있어서 질문드립니다!아직 제대로 된 협업을 해보지 않아서 좀 근본적인 부분에 있어서 헷갈리는게 있네요,,하나의 레포지토리에 모두가 write권한이 있고 여기에 각자 브랜치를 파서 협업할 때이때는 통상적인 git-flow방식처럼 develop , feature/#이슈번호 브랜치 , release브랜치 등등 파서 개발을 진행하는데그러면 이런 경우에는 어차피 다들 write가 가능하니까 굳이 PR을 날릴 필요가 없는 것인가요? 그냥 다들 보기 쉽게 이슈만 등록해놓고 , 이에 해당하는 feature/#이슈번호 브랜치 만 만들어서 개발하면 되나 싶어서요...하나의 원본 레포지토리(A)가 있고 여기에서 fork를 해서 각자 개발할 때원본 레포지토리에서 fork를 해온다 fork해온 개인 레포지토리에서(B) develop 브랜치를 만들고 clone해서 로컬로 가져온다. 이제 개발 시작이슈를 등록한다개인 레포지토리(B)에서 develop으로부터 파생된 feature/#이슈번호 브랜치 , release브랜치 등등 파서 개발을 한다이슈로 등록한 기능이 완성되면 B레포지토리의 develop 브랜치에 최종적으로 merge를 하고B레포지토리의 develop 브랜치에서 원본 레포지토리 A의 메인브랜치에 PR을 날린다이때는 이렇게 하는게....맞나요...??

Gravatars · Answer

Write 권한이 있어도 main 브랜치에는 절대로 바로 커밋 안넣고 PR을 통해서만 merge하는 방식으로 합니다다른 브랜치던 fork던 ‘main이 아닌 다른 브랜치에서 작업 후 PR

rockabyebaby · Answer

요약:PR의 목적은 추가될 커밋이 main 브랜치에 merge 해도 될지 코드 리뷰를 통해 판단하기 위함입니다.Fork 사용하지 마세요. Fork는 오픈소스 프로젝트에서 사용합니다.팀으로써 협업을 한다면 Branch로 작업해야합니다. 그걸 잘 관리하기 위해 다양한 branching strategy가 만들어졌고 말씀하신 git flow 방식도 그 중 하나입니다.GitHub의 branch protection rule을 적용하고 main 브랜치에는 PR을 통해 merge 하도록 구성하면 됩니다.이 밑으론 좀 깁니다...Git 저장소는 로컬 저장소와 원격 저장소로 구분됩니다.사실 GitHub는 Git이 아닙니다. 원격 저장소 제공자이죠. Fork라는 기능은 Git의 기능이 아니라 원격 저장소 제공자가 제공하는 기능입니다. 원칙적으론 Fork는 Git으로 하는 게 아닙니다.Branch는 git 저장소 내의 분기점이라고 보면 됩니다. 여러 브랜치로 분기하여 개발을 하면 잘 동작하는(테스트가 완료된) main 브랜치의 소스코드에 영향을 주지 않고 개발할 수 있습니다. 분기된 브랜치에서 개발하고 테스트까지 완료하여 문제 없으면 main 브랜치에 merge하여 관리할 수 있습니다.Fork는 대상 원격 저장소를 그대로 카피합니다. 카피된 Fork 저장소는 원본 저장소와는 독립적인 관계입니다. Fork 저장소는 원본 저장소에 merge될 수 없습니다. 단, PR을 통해 원본 저장소의 관리자(혹은 PR권한을 가진 유저)가 코드 리뷰를 하고 원본 저장소에 merge 할지 승인을 합니다.Fork를 잘 이해하려면 그 배경을 알아야합니다.오픈 소스는 공개적으로 그 설계에 액세스할 수 있기 때문에 누구나 기술을 수정하고 공유할 수 있는 분산형 프로덕션 모델입니다.https://aws.amazon.com/ko/what-is/open-source/오픈소스 프로젝트 특성 상 누구나 코드를 수정할 수 있는데... 그렇다고 아무런 보호가 안되면 아무개가 막짠 코드, 악성코드 같은 것들이 들어갈 수 있겠죠? 그래서 branch가 아닌 Fork로 독립된 저장소에서 코드 수정을 하고, 원본 저장소에 merge 되길 희망하면 PR을 날리도록 고안된 기능입니다.원본 저장소에 명시된 라이센스만 잘 이행한다면 원본 저장소에 merge될 필요 없이 fork한 저장소를 공개하여 누구나 자유롭게 사용/수정하게 만들어도 됩니다.어쨋든, Fork된 저장소에서 커밋하고 원본 저장소에 merge하면 결과적으론 똑같습니다. Git 입장에선 다른 브랜치에서 merge 되었는지 Fork된 커밋이 merge되었는지 알 수 없거든요. 그러나, 현업의 작업방식을 익힌다면 더더욱 Fork는 지양해야합니다. 회사의 프로젝트가 오픈소스일까요? 오픈소스 개발회사가 아닌 이상 Fork 쓰는 회사는 없습니다.

깃허브 사용 패턴에 대해서 질문드립니다! (Issue , PullRequest)

2개의 답변

#pullrequest 목록