[GIT] Git 동작 원리 + git Pull Request + Git 워크 플로우

황준승·2021년 9월 27일

git

👍 git이란?

형상 관리 도구로 다른 말로는 버전관리 시스템이다. 이는 소프트웨어를 개발하는 기업의 핵심 자신인 소스코드를 효과적으로 관리할 수 있게 해주는 무료 공개 소프트웨어입니다.

이러한 git의 가장 큰 장점은 여러 사람이 소스코드를 주고 받을 필요없이 같은 파일을 여러 명이 동시에 작업하는 병렬 개발이 가능하다는 점입니다.

이러한 병렬 개발을 가능하게 해주는 것이 바로 branch 이다.

🐵 git branch

브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않아 여러 작업을 동시에 진행할 수 있습니다.

또한 이렇게 만들어진 브랜치는 다른 브랜치와 병합(Merge)함으로써, 작업한 내용을 다시 새로운 하나의 브랜치로 모을 수 있습니다.

아래의 명령어를 통해 브랜치를 생성, 통합, 제거 할 수 있습니다.

$ git branch : 현재 사용되고 있는 branch를 보여줌
$ git branch [만들려고 하는 브랜치 명] : 새로운 브랜치를 하나 만듦
$ git checkout [브랜치 명] : 사용하고자 하는 브랜치를 지명한다.
$ git merge [브랜치 명] : master의 branch와 해당 branch를 통합한다. (이 때 사용하고 있는  branch는 항상 master여야 한다. ) (통합을 했다면 반드시 썻던 브랜치는 제거해야한다.)
$ git  branch –d [브랜치 명]: 해당 브랜치를 제거한다.

🐷 git commit 동작 과정

<그림 설명>

Working Directory: 작업할 파일이 있는 디렉토리
Staging Area : 커밋(commit)을 수행할 파일들이 올라가는 영역
Local Repository : 커밋된 파일들이 저장되어져 있는 공간 (하나의 커밋 당 하나의 버전이라 생각하면 쉽다.)
Remote Repository : git프로젝트의 메타 데이터와 데이터 정보가 저장되는 디렉토리

따라서 다음과 같은 과정을 통해 내 컴퓨터의 파일을 git repository에 저장할 수 있다.

git add [파일명] // Staging Area에 파일을 추가 저장(파일명이 . 일 경우 해당 파일에 있는 모든 파일 Staging Area 저장)

git commit -m "커밋 메세지" // local repository에 저장

git push // remote Repository에 저장

그 외
git fetch를 통해 git repository에 있는 커밋을 다운로드 받을 수 있고 git merge를 통해 다운 받은 커밋 내용을 내 컴퓨터에 다운받아 코드를 볼 수 있다.

git fetch와 merge는 pull 명령어를 통해 git repository에 있는 파일들을 한 번에 다운로드 받을 수 있다.

🐦 Pull Request

1. Fork

타겟 프로젝트의 저장소를 자신의 저장소를 Fork한다.

2. clone

해당 파일의 내용을 다운로드 하기 위해 git clone을 한다.

git clone <fork한 git주소>

만약 브랜치가 너무 많아 브랜치 전체를 clone하지 않고 특정 브랜치 하나만 clone하려면 이 방법을 사용하면 된다.

git clone https://github.com/{본인 GitHub Username}/{저장소이름} -b 브랜치명--single-branch

3. commit

git add 파일명(or * 모두) // 추가/변경 파일
git commit -m "메세지" // 커밋

4. push

git push origin 본인_브랜치

5.Pull Request 생성

push 완료 후 본인 계정의 github 저장소에 들어오면 Compare & pull request 버튼이 활성화 되어 있다.
해당 버튼을 선택하여 메세지를 작성하고 PR를 생성한다.

6. 코드리뷰, Merge Pull Reqest

PR을 받은 원본 저장소 관리자는 코드 변경내역을 확인하고 Merge 여부를 결정한다.

7. Merge 이후 동기화 및 branch 삭제

