오늘은 저장소 생성 → 팀원 초대 → 협업 규칙 적용까지 GitHub의 기본 협업 흐름을 실제로 따라 해 보았다. 간단한 실습이었지만, 프로젝트를 진행할 때 필수로 쓰이는 기능들을 손에 익히기에 충분했다.
1) 오늘 한 일
Repository 생성: 새 저장소를 만들고 프로젝트 기본 구조를 준비했다.
팀원 초대: Collaborator로 초대하여 권한을 부여하고, 저장소 접근을 테스트했다.
Projects / Issues 익히기:
Projects 보드에서 To-Do → In-Progress → Done 칼럼 흐름을 만들어 업무를 시각화.
Issues를 생성·할당하여 담당자/라벨/마일스톤로 업무를 분류하고 추적.
브랜치 보호 설정:
Require a pull request before merging를 활성화해 main 브랜치에 직접 커밋 금지.
PR로만 변경을 반영하도록 하여 리뷰 문화를 강제했다.
Pull Request 활용: 기능 브랜치에서 작업 후 PR을 열고, 리뷰/코멘트 과정을 거친 뒤 병합하는 흐름을 연습했다.
2) 주요 설정과 배운 점
Projects & Issues
Projects는 전체 업무 흐름을 칸반으로 한눈에 보여줘 진행률 파악이 쉽다.
Issues는 “담당자/라벨/마일스톤”을 지정해 검색성과 추적성이 좋아진다.
예) type:feature, type:bug 라벨로 업무 성격을 분류하고, 스프린트 단위 마일스톤으로 끊어 관리.
Branch & PR 정책
main은 항상 배포 가능한 안정 상태로 유지하기 위해 PR 필수를 적용.
기능 개발은 feature/* 브랜치에서 진행 → PR 생성 → 리뷰 통과 후 main으로 병합.
이 과정에서 자연스럽게 코드 리뷰, 대화(코멘트), 체크리스트 사용 습관이 생긴다.
협업의 기본 루틴(실습 흐름 요약)
이슈 발행(담당자/라벨/마일스톤 지정)
기능 브랜치 생성 후 개발
커밋 & 푸시 → PR 생성(리뷰어 지정, 설명/스크린샷 첨부)
리뷰 코멘트 반영, 충돌 해결
승인 후 병합
3) 실습 중 좋았던 점
명확한 변경 경로: main 직접 푸시를 막으니, 모든 변경이 PR을 통해 기록되어 히스토리가 깔끔해졌다.
역할과 책임 분명: 이슈에 담당자를 지정하니 누가 무엇을 하는지 모호함이 줄었다.
피드백 루프 형성: PR 코멘트로 작은 개선 사항도 바로잡을 수 있어 품질이 올라간다.
4) 시행착오 & 팁
직접 푸시 거절 오류: main 보호 규칙 때문에 push가 거절될 수 있다. 정상 동작이며, PR로 병합하면 해결된다.
브랜치가 뒤처졌을 때: PR에서 “Update branch” 또는 로컬에서 git fetch 후 rebase/merge로 최신 main을 반영한 뒤 다시 푸시.
5) 마무리
이번 실습을 통해 GitHub로 협업을 구성하는 최소 단위(이슈 → 브랜치 → PR → 병합)를 몸으로 익혔다.
앞으로 템플릿/라벨/컨벤션/체크를 조금씩 더해가면, 팀 규모가 커져도 일관성 있는 프로세스를 유지하면서 개발 속도와 품질을 함께 끌어올릴 수 있을 것 같다.
