하루 협업 흐름 완성

마지막 레슨입니다. 지금까지 배운 조각들(커밋, 브랜치, push/pull, PR, 되돌리기)을 하나의 '하루 협업 흐름'으로 이어 봅시다. 실무 개발자는 매일 이 루프를 돕니다. 한 바퀴만 제대로 돌려 보면, 앞으로의 모든 작업이 이 리듬의 반복이라는 걸 알게 됩니다.

하루 흐름 따라 하기

브랜치→작업→커밋→푸시→PR→리뷰→머지 루틴

1. git pull 로 원격(main)의 최신 상태를 받아 옵니다. (항상 최신에서 시작)
2. git switch -c feature/오늘작업 으로 오늘 할 일을 위한 새 브랜치를 만듭니다.
3. 코드를 작업하고, 의미 단위로 git add → git commit -m "..." 로 커밋합니다. (여러 번 나눠서)
4. git push -u origin feature/오늘작업 으로 브랜치를 원격에 올립니다.
5. gh pr create 로 PR을 열고, 무엇을 왜 바꿨는지 설명을 적습니다.
6. 팀원(또는 나 자신)이 리뷰합니다. 수정 요청이 있으면 고쳐서 다시 커밋·push (PR에 자동 반영).
7. 승인되면 PR을 merge해 main에 반영하고, 다 쓴 브랜치는 정리합니다. 그리고 다시 1번으로.

팀 협업 에티켓

• 작은 PR: 한 PR에 한 가지 목적만. 거대한 PR은 리뷰가 불가능합니다.
• 설명 성실히: 리뷰어가 코드를 열기 전에 맥락을 알 수 있게 씁니다.
• 리뷰는 코드에 대한 것: 사람이 아니라 코드를 이야기합니다. 지적도, 받아들임도 담백하게.
• main은 신성하게: main에 직접 push하지 않고 항상 PR을 거칩니다.

한 걸음 더: Issues와 Actions 맛보기

GitHub Issues는 '할 일·버그 목록'을 팀과 공유하는 게시판입니다. '로그인 화면 버그', '회원가입 기능 추가'처럼 해야 할 일을 이슈로 등록해 두고, 누가 맡을지 정하고, 관련 PR과 연결합니다. 코드와 할 일 관리가 한곳에서 이뤄지는 것이죠.

GitHub Actions는 '자동 검사 로봇'입니다. PR이 올라올 때마다 자동으로 테스트를 돌리거나 코드 형식을 검사하게 설정할 수 있습니다. 사람이 매번 확인하지 않아도, 통과하지 못한 코드는 병합되지 못하게 막아 주는 든든한 문지기입니다. 지금은 '이런 게 있다'는 정도만 알아 두면 충분합니다.

README와 오픈소스 기여 첫걸음

저장소 첫 화면에 보이는 설명 문서가 README.md입니다. '이 프로젝트가 무엇이고, 어떻게 설치·실행하는지'를 적는 프로젝트의 얼굴입니다. 내 저장소에 README를 잘 써 두면, 나중의 나와 방문자 모두에게 친절한 안내가 됩니다.

그리고 지금 배운 흐름(브랜치 → 커밋 → PR)은 사실 전 세계 오픈소스에 기여하는 방법과 똑같습니다. 마음에 드는 오픈소스 프로젝트를 Fork(내 계정으로 복제)하고, 작은 오타 수정이라도 브랜치를 만들어 PR을 보내면, 그것이 첫 오픈소스 기여입니다.

완벽하게 이해한 뒤 시작하려 하지 마세요. 오늘 배운 루프를 나만의 연습용 저장소에서 딱 세 바퀴만 돌려 보세요. 세 번째쯤이면 명령어가 손에 붙기 시작합니다. Git은 눈으로 읽어 익히는 것이 아니라, 손으로 커밋을 쌓으며 익히는 도구입니다.

협업 저장소에서 가장 중요한 습관 하나만 꼽자면, '작업 전 git pull, main에는 직접 push 금지'입니다. 이 두 가지만 지켜도 팀 작업이 꼬이는 사고의 대부분을 예방할 수 있습니다.

여기까지 오셨다면, 여러분은 이제 버전관리의 언어를 할 줄 아는 사람입니다. 커밋으로 안전하게 저장하고, 브랜치로 자유롭게 실험하고, PR로 함께 만들고, 클로드 코드로 이 모든 것을 말로 시킬 수 있습니다. 처음의 '수정본_최종_진짜최종'은 이제 안녕입니다. 여러분의 첫 커밋을, 그리고 첫 PR을 진심으로 응원합니다.