원본 저장소에 Merge가 완료되면 로컬 코드와 원본 저장소의 코드를 동기화 한다.
작업하던 로컬의 branch를 삭제한다.

🐼 다양한 branch전략(gitflow, git workflow, gitlab workflow)

여러 명이서 협업 프로젝트를 하다보면 필연적으로 Git을 사용하게 됩니다.
이때 git을 사용하다보면 일관성있는 규칙의 필요성을 느끼게 됩니다. 이때 개발자는 gitflow, git workflow, gitlab workflow 등과 같은 워크 플로우 전략이 제시되었습니다.

1. Gitflow

Gitflow는 최초로 제안된 git 워크플로우입니다. 이 워크플로우는 대규모의 프로젝트를 관리하는 데 적합한 것으로 평가받고 있습니다.

Gitflow의 브랜치 전략

Gitflow의 작업 방식을 이해하려면 Gitflow의 브랜치 전략에 대해 이해해야 합니다.
Gitflow는 5가지의 브랜치 규정하고 있습니다.

a. Master : 릴리즈를 할 때 사용하는 최종단계의 메인 브랜치

b. Develop : 다음 릴리즈 버전 개발을 진행하는 브랜치입니다. 어떤 기능 구현이 필요해지면 Develop브랜치에서 다시 브랜치를 내어 개발을 진행하며, 개발이 완료된 기능은 다시 Develop브랜치로 병합

c. Feature : 앞서 Develop브랜치에서 기능 구현을 이유로 브랜치를 생성하게 되는 데 그 브랜치가 바로 Feature 브랜치입니다. 브랜치 생성 기준은 한 기능 단위이다.

d. Release : Develop 브랜치에서 파생되는 브랜치이다. 현재 코드가 Master 브랜치로 병합될 수 있는지 테스트하고 테스트 과정에서 발생한 버그를 고치는 역할을 담당합니다.

e. Hotfix : Release브랜치를 통해 테스트 과정을 거쳤음에도 Master브랜치에서 버그가 발견될 수 있습니다. 이때 Master branch에서 Hotfix브랜치를 내어 버그를 수정. 디버그가 완료되었다면 Master 브랜치와 Develop브랜치에 병합해주고 브랜치를 닫습니다.

문제점

이러한 브랜치 전략은 엄격하게 각각의 브랜치의 역할을 규정하기에 위에서도 언급하였듯 계획적인 릴리즈를 스케줄링하는 대규모 프로젝트에 적합하다. 이는 대다수의 소프트웨어 개발에는 불필요한 절차를 준수하도록해 생산성을 떨어트리기도 합니다.

2. Github flow

Master브랜치가 릴리즈에 있어서 절대적인 역할을 합니다. Master브랜치는 항상 최신 버전을 유지합니다. 그리고 무조건적으로 stable한 상태를 담보합니다. Develop브랜치가 존재하지 않고 Feature브랜치는 Master브랜치에서 생성되며,병합됩니다. 병합을 할 때는 무조건 pull request를 하여 코드에 대한 검토를 받도록 합니다. Github flow는 CI가 필수적입니다.

3. Gitlab flow

Gitlab flow는 너무 단순해진 Github flow에 보완하는 내용을 가미하여 제안된 방식입니다. Gitlab에는 Production 브랜치가 있는데, 이는 Gitflow의 Master브랜치역할과 같습니다. Gitlab flow의 Master브랜치는 Production 브랜치로 병합합니다. 이렇게 브랜치전략을 가져갈 때의 이점은 Production브랜치에서 릴리즈된 코드가 항상 프로젝트의 최신버전 상태를 유지해야할 필요가 없다는 것입니다. Gitflow와 Github의 절충안이라는 느낌을 줍니다.

결론

어떤 방식이 더 나은 방식이라고 꼽을 수는 없습니다. 몇 명의 개발자가 참여하는지, 릴리즈 계획은 어떤 방식인지 등등 모든 프로젝트의 상황은 같지 않기 때문입니다. 때문에 팀의 상황을 파악하여 적절한 방식의 워크플로우를 채택하는 것이 팀의 생산성을 높이는 데 중요합니다.