Git flow
기본적으로 Git은 로컬 저장소와 원격 저장소간의 동기화를 위해 master 하나에 git add, commit 을 통해 협업 한다. 그러나 프로젝트의 규모가 커지고 협업하는 동료들이 많아진다면 이슈에 따라 다양한 branch를 통해 다양한 인원이 독립적으로 개발이 가능한 전략이 필요하다.
git-flow 전략은 소프트웨어의 소스코드를 관리하고 출시하기 위한 '브랜칭 관리 전략branch management strategy’이다. 꽤 오래전에 나온 전략이며 이 전략의 단점을 극복하기 위해 github flow와 gitlab flow 전략이 나왔다.
Git flow 는 프로젝트 규모가 커지고 협업하는 동료들이 많아짐에 따라 효율적으로 프로젝트를 관리하고 배포하기 위한 전략이다. 이슈에 따라 다양한 branch를 통해 독립적으로 개발이 가능하고, 관리하여 통합하기 용이하다.
Git Flow의 주요 브랜치는 master와 develop 이며, 이 두 브랜치를 중심으로 feature, release와 필요에 따라 hotfixes 브랜치를 정의한다.
master
master 브랜치에 merge된 내역은 새로운 버전이 갱신되었다는 것을 의미한다. 즉 master 브랜치에 변경 내역이 생기면 최종 버전인 Tag를 통해 Production에 배포된다.
develop
hotfix를 제외한 모든 변경내역이 출발하는 지점이다. develop 브랜치의 코드가 안정화되고 배포할 준비가 되면 master를 통해 배포 버전의 태그를 단다.
feature
feature 브랜치는 배포하려고 하는 기능을 개발하는 브랜치다. 기능을 개발하기 시작할 때는 언제 배포할 수 있을지 알 수 없다. 기능을 다 완성할 때까지 유지하고 있다가 다 완성되면 develop 브랜치로 병합한다.
release
release 브랜치는 실제 배포할 상태가 된 경우에 생성하는 브랜치다.
hotfix
미리 계획되지 않은 브랜치다. 기본적인 동작방식은 release와 비슷하다. 배포 이후에 생긴 치명적인 버그는 즉시 해결해야하기 때문에 문제가 생기면 master 브랜치에 만들어둔 태그tag로 부터 긴급수정을 위한 브랜치를 생성한다.
Git fork
git fork vs git clone
git fork는 git 에서 내 레파지토리로 복사 해서 클론하는 것을 말한다. 외부 다른 프로젝트를 내 레파지토리에 그대로 갖고 오는 것이기 때문에 커밋하고 푸쉬하여도 내 레파지토리에서 먼저 머지를 하고 진짜 리모트에 pr 를 할 수 있다.
git fork 시 기억해야 할 점
- fork 받은 레파지토리는 내 remote 레파지토리이다. 작업을 하려면 보통 하는 것처럼 내 디렉토리로 clone 할 것.
- remote 를 따로 지정해 주어야 한다.
fork를 받아온 original remote 주소를 등록하여 원본이 업데이트되면 내가 fork 받은 레파지토리도 같이 업데이트가 될 수 있도록 연결해주는 과정이다.
git remote add upstream 주소
원본 레파지토리가 업데이트 된 것을 받아오는 과정
git fetch upstream master
내 디렉토리에서 fork받은 내 레파지토리로 push
git push origin branch이름
fork받은 내 레파지토리에서 원본 레파지토리로 push
git push upstream master
위에 remote add 를 upstream 이라는 이름으로 등록해 주었기때문에 아래와 같이 origin 과 upstream 의 주소가 나오고 내가 작업한 것을 각각 push 하여 작업할 수 있다.
Git fetch
git fetch vs git pull
원격저장소로부터 파일을 갖고 오는 것은 같다.
하지만, pull 은 갖고 와서 바로 내 로컬 마스터에 병합이 되고,
fetch는 마스터에 병합은 되지 않는다. 후에 rebase or merge를 통해 병합해 주어야 한다.
