오늘은 Git과 GitHub 수업을 듣고 팀 협업을 실습했다. 팀 저장소를 만들고, 한 명씩 돌아가며 텍스트 파일을 작성해 PR을 보내는 방식이었다.
작업은 작은 파일 하나였지만, 내 컴퓨터에서 만든 변경 내용을 팀에 공유하고 다시 받아오는 흐름까지 따라가 봤다.
작업을 기록하는 단위, 커밋
수업에서는 파일의 변경 이력을 남기는 기본 명령어부터 배웠다. add로 커밋에 담을 내용을 준비하고, commit으로 기록을 남긴다.
아래 파일명과 메시지는 설명용 예시다.
git status
git add 파일명.txt
git commit -m "docs: 실습 텍스트 추가"
git logstatus로 현재 파일 상태를, log로 커밋 이력을 확인한다. 파일을 저장하는 것과 Git에 변경 이력을 남기는 것은 별개다.
커밋 메시지에 붙이는 feat, fix, docs, refactor도 배웠다. 어떤 종류의 변경인지 메시지에서 드러내는 규칙이다.
브랜치를 나눠서 작업하기
이번 수업의 작업 규칙은 두 가지였다. main에서 직접 수정하지 않고 작업용 브랜치를 사용할 것, 한 파일은 한 명이 맡을 것.
git checkout -b 브랜치명새 브랜치를 만들면서 이동하는 명령이다. 이미 있는 브랜치로 이동할 때는 -b를 빼고 사용한다.
팀 실습에서도 작업 폴더에서 브랜치를 변경한 뒤 텍스트 파일을 만들고, add와 commit을 진행했다. 이후 main으로 이동해 개인 저장소에 올리는 순서였다.
여기서 브랜치 이동과 병합은 구분해야 한다. git checkout main은 이동만 하므로, 작업 브랜치의 커밋을 main으로 보내려면 별도로 합치는 과정이 필요하다. 이 연결 부분은 다시 복습해볼 예정이다.
개인 저장소에서 팀 저장소로
수업에서는 원격 저장소를 두 개로 구분했다.
origin: 개인 GitHub 저장소project: 팀 GitHub 저장소
이번 실습에서 붙인 이름이며, Git에서 역할이 고정되어 있는 것은 아니다.
개인 저장소에 올릴 때는 다음 명령을 사용했다.
git push origin main로컬 main을 개인 저장소에 올린 뒤, 팀 저장소로 PR을 요청하고 팀장이 승인하는 과정을 진행했다. 팀원들이 한 명씩 돌아가며 같은 흐름으로 작업했다.
PR은 변경 내용을 반영해달라는 요청이다. 승인과 병합은 별도 단계라서 실제로 팀 저장소에 합쳐졌는지도 확인해야 한다. GitHub PR 문서
마지막에 pull과 push를 다시 하는 이유
팀장 승인 이후에는 팀 저장소의 내용을 받아오고, 개인 저장소에 다시 올리는 순서로 진행했다.
git pull project main
git push origin mainpull은 팀 저장소의 main을 가져와 현재 브랜치에 통합한다. 로컬 main을 갱신하려면 먼저 해당 브랜치에 있어야 한다. Git pull 문서
이어지는 push는 받아온 내용을 개인 저장소에도 반영하는 단계다. 처음에는 내 작업을 올렸고, 마지막에는 팀에서 바뀐 내용까지 개인 저장소에 맞췄다.
실습을 마치고
오늘은 commit, push, PR, pull을 하나의 작업 안에서 사용해봤다. 각각 로컬에 기록하기, 원격에 보내기, 반영 요청하기, 변경 내용 받아오기로 역할을 나눠보니 전체 흐름을 정리하기 쉬웠다.
다음에는 작업 브랜치의 커밋이 main에 합쳐지는 과정을 다시 확인하려고 한다. PR에서도 어느 저장소의 어떤 브랜치에서 어디로 합치는지 함께 살펴볼 생각이다.
