git&github 협업 방식 3가지

김선우 튜터님 의견

아래에 제시된 1, 2, 3번 방법 또는 그 외라도 자신의 팀에 맞는 방법 중에서 하나를 선택해서 하면 됩니다.

(그러나 일반적으로 계속 프로젝트를 하는 회사 조직에서는 팀을 만들어서 관리하는 3번 방식을 사용합니다.)

 

강민철 튜터님 의견

그리고 pull request는 필수입니다.왜냐하면 pull request 그 자체가 코드 리뷰를 가능케 하기 때문입니다.

 

 💡 1. 각자 포크 후 Pull request (오픈소스에서 사용, 다양한 사람과 작업시)

사용법

1. 팀장이 레퍼지토리를 만든다.
2. 레퍼지토리에 브랜치를 만든다. (멤버 수만큼)
3. 팀원은 Repositories를 포크한 후
4. 각자 본인 저장소에서 자신의 브런치를 만든다.
5. 본인 저장소에서, 작업한 후
6. 상대에게 compare&request 한다.(New pull request도 가능)

장점

1. 커밋을 교환하면서 그 자체로 코드리뷰가 가능하다.(따로 또 쓰지 않아도 됨.)
2. 커밋을 한 기록, 코드 논의를 한 기록이 남는다. (특정 사람 논의한 내용도 찾기 가능함)
   1. 회사에서 커밋으로 코드 논의를 하는지 면접에서 중점적으로 본다. 
3. Merge 기능이 한명한테만 있어서 오류가 일어날 일이 적음
4. 일일이 권한부여나, 멤버 추가를 할 필요가 없다.

팀 과제시 주의사항

1. 위 방법으로 과제시 레퍼지토리를 멤버 수 만큼 각자 만들어야 함.
   1. 멤버수만큼 레퍼지토리가 만들어지므로, 전송 과정에서 오류가 날 확률이 높음
   2. 같은 팀으로 프로젝트를 여러번 한다면 계속 레퍼지토리를 만들어야 함으로 관리가 어렵다.
2. 팀과제에 경우 머지 권한이 팀장에게만 있어서 부담이 가중된다.

---

💡 2. Collaborators (일반적으로 프로젝트마다 멤버를 추가해야 해서 사용하지 않음, 머지 기능 학습용)

사용법 초대

1. setting에서
2. Collaborators에서 추가
3. 이메일 보내고, 각자 확인 후 초대 수락

 

사용법 사용

1. 브랜치 따로 각각 따로 만든다
2. 브랜치에서 작업 완료 되면 메인과 머지한다.
3. 각 브랜치는 리베이스로 내용을 업데이트 한다.

 

교육 목적으로 활용성

1. 한명만 머지를 연습하지 말고, 각자 할 수 있다.
2. 문제를 대비해서, 규칙을 정해서 2명이상 같이 코드를 보면서 연습할 수 있다.

 

규칙 정하기

1. Collaborators 규칙 정하기
   1. 머지는 2명이상 같이 확인하면서 한다.

문제점

강민철 튜터님 의견

 

