사지방에서 웹 백엔드 공부하기 #4 git, github 관리하기

프로젝트를 진행할때 git과 github를 이용해 관리를 하는 경우가 많다.

특히나 두 명이상 공동으로 진행하는 프로젝트라면 더더욱

 

git과 github의 차이가 뭔가요?

https://www.youtube.com/watch?v=YFNQwo7iTNc 

 

설명하기 귀찮으니까 더 잘 설명하는 사람의 영상과 글을 보도록 하자

https://backlog.com/git-tutorial/kr/

누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog

 

그럼 git을 이용해서 어떻게 프로젝트를 관리한다는 건가요?

바로 branch라는 녀석을 이용하면 됩니다.

그리고 branch를 사용하는 방법도 여러가지가 있는데 이를 브랜치 전략이라고도 합니다.

 

git branch [브랜치 이름]     #로컬 브랜치 생성
git checkout [브랜치 이름]   #브랜치 이동
git remote add [origin] [레포지토리 주소] # 원격 브랜치 연결
git clone [레포지토리 주소]   #깃허브 리포지토리 복사

git add .*
git commit -m "커밋 메세지"
git push origin main

1. git-flow 전략

https://techblog.woowahan.com/2553/

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

git flow 전략은 진행중인 프로젝트를 5가지의 브랜치로 나눠 관리한다.

 

1. main (master)  : 이미 완성된 출시가 가능한 브랜치

2. develop : 다음 버전을 개발하는 브랜치

3. feature : dev 브랜치에서 세부 기능을 개발하는 브랜치

4. release : 다음에 출시할 버전을 최종 준비하는 브랜치

5. hotfix : 출시 버전에서 발생한 버그를 긴급 수정 하는 브랜치

 

뭔가 기능을 추가하고 싶다면

1. main -> develop (현재 버전은 놔두고 개발을 진행할 브랜치 생성)

2. develop -> feature (세부 기능을 구현하는 브랜치 생성)

3. feature -> develop (각각 세부기능 구현 후 dev 브랜치에 merge)

4. develop -> release (release 브랜치 생성 후 다시 점검, 기능 추가 더 필요할 시 2,3 반복)

5. release -> main (출시해도 문제가 없을 시에 main 브랜치로 merge)

와 같은 과정을 겪는다.

 

2. github-flow 전략

git-flow의 복잡성이 github와는 어울리지 않다는 의견과 함께 나온 전략이다.

https://brownbears.tistory.com/603

[Git] 브랜치 전략 - Github flow

gihub-flow에선 한 개의 main 만 관리한다.

 

뭔가 기능을 추가하고 싶다면 feature 브랜치 1개만 새로 추가하여 만든 후 다시 main 브랜치에 merge 하면 된다.

dev,release브랜치와 같은 준비단계없이 main 브랜치에 바로 merge를 하기 때문에 Pull Request에 신경을 써야한다.

 

3. gitlab -flow 전략

github-flow 전략은 너무 단순하다는 의견과 함께 나온 전략이다.

https://docs.gitlab.com/ee/topics/gitlab_flow.html

Introduction to GitLab Flow | GitLab

github flow에 존재하는 main - feature 브랜치 뿐 아니라

배포용 productions 브랜치와 production 브랜치에 올리기 전 테스트를 하거나 시간을 두고 반영하는 pre-production 브랜치가 추가됐다.

 

뭔가 기능을 추가하고 싶다면

1. github-flow처럼 main 브랜치에서 feature브랜치를 만들고 수정한다.

2. 출시 준비가 되었다면 pre-production 브랜치에서 통합 테스트 및 배포 전 시간을 가진다.

3. pre-production 브랜치에서 production 브랜치로 merge 한 후 출시한다.

 

 

사실 정해진 정답은 없다.

본인 프로젝트의 구조와 크기, 협업하는 인원에 따라 더 좋은 전략은 프로젝트 중간에라도 바뀔 수 있다.