이 글의 목적?
이번에 작성할 글은 이전에 작성한 오픈 소스 기여 방법 포스팅과 동일하다. 하지만 이번에 새로운 프로젝트를 들어가니 다시 한번 살펴보자.
간략하게 살펴보자!
이번에 내가 정리할 내용을 간단하게 이미지로 살펴보자.
Fork를 이용한 협업 방법
내가 참고한 레퍼런스에서 이해하기 가장 적절한 이미지를 가져와 보았다. 왼쪽부터 순서대로 과정을 나열해보자.
1. 기여 방법
기여 방법은 보통 CONTRIBUTION.md, CONTRIBUTING_GUID.md 파일에 작성되어있다. 이 파일에는 해당 Repository에 기여하기 위한 조건들에 대한 지침이 기록되어있다. 규모가 큰 프로젝트일 경우 Fork를 이용한 방법을 많이 사용하니 해당 문서에 대한 기록에 신경써야 한다.
2. Fork
Fork를 하는 방법에 대해서는 생략하도록 하겠다. 다만, Fork된(main) Repository와 Fork한 Repository를 헷갈리지 않도록 조심해야한다. 용어를 잠깐 정리해보자.
- Fork된 Repository = Origin Remote Repository = Upstream Repository
- Fork한 Repository = Origin Repository
3. Clone
Origin Repository에서 내 Local Repository로 Clone 하는 과정이다. Clone 방법에 대해서는 생략하도록 하겠다. 단, Local Repository에서 추가적으로 설정해주어야 하는 내용만 살펴보자.
Clone이 완료되면, 기본적으로 내 Local Repository에는 Origin Repository 정보만 들어가있다. 여기서 우리는 Upstream Repository도 추가로 등록해주어야 한다.
# Upstream Repository 추가
git remote add upstream [Upstream Repository 주소]
# 등록된 원격 저장소 목록 확인
git remote -v4. 브랜치
브랜치 생성 방법에 대해서는 생략하겠다. 단, 가장 중요한 것은 각 저장소의 master 브랜치다. Upstream Repository가 가진 모든 Commit 내역을 가져와 로그를 확인해보면, Local Repository, Origin Repository, Upstream Repository 3곳의 master 브랜치가 모두 한곳에 모여있는 것을 확인할 수 있다. 쉽게 말하자면 모든 Repository의 master 브랜치는 하나다! 로 생각하면 된다.
# Upstream Repository가 가진 Commit 내역 가져오기
git fetch --all
# Commit History
git log -105. Fetch
Fetch 단계는 마지막으로 수정 내역을 반영하기 전에 Upstream Repository에서 다른 협업자들의 업데이트한 내역을 확인하는 단계다. 만약 내가 반영하고자 하는 내역에 Upstream Repository에서의 변경이 영향이 없다면 별도로 처리할 내용은 없지만, 영향이 있을 경우에는 Upstream Repository 변경 내역을 내가 반영할 예정인 내역에 적용시켜야한다.
# Upstream Repository 의 내용을 불러옴
git fetch upstream
# Upstream Repository master 브랜치를 내 Local Repository에 merge
git checkout master
git merge upstream/master6. Push & PR
마지막으로 나의 수정 내역을 반영하는 단계다. Local Repository에서 Origin Repository로 Push를 하면, GitHub UI의 'Compare & pull request' 버튼을 눌러 Upstream Repository에 PR을 날린다. 참고로 Local Repository에서 바로 Upstream Repository에 반영할 수는 있으나, Fork의 의미가 없어지고 의도치 않은 상황이 발생할 수 있으니 Upstream Repository에 직접 반영하는 일은 없어야 한다.
그리고 해당 PR이 반영이되면, master 브랜치로 이동하여 Upstream Repository의 커밋 내역을 가져와 동기화해주는 작업까지가 끝이다.
Fork 방법의 단점
지금의 나도 적응하는 단계라 그런지 가장 공감하는 Fork 방법의 단점은 해당 흐름을 이해하기가 쉽지 않다는 것이다. 또한 작업 상황을 리뷰하기가 쉽지 않다는 점도 있다. 따라서 대규모 프로젝트일 경우와 개인이 독립된 기능을 자유롭게 개발하고자 할 때 추천하는 방법이라고 한다.
무엇을 Git-Flow라고 지칭하는가?
여러 블로그를 살펴보면, Fork를 이용한 협업 방식을 "Git Flow 진행 방식, Git Flow 진행, One of the Git Flow" 등으로 내용이 정리되어있다. 그래서 나는 - "이전에 내가 정리한 Git-Flow와 Fork를 이용한 방식은 다른 전략인데 왜 하나의 동일한 개념으로 보고 있는거지?" 라는 의문이 들었다. 지금부터 나의 개인적인 생각을 정리해보고자 한다. ✍
- 하나의 동일한 개념으로 봤던 원인이 뭘까?
Git-Flow는 Git의 흐름을 의미한다. 그리고 Vincent Driessen 전략도 Git의 흐름이고 Fork를 이용한 방법 또한 Git의 흐름이기에 하나의 개념으로 바라보게 되었다고 생각한다.
- 그럼 어떻게 정리해야할까?
솔직히 둘 다 Git-Flow라고 지칭하는 것 보다 더 정확하게 Vincent Driessen의 방법을 브랜치 전략, Fork는 Repository 전략이라고 지칭하는게 맞다고 생각하지만, 대부분 Git-Flow를 검색하면 이 두 가지 전략 자체를 하나의 개념으로 바라보니 - Git-Flow는 모든 전략을 지칭하는 용어로, 그리고 그 전략들 중에서는 Vincent Driessen 브랜치 전략과 Fork 전략이 있다! 로 정리했다.
Git-Flow
- Vincent Driessen 브랜치 전략
- Fork 전략이 글의 레퍼런스