• Collaborators 추가는 다소 권장할만하지 못한 예외적인 상황이라 볼 수 있습니다 :)
• (개발 팀원의 수가 적거나, 프로그램 규모가 작거나, 버전 관리를 제대로 하지 않거나
• 보통 신입이나 인턴 개발자에게는 push 권한을 제하는 것이 원칙이며  함께 개발하는 팀원이 많거나 프로그램 규모가 커지면 더더욱 push 권한을 최소한으로 유지하는 것이 원칙입니다.
• 물론 collaborators로 push 권한을 주는 경우도 있으나,그건 잘못된 push를 감안하겠다는 것과 같고,
• *그리고 회사나 팀에서는 보통 Collaborators를 추가한 후 브런치를 각자 나누어서 작업한다고 했습니다.*그렇지 않습니다.오픈소스에서의 협업 방식과 실무 상황에서의 협업 방식은 다르지 않습니다. (사실 완전 동일합니다)만일 그렇게 언급한 문서나 안내가 있다면 그것이 잘못된 것입니다.개인적으로도/제 동료 개발자 분들도 다양한 실무 상황에서 대부분 pull request를 사용하여 협업하였습니다.왜냐하면 pull request 그 자체가 코드 리뷰를 가능케 하기 때문입니다.

1. collaborator로 push 권한을 주는 경우도 있으나, 잘못된 push를 감안하겠다는 것과 같고, 다소 권장할만하지 못한 예외적인 상황이라고 볼 수 있습니다.
2. 바로 브랜치에 푸쉬가 되기 때문에, 커밋 메시지 외에 코드리뷰가 불가능하다.

 

보완방법

1. 권한 설정을 통해 방법을 통제 할 수 있다.
   • 김선우 튜터님 Answer : Collaborators로 권한을 설정하고 통제할 수 있습니다.
2. Collaborators
   1. 권한 설정
   2. 각자 권한 안에서 작업함
3. 브랜치 프로텍트 (전체 브랜치 룰을 관리하는 기능)
   • 김선우 튜터님 Answer : Branch protect도 가능합니다, 직접 push는 막기 위해 사용하는 기능이고요. 이는 Github 내에서는 유료로 제공되는 기능일 거예요.

 

질문 했던 내용 (위에 기능은 존재한다. 그러나 실무에는 정말 이렇게 하는지?)

1. 실무에서는 브런치로 각자 나눈 후 작업함
2. 팀장 등 주요 권한자는 머지 기능을 가짐
3. 신입, 인턴은 머지 기능이 없음.

• 김선우 Answer : 보통은 Collaborator는 사용하진 않습니다. 밑에 3번. 김태선 튜터님이 제시한 방안대로 하는게 일반적이고요. 일반적으로는 Git flow라는 코드 통합 전략을 활용하는데, 회사에서 운영하는 프로젝트에 따라 약간의 차이는 있기 때문에 어떤 전략이 가장 이상적이다라고 말씀을 드리기 어려울 것 같습니다

---

💡 3. 김태선 튜터님

문제 제시(현업에서는 1번처럼 그렇게까지 사용하지 않음)

1. 깃에서 포크를 떠서 레퍼지토리를 각자 따로 작업하고
2. 다시 합치는 방식

해결 방법

1. 포크를 뜨는 경우는 오픈소스 프로젝트에서 참여자가 아닌 사람이 pr(풀리퀘스트를 날리기 위해서 사용함)
2. 보통 한 프로젝트를 같이 할 때
3. 하나의 레퍼지토리 안에서
4. 브랜치만 따로 가져가서 개발을 하고,
5. 그리고 풀리퀘스트를 만들어서, 머지 작업을 수행하는 방식을 추천드립니다.

사용법

1. github 오른쪽 상단 사진 누르기
2. your organizations로 팀 만들기
3. 팀원 추가 및 권한 설정
4. 회사는 프로젝트 멤버를 추가 후 계속 organizations안에서 팀단위로
5. 레퍼지토리를 만들어서 진행한다.
6. 마스터 브랜치 만들고, 디벨롭 브런치를 만드고, 개인 기능 만들고, 디벨롭 브런치에서 실행해보면서, 최종적으로는 마스터 브랜치에 합친다. 

단점 :

1. 일회성 팀에 경우에는 팀을 만들고, 세부적인 권한 설정도 해야하는 이 방식도 안 좋을 수 있다.
   1. 단 한번 설정하면 계속 쓰는 팀 특성상 회사에는 이 방법을 사용
2. 왜냐하면 기능이 너무 많아서, 오히려 실수 할 수 있기 때문이다.

• 튜터님 Answer : Collaborator(아래 Manage access를 통해서 관리되는 형태)가 없어도 각자 브런치를 만드는건 가능합니다. 아래의 스크린샷을 보시면 who has access 항목에 들어오는 모든 인원들이 접근할 수 있고 PR을 날릴 수 있고요. 보통 PR을 날리는건 오픈소스를 기준으로는 fork를 떠서 개인 repository로 만든 다음에 PR을 날리는게 일반적입니다.
• 하지만 오픈소스가 아닌 협업을 하는 목적으로 PR을 생성해서 관리하는 경우는 fork를 뜨지 않고 같은 repository에서 branch를 별도로 만든 다음에 기준이 되는 branch(master)에 PR을 생성해서 확인 후 merge하게 됩니다(김태선 튜터님이 설명하신 방식 - 팀 책임별로 권한부여)

---

결론 최종 : 현업에서 어떻게 작업을 하는게 가장 맞는 것인가?

1번 방식은 번거로워서 잘 쓰지 않는다.

2번 방식도 일일히 콜라보레이션을 추가해야 해서 쓰지 않음, 번거로움.

3번 방식이 일반적인 회사의 방식이다.(그러나 내배캠에서는 설정이 귀찮을  수 있고, 여러 세부 설정 필요)

 

결론 결국 장단은 있다. 그러나, 우리는 배우는 과정이니까, 각각의 장단점을 알고 있으면 훗날 도움이 될 날이 반드시 있을 것이다.