github fork를 사용해야하는 이유에 관하여

[livlikwav]

What

• repo를 fork해서 작업해야하는 이유 정리
• repo fork를 사용하지 않고 그대로 origin repo에서 branch 활용해서 작업하는 방향으로의 회귀 제안

찬/반 + 근거 정리해주시면,
의견 취합해서 결정하고, 다시는 이의제기하지 않도록 하겠습니다 😂

Description

내부 회의를 통해 repo를 fork해서 작업하는 방향으로 정리했었는데요. 제가 새로운 작업을 위해 fork하려다가, 근데 왜 fork 해야 하는지에 대해서 궁금해서 조사해보았고,
우리 팀의 경우에는 안해도 될 것 같단 생각이 들어
의견을 묻고 싶어 공유드립니다.

https://stackoverflow.com/questions/31209669/github-why-should-i-fork
관련 Stackoverflow 질문인데, 질문자는 저와 동일하게 branch를 사용하면 되는데 fork를 굳이 해야하는 이유를 묻고 있습니다.

답변을 정리해보면

• 대부분의 오픈소스 프로젝트에 branch를 생성할 권한 자체가 기본적으로 주어지지 않는다.
  • 그래서 fork를 한 후, 해당 repo에 작업하고, origin repo로 PR을 날리는 것이 '예의바른' 방법이다.
  • 사실 권한이 없으면 그냥 clone해서 local에서 branch 파고 작업하고 push 날려도 permission denied 당한다
• 혹은 해당 프로젝트에 대해서 자신의 아이디어로 변경하고 싶다거나, 실험을 하고 싶다거나 하면 fork해서 작업한다.
• fork 자체가 github에서 기원한 개념이다. git에는 해당 개념이 없다.
• 만약 네가 원본 repo에 권한이 있다면 fork를 하지 않아도 된다.

그리고 이번 PR 진행하면서도 불편함을 느낀 것은,
같은 repo branch에서 작업하면, remote branch로 쉽게 checkout하여 IDE 상에서 코드를 확인할수도 있고, 코드를 돌려볼 수도 있는데,
각각 fork해서 작업하면 작업내역을 확인하고 싶을 때마다 fork된 repo를 clone해서 확인해야한다는 불편함이 있는 것 같습니다.

Related

None

[coloryourlife]

저는 회사를 다녀본 경험은 없기 때문에 경험을 근거로하여 의견을 제시할 수는 없으나 제가 참고하거나 배우고 들었던 것을 공유해드립니다.

우선 경민님이 말씀하셨던 것 처럼 Git fork는 github의 취지 중 하나인 익명의 대규모 오픈소스 프로젝트의 원활한 관리를 위해 있는 기능으로 알고 있습니다. 누구나 공개된 repository에 branch를 생성할 수 있게된다면 큰 규모의 오픈소스 레포같은 경우에는 관리가 힘들겠지요. 하여 회사나 소규모 팀 단위에서는 굳이 fork를 하지 않고 해당 repository에서 clone해서 각자 branch를 만들어 작업하는 경우가 많습니다. 저희와 같은 경우에는 fork를 사용하지 않는 방법이 맞는 규모에 해당할 수 있구요.

그렇다면 회사에서 fork를 해서 사용하는 경우에는 어떤 것 때문에 그러는지를 살펴보는게 좋겠죠. 먼저 지난번에 우찬님이 얘기하셨던 것은 branch를 깔끔하게 유지할 수 있지 않냐는 의견을 피력하셨던 것 같구요. 하지만 이런 점은 저희가 끝난 PR같은 경우에는 branch를 지우는 것을 원칙으로 삼는다면 언제든지 해결이 가능한 사항입니다.

다른 이유는 우아한 형제들 기술 블로그에서 fork를 하는 이유에 대한 설명을 인용해드립니다.

이런 워크플로우를 두는 데에는 한 가지 이유가 있었습니다. 그 이유는 개발자들의 실험정신(?)을 펼치기 위해서였습니다. 모두가 공유하고 있는 Repository에서 실험하기에는 위험이 있다고 생각했고, Forked한 Repository를 두면 부담 없이 원하는 실험들을 해볼 수 있다고 생각했습니다. 무엇보다 이런 구조로 가져갔을 때 개발자가 해야 할 작업들이 중앙집중식 워크플로우보다 일이 늘거나 크게 복잡해지지도 않았습니다.

여기에서 설명하는 이런 워크플로우가 fork를 해서 각 개인의 원격 저장소를 만들어 하는 경우를 일컫습니다. 여기서 말하는 실험정신이 무엇인지는 잘모르겠고, 저희가 현재 단계에서 실험정신을 발휘할 만큼에 대한 작업이 없는 것도 사실입니다.

하여 저의 의견은 지극히 중립입니다. 다른 분들의 의견들어볼게요.

++ 다시보니 경민님이 말씀하신거랑 똑같네요..ㅎ

[livlikwav]

