프로젝트 규모가 작거나 혼자서 개발하는 경우 외에 규모가 커지거나 팀원이 늘어났을 경우 생기는 문제들을 효율적으로 관리할 수 있다.
Git-flow에는 5가지 종류의 브랜치가 있다.
master, develop :: 항상 유지되는 메인 브랜치들
feature, release, hotfix :: 일정 기간 동안만 유지되는 보조 브랜치들
⚪️ master : 제품으로 출시될 수 있는 브랜치
tag를 이용해서 버전을 기록한다.
X . 0 : 프로젝트 추가
1 . X : 기능 추가
⚪️ develop : 다음 출시 버전을 개발하는 브랜치
⚪️ feature : 단위 별로 기능을 개발하는 브랜치
develop 에서 갈라져 나온 브랜치로 작업이 완료되었다면, feature 브랜치는 develop 브랜치로 merge 됨.
git flow를 깔끔하게 보기 위해 origin develop의 갈라나온 시점을 잘 관리해 주어야 한다.
git pull --rebase origin devlop
을 이용해서 제일 마지막에 반영된 develop에서 branch가 갈라 나온 것 처럼 보이게 한다.
🔹 네이밍 규칙
어떤 이름도 가능하다. 단, master, develop, release-..., hotfix-... 같은 이름은 사용할 수 없다.
feature/기능요약 형식을 추천한다. ex) feature/login
feature/{issue-number}-{feature-name} 이슈추적을 사용한다면 이와 같은 형식을 따른다.
ex) feature/1-init-project, feature/2-build-gradle-script-write
⚪️ release : 이번 출시 버전을 준비하는 브랜치
⚪️ hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치
중앙 원격 저장소(remote repository)를 복제
> git clone[중앙 remote repository URL]
현재 디렉토리를 빈 Git 저장소로 만들기
> git init
현재 작업 중인 Git 저장소에 팀의 중앙 원격 저장소(origin)를 추가하기
> git remote add origin [중앙 remote repository URL]
중앙 원격 저장소(origin)의 master 브랜치 데이터를 로컬에 가져오기만 하는 작업
> git fetch origin master
👀 fetch와 pull의 차이
fetch : 원격 저장소의 데이터를 로컬에 가져오기만 하는 작업
pull : 원격 저장소의 데이터를 가져와 자동으로 병합까지 하는 작업
develop 브랜치 만들기
git branch develop
중앙 저장소로 push
git push -u origin develop
Github 페이지에서 Pull Request를 함.
(자신이 push한 develop branch를 병합해달라는 요청)
프로젝트 관리자는 해당 pull request를 merge 하고,
develop branch를 default branch로 설정함.
이제, 팀원들은 작업할 브랜치 만들어 작업하면 된다.
feature 브랜치는 기본적으로 기능명을 규칙으로 한다.
ex) login 기능을 추가할 브랜치면 '내가 만든 브랜치명' 을 feature/login 으로 하면 된다.
git branch [내가 만든 브랜치명] develop
git checkout [내가 만든 브랜치명]
위의 두 명령을 합하면
git checkout -b [내가 만든 브랜치명] develop
작업한 내용을 push
변경된 모든 파일을 스테이징 영역에 추가
> git add .
또는 특정 파일만 스테이징 영역에 추가하기
> git add [내가 수정한 파일명]
커밋하여 로컬 저장소에 변경된 사항들을 저장한다.
> git commit -m "적절한 커밋메세지 적으면 됨"
원격 저장소에 push 한다.
> git push origin [내가 만든 브랜치명] branch
깃헙에서 프로젝트 관리자에게 pull request를 보낸다.
이후, 프로젝트 관리자가 merge 한다.