[github] 프로젝트 협업하기

git과 github는 개발자라면 절대로 빼놓을 수 없는 협업 툴이다.

 

이번 시간엔 4명의 팀원과 함께 파이썬 streamlit을 활용한 간단한 코드 퀴즈 프로그램을 만들면서 github를 어떻게 활용하였는지 알아보겠다.

 

협업 내용을 좀 자세하게 보고 싶다면 https://github.com/CodeQuizz

CodeQuizz

 

여기로 와서 보면 된다.

 

 

 

github에선 그냥 맘대로 커밋을 하고 푸시를 해버리면 누가 어떤 걸 올렸는지 어떤 부분에 대한 내용인지 정확히 파악을 할 수 없다.

 

최대한 사람들이 알아보기 좋게 github에 꼭 추가 해야 하는 것들이 있다.

 

 

1. 작업의 투명성과 가시성

• README 파일 생성: 프로젝트의 개요, 설치 방법, 사용법 등을 정리하면 팀원뿐만 아니라 외부 기여자도 프로젝트를 쉽게 이해 가능하다.
• 이슈 생성 및 관리: 어떤 작업이 필요한지, 누가 담당하는지, 어떤 상태에 있는지 명확히 알 수 있다. 이를 통해 팀원 간의 역할 분담이 쉬워지고, 중복 작업을 방지할 수 있다.
• 마일스톤 설정: 프로젝트의 큰 목표나 주요 단계를 설정하여 진행 상황을 시각화하고, 일정 관리에 도움을 준다.

 

 

2. 추적 가능성

• PR(Pull Request)에 이슈 번호 연결: 특정 PR이 어떤 문제를 해결하려는 것인지 명확히 알 수 있다. 나중에 문제가 발생했을 때 어떤 변경사항이 원인이었는지 추적하기가 용이하다.
• 라벨링: 작업의 성격(버그 수정, 신규 기능, 문서화 등)을 라벨로 표시하면 전체적인 작업 흐름과 우선순위를 쉽게 파악할 수 있다.

 

 

3. 협업의 효율성

• 리뷰 과정: PR을 통해 코드 리뷰를 진행하면서 품질을 높이고, 버그를 사전에 잡을 수 있다.
• 분산된 작업 관리: 팀원들이 각자 작업을 하고, 완성된 작업만 병합하기 때문에 효율적으로 병렬 작업이 가능하다.

 

 

4. 코드 품질과 유지보수성 향상

• 커밋 메시지 관리: 어떤 변경 사항이 있었는지 명확히 기록하면 나중에 다른 사람이 코드를 읽고 이해하기 쉽다.
• 변경 이력 추적: 프로젝트가 커질수록 변경 사항을 기록하고 관리하는 것이 중요하다. 협업 규칙을 따르면 이력이 체계적으로 관리된다.

 

 

5. 오류 방지

• 임의의 커밋과 푸시 방지: 정해진 규칙 없이 아무렇게나 작업하면, 나중에 코드 충돌이나 의도치 않은 버그가 발생할 가능성이 커지므로 규칙을 지키면 이런 상황을 최소화할 수 있다.

 

 

이 과정은 혼자 작업할 때는 복잡하게 느껴질 수 있지만, 협업 시에는 반드시 필요하다.

 

특히 팀 프로젝트나 오픈소스 프로젝트에서 일할 때는 협업의 체계가 프로젝트 성공의 핵심 요소가 된다.

 

 

 

 

Team Building 과정

 

 

1.  Organization 팀원 초대 후 프로젝트 생성

 

 

 

 

함께할 팀원들을 먼저 organization에 추가한 후

 

 

우리가 할 프로젝트를 생성했다.

 

 

 

 

 

이런 식으로 할 일과 진행 중인 일, 완료한 일 순서로 프로젝트 이슈를 구성한다.

 

이슈는 여기서 구성해도 되고 프로젝트의 레포에 들어가서 생성해도 된다.

 

상황 진행이 될 수록 드래그 해서 옆으로 옮길 수가 있다. 다 완료가 되었으면 이슈를 close 하거나 프로젝트에 들어와서 done으로 드래그할 수 있다.

 

 

 

 

마일스톤을 생성하여 진행상황 또한 시각화할 수 있게 한다.

 

 

 

 

2.  Readme 생성과 Branch 나누기

 

 

 

 

프로젝트 소개, 사용법 제공, 주의사항 등을 한 눈에 알 수 있게 Readme에 기재해놓으면 프로젝트에 대해 이해하기 쉬우므로 해야 한다.

 

 

 

main은 최종본을 할 때에 필요하므로 그 전까지 default 브랜치를 개발 브랜치인 develop으로 해놓고 앞으로 이슈를 생성한 것에 대한 pr을 develop으로 할 수 있게 한다.

 

 

밑의 active 브랜치의 내용들은 추후에 다시 설명하겠다.

 

 

 

 

3. 이슈 생성, 로컬 저장소 -> 원격 저장소로 올리기.

 

 

 

 

이슈 생성에 들어와서 이슈 템플릿을 생성한 뒤 이 템플릿에 맞도록 이슈를 생성해준다.

 

 

 

assigneers를 통해 누가 이 이슈를 생성했는지 확인할 수 있게 하고

 

 

 

 

labels를 통해서 어떤 목적으로 작업을 하는 것인지 또한 확인할 수 있다.

 

label은 직접 내 식대로 만들 수도 있다.

 

 

이런 식으로 이슈에 채울거 채운 뒤 생성하면

 

 

 

이슈에 대한 태그 번호가 나와있는데 이 번호를 참고하여 로컬에 브랜치를 만들고 작업을 수행한 뒤

 

원격 브랜치로 올려주면 된다.

 

 

 

이제 내 로컬 브랜치에 와서 

 

git checkout -b feat/#62/Login 같은 형식으로 브랜치를 생성한다.

 

 

브랜치 생성 후 작업을 수행한 뒤 

 

git status
git add .
git commit -m "[#62]feat: 로그인 ui 개선"

 

 

을 통해 로컬에서 커밋을 완료하고

 

git push -u origin feat/#62/Login

 

 

 이런 형식으로 upstream을 통해 원격 저장소를 생성하고 연결해주는 명령어를 입력한다.

 

 

 

 

4. develop에 머지하기

 

 

이제 원격저장소에 들어가서 

 

 

 

이렇게 develop에 pr을 날려주면 우리 팀이 코드 리뷰를 주고, 그에 맞춰 머지를 해주면 된다.

 

 

 

 

리뷰어는 pr을 올린 팀원의 코드를 보고 문제점이 있는지 확인 후 승인한다.

 

담당자는 리뷰어의 코멘트 확인 후 여러 개의 커밋을 하나로 합치는 squash and merge를 해주면 된다.

 

 

지금까지의  작업이 반복되고 끝날 때마다 브랜치 삭제와 이슈 close를 하다보면 마일스톤도 차게 되고 결국 프로젝트 관리가 용이하게 되는 것이다.

 

 

 

 

 

화면설계서와 RNR과 WBS도 만들어봤다. 간단하게 md파일로 만들어보았다.

 

 

 

 

 

 

 

 

 

이런 협업 과정을 통해 github에 익숙해진다면 더 큰 규모의 프로젝트에도 참여할 수 있지 않을까 생각한다. 

 

더 익숙해져서 팀 프로젝트에 CI/CD까지 곧 적용시킬 생각이다.