좋은 링크 공유 감사합니다! 우아한 형제들 기술 블로그 글 확인해보니 이런 생각이 드네요. 실험정신을 펼치는 것 자체는 branching으로도 충분히 할 수 있는데,
다만 human error를 피하기 위해 origin repo에 권한을 제한을 걸어버리고,
각 fork repo에서 작업하도록 할 수도 있겠네요.

git에 익숙하지 않은 팀원이 force push를 해버리거나,
merge conflict를 잘못 처리 후 merge 한다거나 할 수 있으니까요(이는 PR을 통한다면 없는 문제겠지만).

Push 권한을 엄격하게 관리한다 <-- 이 측면에서 생각해보면 fork의 이유가 명확해지는 느낌이네요.

[do168]

두 분 의견 잘 보았습니다. 저도 fork 방식을 강제로 하자! 이런 주장은 아닙니다. 초기에는 분명 중앙 repo만을 사용하면서 협업하는 것이 편의성 면이나 효율성 면에서 좋아보입니다. 위에 말씀하신대로 휴먼 에러를 피할수만 있다면 좋은 전략인 것 같습니다.

대신 경민님이 말씀하신 branch checkout 후 돌려본다는 것에 대해서는 조금 생각이 다릅니다. pr을 위해서 개발자는 개발, 테스트까지 거치고 구현한 로직이 눈으로 보아도 흐름이 충분히 이해가 가게 짜야한다고 봅니다. 로직이 정상적으로 돌아가는 것은 전제 하에 깔려있다고 봅니다. 즉 pr review는 기능에 관한 피드백이 아닌 Clean code, 로직 자체의 결함 등에 관한 피드백이라고 봅니다. 또 작업내역은 pr 시 같이 올라온다고 알고 있습니다.

제가 잘못 이해했을 수 있고 모르는 부분도 있으니 설명해주시면 감사하겠습니다.

[livlikwav]

pr을 위해서 개발자는 개발, 테스트까지 거치고 구현한 로직이 눈으로 보아도 흐름이 충분히 이해가 가게 짜야한다고 봅니다. 로직이 정상적으로 돌아가는 것은 전제 하에 깔려있다고 봅니다. 즉 pr review는 기능에 관한 피드백이 아닌 Clean code, 로직 자체의 결함 등에 관한 피드백이라고 봅니다. 또 작업내역은 pr 시 같이 올라온다고 알고 있습니다.

네 이건 옳은 말씀입니다.
제가 설명을 잘못했네요. 이번에 init cli PR 작업하면서, 호연님이 작업하신 코드를 제가 생각하는대로 수정하고 돌려보고 싶었는데, 이렇게 현재 리뷰 건에 대해서 직접 코드 수정을 해보고, 개선을 해보고 싶을 때의 어려움을 말한 것 이었습니다.

우찬님이 말하신대로 PR 자체는 PR을 올린 사람이 그런 부분에 대해서 책임을 지고 올리는 것이 맞고,
막연히 믿는다기 보다는 Github actions를 통해 lint, build, test를 commit 마다 자동화하도록 하는 것이 맞습니다.

[hoyeon94]

저는 제홍님께서 인용해주신 아래 인용이랑

이런 워크플로우를 두는 데에는 한 가지 이유가 있었습니다. 그 이유는 개발자들의 실험정신(?)을 펼치기 위해서였습니다. 모두가 공유하고 있는 Repository에서 실험하기에는 위험이 있다고 생각했고, Forked한 Repository를 두면 부담 없이 원하는 실험들을 해볼 수 있다고 생각했습니다. 무엇보다 이런 구조로 가져갔을 때 개발자가 해야 할 작업들이 중앙집중식 워크플로우보다 일이 늘거나 크게 복잡해지지도 않았습니다.

경민님께서 정리해주신 아래내용

다만 human error를 피하기 위해 origin repo에 권한을 제한을 걸어버리고, 각 fork repo에서 작업하도록 할 수도 있겠네요. Push 권한을 엄격하게 관리한다 <-- 이 측면에서 생각해보면 fork의 이유가 명확해지는 느낌이네요.

을 볼 때 fork로 하는 게 맞다고 생각했습니다.

사실 월요일날 회사 가서 맨날 fork 무조건 해야 된다고 말씀하시는 선임분께 한번 물어보고 답변달려고 했었습니다ㅋㅋ 월요일날 추가 답변 달게요~!

[livlikwav]

Git Workflow 관련해서 더 공부해봤는데,
각 컨트리뷰터가 겹치지 않는 task를 수행한다면 forking workflow도 불편할 일이 크게 없을 것 같네요.
정 다른 사람의 branch를 땡겨와서 확인하거나 작업해야하면 remote 추가해서 하면 되니까 그대로 진행하면 될 것 같습니다.

일단은 forking workflow로 그대로 진행하면 될 것 같습니다. 그래서 issue는 일단 close 하도록 하겠습니다.
혹시나 추가적인 내용 공유해주실 게 있으시다면 여기에 남겨주세요~