변경 이력을 남기며 협업하기

예시: 외부 기여자의 수정 제안과 검토

개념 설명용 시나리오 · 아래는 Git 협업 절차가 필요한 이유를 설명하기 위한 가상의 상황입니다. 이번 실습은 본인 저장소에서 진행하며, 외부 프로젝트에 기여하는 과제가 아닙니다.

혼자 작업한다면 main에서 직접 수정하고 Commit으로 이력을 남길 수 있습니다. 작은 팀에서 작업을 충분히 조율할 수 있다면, 친구를 Collaborator로 초대해 저장소 수정 권한을 공유하고 직접 반영하는 방식도 가능합니다. 항상 별도의 검토 요청을 거쳐야 하는 것은 아닙니다.

그런데 처음 보는 사람이 “설명을 고쳐 드릴게요”라고 제안한다면 어떨까요? 제안은 받아보고 싶지만, 기본 버전을 바로 바꿀 권한까지 줄 필요는 없습니다. 이때 자신의 사본에서 수정한 내용을 제안하고, 관리자가 검토한 뒤 반영하는 흐름이 유용합니다. 서로 아는 팀이라도 여러 사람이 사용하는 기본 버전에는 같은 검토 절차를 둘 수 있습니다.

공개된 실습 코드를 처음 사용하다가 README에 실행 준비 단계가 빠진 것을 발견했습니다. 나는 이 저장소를 직접 수정할 권한이 없지만, 안내를 보완해 관리자에게 제안하려고 합니다.

이 사례에서 팀이 주고받은 것은 수정한 파일만이 아니라 무엇을 바꾸었는지 확인할 수 있는 변경 이력입니다. 아래에서는 먼저 이력을 남기는 Commit을 이해하고, 그 이력을 Branch로 나누는 방법, PR에서 검토하고 Merge하는 방법을 차례로 살펴봅니다. 협업의 기초가 되는 변경 기록부터 시작하는 순서입니다.

1. 변경을 기록하는 단위: Commit

앞의 README 사례에서 파일을 저장하는 것만으로는 “어떤 준비 단계를 추가했는지”가 변경 이력으로 남지 않습니다. Commit은 선택한 변경을 설명과 함께 기록합니다. 이후의 비교와 검토는 이 기록을 바탕으로 이루어집니다. git status는 바뀐 파일을, git diff는 바뀐 내용을 확인하는 데 사용합니다.

2. 변경 이력을 나누는 Branch

Commit으로 변경을 남길 수 있게 되었다면, 다음은 기본 버전과 작업 중인 변경을 구분할 차례입니다. Branch는 같은 저장소에서 변경 이력을 나누어 관리합니다. 앞의 사례처럼 main에서 practice를 만들고 Commit하면, main을 유지하면서 practice의 변경을 비교·검토할 수 있습니다.

3. PR은 변경을 검토하는 요청

Pull Request(PR)는 별도의 작업 흐름인 Branch에서 만든 변경을 다른 Branch에 합치기 전에 검토해 달라는 요청입니다. 예를 들어 practice에서 수정한 내용을 기본 Branch인 main에 반영해 달라고 제안할 수 있습니다. PR을 만드는 것만으로 main이 바뀌지는 않습니다. 검토한 변경을 실제로 합치는 작업을 Merge라고 합니다. 제목에는 변경 목적을, 설명에는 실제 바꾼 내용을 적으세요. 상대방은 Files changed에서 차이를 확인하고 검토합니다.

4. Git과 GitHub의 역할

Commit과 Branch는 Git이 관리하는 변경 이력입니다. 내 컴퓨터나 Colab의 폴더에서도 사용할 수 있습니다. GitHub는 저장소를 온라인에서 공유하고, PR의 검토 의견과 반영 여부를 함께 관리하는 서비스입니다.

따라서 변경을 기록하는 Commit과, 그 기록을 GitHub에 보내는 Push는 서로 다른 작업입니다. 내 컴퓨터에서 만든 Commit은 Push해야 GitHub에도 반영됩니다. 앞의 협업 사례를 로컬에서 수행한다면 수정·Commit → Push → PR 순서로 이어집니다.

학습 내용 확인

1. 파일 저장·Commit·Push의 차이를 설명할 수 있나요?
2. PR의 변경 출발 Branch와 합칠 대상 Branch를 확인했나요?
3. Merge 후 main에서 수정한 내용과 이력을 찾을 수 있나요?

GitHub 공식 문서