Git,깃허브,GitHub,Git협업,PullRequest,Fork,브랜치,버전관리,오픈소스기여
| Git 협업, Fork와 Pull Request로 이해하기 |
Git과 GitHub을 이용한 버전 관리와 협업의 기본 흐름을 정리합니다. 혼자 작업할 때의 절차부터, 여러 사람이 함께 일할 때의 Fork → Pull Request 흐름까지 단계별로 살펴봅니다.
목차
Git 설치 (Windows)
먼저 Git을 설치합니다. 공식 사이트에서 운영체제에 맞는 버전을 내려받아 설치하면 됩니다.
Git - Downloading Package
Downloading Git Now What? Now that you have downloaded Git, it's time to start using it.
git-scm.com
설치를 마치면 명령줄(CLI)에서 git을 사용할 수 있습니다. 윈도우 기본 CMD보다는, 함께 설치되는 Git Bash를 사용하는 편이 더 편리합니다.
혼자 작업할 때의 기본 절차
로컬 저장소(local repo)에서 원격 저장소(remote repo)로 변경 사항을 동기화하는 기본 흐름입니다.
git add . # 변경 파일 스테이징
git commit -m "메시지" # 커밋(스냅샷 기록)
git push origin main # 원격 저장소로 반영
협업 플로우 (Fork → Pull Request)
여러 사람이 함께, 또는 오픈소스 프로젝트에 기여할 때의 일반적인 흐름입니다.
- 기여할 프로젝트를 Fork한다. (내 계정으로 저장소 복제)
- main(master) 기반으로 토픽 브랜치를 만든다.
- 코드를 수정하고 커밋한다.
- 내 GitHub 저장소의 브랜치로 Push한다.
- 원본 저장소로 Pull Request(PR)를 생성한다.
- 리뷰어와 토론하며 필요한 부분을 계속 커밋한다.
- 프로젝트 소유자가 PR을 검토 후 Merge한다.
Pull Request가 좋은 이유
Pull Request는 자연스러운 코드 리뷰를 위한 장치입니다. Push 권한이 없는 오픈소스 프로젝트에 기여할 때 주로 사용하고, 콜라보레이터(공동 작업자)로 소속된 경우에는 같은 저장소에서 브랜치를 따 Push한 뒤 PR을 올릴 수도 있습니다.
단순히 Push만으로 협업하면, 다른 사람이 그 커밋을 들여다볼 일이 많지 않고 보통 master 브랜치와 Merge할 때서야 확인하게 됩니다. 반면 PR은 '당장 Merge하지 않는다'는 규칙 덕분에, 변경된 코드를 한 번 더 살펴보게 만듭니다. 그 결과 어떤 작업이 언제 적용되었는지 추적하기 쉽고, 당황스러운 코드 충돌도 줄일 수 있습니다.
[참조: velog – Pull Request 이해하기]
정리하면, 나만의 저장소를 만들어 프로젝트를 진행하고, 변경 사항을 브랜치와 PR을 통해 공유하면 협업의 흐름이 한결 깔끔해집니다.