🫧 나의 상황
이전에 다른 프로젝트를 진행할 때는 항상 원격 저장소에서 git clone만 해서 프로젝트를 진행했었다.
clone 한 후에 각자의 개발 브랜치를 생성하여 해당 브랜치 안에서만 개발과 merge 등을 했었는데, 이번에는 처음 해보는 방식으로 github를 활용하게 되었다.
💡포크 앤 풀(Fork and Pull) 워크플로우란?
소프트웨어 개발에서 협업은 필수적이다.
특히, 팀 프로젝트에서는 여러 개발자가 함께 작업하는 것이 일반적이고
이때, 각자의 작업을 안전하고 효율적으로 관리하기 위해 사용하는 대표적인 협업 방식이 바로 포크 앤드 풀(Fork and Pull) 워크플로우라고 할 수 있다.
1. 팀 깃허브 페이지 생성하기
포크 앤드 풀 워크플로우를 시작하기 위해서는 우선 팀 깃허브 페이지를 설정해야 한다.
이 페이지는 팀 프로젝트를 관리하고 협업할 수 있는 기본 플랫폼이 된다.
1. 깃허브에 로그인한다: 자신의 깃허브 계정에 로그인한다.
2. 팀 페이지를 생성한다:
• 깃허브 대시보드에서 ‘New Organization’을 선택하여 팀 페이지를 생성한다.
• 팀 이름, 설명, 기타 설정을 입력하여 새로운 팀을 생성한다.
2. 팀 레포지토리 만들기
팀 페이지가 생성되면, 팀이 사용할 레포지토리를 만들어야 한다.
이 레포지토리는 모든 팀원이 작업할 수 있는 중앙 저장소 역할을 한다.
1. 팀 페이지로 이동한다: 생성한 팀 페이지로 이동한다.
2. 새 레포지토리를 생성한다:
• ‘New Repository’ 버튼을 클릭하여 새로운 레포지토리를 생성한다.
• 레포지토리 이름, 설명, 공개 여부를 설정하고 ‘Create repository’를 클릭한다.

(각각의 레포지토리를 생성하는게 아니라 그 밖에 한 번 더 팀이라는 단위로 묶어서 그 안에 프론트/백엔드 레포지토리를 생성할 수 있다는 사실을 이번에 처음 알게 되었다..)
3. 포크(Fork)하여 개인 레포지토리 만들기
팀 레포지토리를 개인 깃허브 계정으로 포크(Fork)하면, 독립적인 작업 환경이 생성된다.
이를 통해 자신만의 레포지토리에서 자유롭게 작업할 수 있다.
1. 팀 레포지토리로 이동한다: 팀 깃허브 페이지에서 팀 레포지토리를 연다.
2. 포크 버튼을 클릭한다: ‘Fork’ 버튼을 클릭하여 개인 계정으로 레포지토리를 복사한다.
3. 개인 레포지토리를 확인한다: 개인 계정의 레포지토리 목록에서 포크된 레포지토리를 확인한다.
(지금까지는 포크와 clone의 기능의 차이에 대해서 깊게 생각해 본 적이 없고, 늘 git clone 기능만 사용했었는데 이번에 fork라는 기능을 처음 사용해 보게 되었다. 그런데 clone과 다르게 새로운 나만의 레포지토리가 생긴다는 사실이 너무 충격적이었다.. 이런 좋은 기능을 이제야 제대로 알게 되었다는 것이 2차 충격...)

4. 클론(clone)허여 로컬 작업 환경 만들기
포크 된 레포지토리를 로컬 환경으로 클론 하면, 자신의 컴퓨터에서 작업을 시작할 수 있다.
또한, 팀 레파지토리의 원격 주소를 추가하여 팀 레포지토리의 최신 변경 사항도 로컬에서 관리할 수 있다.
1. 클론 URL을 복사한다: 포크된 레포지토리 페이지에서 ‘Code’ 버튼을 클릭하고, HTTPS 또는 SSH URL을 복사한다.
2. 로컬 클론을 수행한다:
git clone https://github.com/username/forked-repo.git
이렇게 하면, 포크 된 레파지토리의 내용을 로컬 컴퓨터로 복사할 수 있다.
3. 팀 레포지토리의 원격 주소 추가하기:
- 클론한 로컬 레포지토리로 이동한다.
cd forked-repo
- 팀 레포지토리의 원격 주소를 로컬 레포지토리에 추가한다.
git remote add upstream https://github.com/team-username/team-repo.git
4. 팀 레포지토리의 최신 변경 사항을 로컬에 반영하기:
- upstream 원격 저장소에서 변경 사항을 가지고 온다.
git fetch upstream
- 가져온 변경 사항을 로컬 브랜치에 병합한다.
git checkout main
git merge upstream/main

❓upstream 이라는 이름을 사용하는 이유 ??
1. 명확한 구분: origin은 일반적으로 포크 한 개인의 원격 저장소를 가리키고, upstream은 팀의 원본 저장소를 가리킨다.
두 저장소가 동일하지 않기 때문에, 명확한 이름을 통해 혼동을 줄일 수 있다.
2. 작업 흐름의 이해: 팀 프로젝트에서 upstream을 활용하여 원본 저장소의 변경 사항을 가져오고(pull),
이를 자신의 origin 저장소에 반영하는 워크플로우가 일반적이다. 이를 통해 협업 시 최신 상태를 유지하며 작업할 수 있다.
3. 컨벤션: upstream이라는 이름은 오랜 기간 동안 개발자들 사이에서 표준으로 자리 잡아 왔기 때문에, 팀 내에서 다른 사람들과 협업할 때 의사소통이 더 원활해진다.
꼭 upstream이라는 이름을 사용할 필요는 없지만, 이 컨벤션을 따르면 협업할 때 서로 이해하기 쉽고, 작업 흐름이 명확해진다는 장점이 있다.

'개발일지 > League Linker' 카테고리의 다른 글
🤦🏻♀️고민하기 - Spring Security_API 경로에 따른 인증 및 역할 관리(1) (2) | 2024.09.04 |
---|---|
[spring boot] - Swagger로 API 문서화하기 (0) | 2024.09.03 |
[개발] - MapStruct를 사용하여 매핑 구현하기 (0) | 2024.09.01 |
🚨ERROR - [spring boot] GET 요청 시 406 오류 발생 (0) | 2024.08.31 |
[개발환경] H2 DB 선택과 연결하기 (0) | 2024.08.09 |