[Git] - Git을 사용한 협업 (자주 사용되는 용어 정리)

Git & GitHub - Collaboration tools

 

 

 

 

1. Git을 통한 협업 - Fork, Clone

1-1. Fork

(1) Fork 작업은 타인의 프로젝트나 또는 공동 소유의 프로젝트 소스와 Commit 내역, Branch의 구조를 그대로 복사하여 본인 소유의 새로운 Repository를 생성하는 작업을 의미한다.

 

(2) 이러한 fork는 본인 개인 소유이기 때문에 fork를 통한 작업 내용이 원본 코드에 반영되지 않는다. 따라서 새로운 기능을 개발하거나 테스트할 때 원본 코드에 영향을 주지 않는 방법이다.

 

 

 

 

1-2. Clone

(1) Clone은 원격 저장소의 모든 코드 파일들을 그대로 본인의 작업 환경으로 가져오는 것이다.

 

(2) Fork와 비슷해 보이는데 Fork는 본인의 개인 호스팅 리포지토리(Repository, 저장소)로 끌고 와서 새로운 리포지토리를 생성하는 작업이고, Clone은 개인 리포지토리로 가져오지 않고 본인의 개발 환경으로 직접 가져오는 방법이다.

 

 

 

 

 

 

2. 기본적인 용어 정리 

2-1. Commit

(1) Commit(커밋)이란 로컬 저장소의 코드 변경 사항을 저장하는 것을 의미한다.

 

(2) 로컬 저장소의 변경사항을 Staging area라는 영역으로 올리는 작업이다.

 

(3) 일반적인 Commit command

git commit -m "Commit Message"

 

 

 

 

2-2. Push

(1) Push(푸시)는 Staging area 영역으로 올라온 로컬 저장소의 코드 변경사항을 원격 저장소에 반영하는 것을 말한다.

 

(2) 현재 작업 중인 브랜치에서 발생한 변경사항을 원격 저장소의 해당 브랜치로 반영하게 된다.

 

(3) 아래와 같은 커맨드로 Push 할 수 있다.

git push --set-upstream origin "현재 로컬 브랜치명"

 

 

 

 

2-3. Merge

(1) Merge(병합)은 특정 브랜치에서 다른 브랜치로 코드의 변경 사항을 통합하는 작업을 말한다. 주로 작업 브랜치에서 모든 개발이 완료되었을 때 모든 변경 사항을 특정 브랜치로 통합하기 위해 Merge를 진행하게 된다.

 

- 예를 들어 BE#2-Entity 브랜치의 변경 사항을 develop 브랜치로 통합하고자 할 때 사용

- 모든 개발이 완료되어 develop 브랜치의 변경 사항을 실제 배포 환경의 main 브랜치로 통합하고자 할 때 사용

 

 

(2) Push와 헷갈릴 수 있는데, Push는 로컬 저장소의 변경 사항을 원격 저장소로 반영하는 작업이고, Merge는 코드의 변경사항을 브랜치 간에 통합이 필요할 때 진행하는 작업이다.

 

 

(3) 협업 프로젝트에서는 Merge 이전 이 부분에 대한 Pull Request(PR, 풀 리퀘스트)를 진행한 후 코드 리뷰를 통해 Merge가 가능하다고 결정되면 Merge 하는 것이 일반적이다. Pull Request에 대해선 아래에서 더 자세하게 적어보겠다.

 

 

 

 

2-4. 기본 명령어 : 브랜치 리스트 확인

git branch

 

로컬 저장소의 브랜치 리스트가 출력된다.

(2) 위와 같이 브랜치 리스트들이 확인된다.

 

 

 

 

2-5. 기본 명령어 : 해당 브랜치로 이동하기

git checkout "브랜치명"

 

브랜치 간 이동

(1) develop 브랜치에서 각 기능을 개발하는 Feature 브랜치인 BE/#2-Entity 브랜치로 이동했다.

 

 

 

 

2-6. Push

git push --set-upstream origin "작업 브랜치명"

(1) 로컬 저장소에서 작업 중인 브랜치의 변경 사항을 실제 원격 저장소의 해당 브랜치로 반영하는 작업이다.

 

(2) 이후 GitHub 원격 저장소에서 해당 브랜치를 확인해 보면 변경사항들이 반영되어 있는 것을 확인할 수 있다.

 

(3) 여기서 upstream, origin이라는 커맨드가 나오는데 어렵게 생각하지 말자. 하나씩 설명해 보겠다.

- origin : 호스팅 웹 서비스인 GitHub에 저장된 실제 원격 저장소(Remote Repository)

 

- upstream & downstream : 상대적인 개념으로 접근하면 조금 이해하기 수월하다. 본인의 작업 환경을 local(로컬, Local Repository), 실제 원격 저장소를 origin이라 했다면 이 둘 간에는 상대적인 개념이 생기는데 바로 origin이 upstream, local이 downstream이 된다.

 

- 이처럼 upstream&downstream으로 상대적인 작업 플로우(스트림)가 형성되었기 때문에 local에서 origin으로 push, origin에서 local로 pull을 할 수 있다.

 

 

(4) 협업 프로젝트에선 이 변경 부분에 대한 내용을 Pull Request를 진행하여 코드 리뷰를 받고 일정 이상 Approve를 받아서 Merge가 가능하다고 판단될 때 코드 리뷰어나 협업 관리자의 허락을 받고 Merge 한다.

 

 

 

 

 

 

3. Pull Request(PR)

3-1. Pull Request

(1) Pull Request(PR, 풀 리퀘스트)는 개발자들이 코드의 변경 사항을 리뷰하고 주 브랜치에 Merge 하기 위한 방법 중 하나이다. 원격 저장소의 주 브랜치에 작업한 내역을 통합하기 전, 여러 개발자들에게 확인 작업 및 코드 리뷰를 요청하는 과정이라고 생각하면 쉽다.

 

 

 

 

3-2. Pull Request 과정 

(1) 특정 브랜치를 새롭게 생성하여 코드 작업을 진행한다.(기능 구현, 버그 수정 등)

 

(2) 이를 통해 변경된 코드의 변경 사항을 커밋하고 푸시한다. 기능 개발 또는 특정 브랜치에 지금까지 작업한 변경 사항들이 모두 반영된다.

 

(3) 이후 Pull request를 생성할 수 있는데, 이를 통해 여러 협업하는 개발자들에게 코드의 변경 사항에 대한 검토를 진행하는 코드 리뷰를 진행할 수 있다. 저장소에서 일정 이상의 Approve를 받아야 merge가 가능하도록 설정 또한 가능하다.

 

(4) 코드 리뷰를 통해 잘못된 부분, 더 좋은 코드에 대한 피드백을 받을 수 있다.

 

(5) 코드 리뷰가 완료되고 모든 피드백 사항을 반영했다면 코드 리뷰어나 협업자의 Approve를 받아 Merge를 진행한다.

 

 

 

 

 

 

 

 

※ 해당 포스팅에 대해 내용 추가가 필요하다고 생각되면 기존 포스팅 내용에 다른 내용이 추가될 수 있습니다.

개인적으로 공부하며 정리한 내용이기에 오타나 틀린 부분이 있을 수 있으며, 이에 대해 댓글로 알려주시면 감사하겠습니다!