프로젝트 협업 시 각각의 개발자는 원격저장소에 저장된 프로젝트 파일을 개인이 사용하는 로컬저장소에 받아 작업한다.
새로운 작업내용이 있을 때 원격저장소의 소스코드에 작업내용을 추가하고 다시 로컬저장소에서 작업한다.
git은 위의 과정에서 프로젝트의 버전을 관리하기 위한 프로그램으로 명령어로 쉽게 사용할 수 있다.
git과 함께 사용되는 github은 프로젝트의 전체 소스코드를 저장할 수 있는 원격저장소를 제공하고
기존의 소스코드나 새로 추가할 내용을 좀 더 가시적으로 제공하는 웹서비스이다.
처음 git과 github를 접했을 때는 레포지토리를 생성하고, 로컬저장소와 연결해 변경사항이 있을 때 add, commit, push만을 사용해 프로젝트를 관리했다.
하지만 협업을 하고 프로젝트가 복잡해질수록 버전관리 또한 중요한 부분이 되었고, 이런 문제를 해결할 수 있는 방법을 찾게 되었다.
그 과정에서 몇가지 명령어를 새로 익히게 되었고, git-flow에 대해서도 공부할 수 있었다.
Git-flow
버전관리 중 발생할 수 있는 문제를 최소화하기 위한 전략으로 브랜치를 기반으로 한 버전관리 방식
git-flow 방식에서는 브랜치를 개발 단계에 따라 5종류로 나누어, 각 단계에 맞는 브랜치를 사용한다.
메인 브랜치
메인 브랜치는 항상 유지하는 브랜치로 보조 브랜치의 결과를 반영하는 브랜치이다.
- master: 실제 서비스를 배포하기 위한 브랜치
- develop: 개발 과정에서 메인이 되는 브랜치
보조 브랜치
실제 기능의 개발, 수정은 보조 브랜치에서 이루어지며, 필요에 따라 생성하거나 폐기하는 브랜치이다.
- feature: 새로운 기능을 개발할 때 사용하는 브랜치로 develop 브랜치에서부터 생성해 작업한다.
- release: 배포하기 위해 develop에서 master로 넘어가기 전 확인되는 오류 또는 수정 사항을 반영하는 브랜치이다. 변경 사항은 master, develop 양 쪽에 반영한다.
- hotfix: master에서 확인되는 오류 또는 수정 사항을 반영하는 브랜치로 release와 마찬가지로 변경 사항은 master, develop 양 쪽에 반영한다.
결국 개발용 메인 브랜치와 배포용 메인 브랜치가 있고 실제 작업은 따로 브랜치를 만들어 결과만 메인 브랜치에 반영하는 구조
git-flow를 공부하다 보니 개발 자체도 중요하지만 리액트 폴더구조나 네이밍 컨벤션, ESLint, Prettier 등 여러 사람이 함께 작업할 때 발생할 수 있는 차이를 방지하기 위한 개념이 많은 것 같다.
git 브랜치 관련 명령어
- 브랜치 생성
- 기능을 개발하거나 수정 사항이 있을 때 메인브랜치에서 새로 브랜치를 만들어 작업
- git checkout -b 브랜치이름: 브랜치를 생성하고 바로 해당 브랜치로 이동하는 명령어이다.
- pull request 진행
- 브랜치에서 작업을 완료한 후 메인브랜치로 반영하기 위한 과정
- add, commit, push를 차례대로 거치면 github에서 새로운 pull request가 생긴다.
- 관리자가 요청을 확인하고 merge까지 완료한 후 해당 브랜치는 삭제
- 로컬 저장소에 수정사항 반영
- git pull: 내 로컬 저장소의 메인 브랜치에도 최신 내용을 반영
- git branch -d 브랜치이름: 로컬 저장소에는 기능 개발에 사용한 브랜치가 남아 있기 때문에 삭제
- 실수로 메인브랜치에 변경된 코드를 commit 했을 때
- git reset: commit한 내용을 취소한다. 취소할 때는 이 방법을 사용한다.
- git revert: commit 내용은 남기고, 이전 사항으로 돌아가며 새로운 commit이 생성
참고
https://techblog.woowahan.com/2553/
https://devlog-h.tistory.com/6
