깃허브 브랜치 전략에 대해 알아보자

목차

 

이번 해커톤을 하면서 깃허브 건드리면서 알게 된 것을 정리하고자 한다.

 

깃허브 fork

fork는 다른 사람의 Github Repository에서 내가 어떤 부분을 수정하거나 추가 기능을 넣고 싶을 때 해당 repository를 내 Github Repository로 그대로 복제하는 기능이다. 

 

fork한 저장소는 원본(원래 Repository 주인)과 연결되어 있다. 여기서 연결되어 있다는 의미는 원래 레포지토리에 어떤 변화가 생기면(새로운 commit, push) 이는 그대로 fork된 repository로 반영할 수 있다. 이 때 fetch, pull의 과정이 필요하다
그 후 original repository에 변경 사항을 원본 레포지토리에 적용하고 싶으면 원본 저장소에 pull request를 보내야 한다.

 

즉 fork를 하면 일종의 안정장치 역할을 할 수 있다!!

develop 브랜치에서 개발을 하는 참사를 막을 수 있다.

 

이 녀석을 이번 프로젝트에서 하지 않고 진행했는데 fork를 하지 않으면 develop 브랜치에서

바로 개발을 해서 머지를 시켜버리는 참사가 났다.. 주의하자

 

GIT-FLOW 전략

가장 기본적인 가지의 이름은 다음과 같다.

• master : 라이브 서버에 제품으로 출시되는 브랜치.
• develop : 다음 출시 버전을 대비하여 개발하는 브랜치.
• feature : 추가 기능 개발 브랜치. develop 브랜치에 들어간다.
• release : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다.
• hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치.

 

소규모 개발에서는 develop과 master 그리고 feature만 잘 알고 있으면 된다.

develop 브랜치에서 통합이 이루어지고 파생되어 개발이 된다는 것을 꼭 기억하자

 

 

아래 방법은 문제가 있으니 글 마저 봐주세요!

간혹 개발 중에 풀을 받아와야 하는 경우가 생긴다.

이렇게 되면 내가 개발하던 브랜치는 최신 develop 브랜치에서 파생이 된 브랜치가 아니게 된다.

 

이럴때는 develop 브랜치에서 다시 브랜치를 판후 내가 개발하던 브랜치를 통합시켜 주면 된다.

develop 브랜치로 이동해서 브랜치를 하나 파자

$git branch feat/petitionComplete

 

그 후 통합시킬 기존 개발 브랜치를 입력하자

git merge feat/petition

그러면 다음과 같이 feat/petitionComplete 브랜치가 develop 브랜치 기반으로 최신 브랜치가 된 것을 볼 수 있다.

 

 

추후 정정 (중요!)

머지와 관련된 흔한 오해

머지 과정에서 많은 사람들이 혼동하는 점이 있는데, 내 브랜치를 기준 브랜치에 반영하려면, 이는 머지가 아니라 풀리퀘스트(PR) 또는 기준 브랜치로의 병합 작업을 해야 합니다.
즉, 작업 방향성이 아래와 같이 달라집니다:

• 머지: 기준 브랜치 → 작업 브랜치
• PR/병합: 작업 브랜치 → 기준 브랜치

머지를 한다고 해서 원격 저장소에 반영이 되는 것이 아니기 때문에 그냥 개발한 것에 합쳐도 그대로 남아있다.

따라서 위에서 처럼 하는게 아니라 pull한 이후 기존의 브랜치에서 바로 머지하면 된다. 

이렇게 해야 기존 브랜치의 히스토리를 유지하면서 pr을 다시 줄 수 있다.

 

 

 

 

squash-merge

Squash는 여러 개의 커밋을 하나의 커밋으로 합치는 것을 의미한다. (a, b, c를 합쳐서 새로운 커밋으로 만들고, Merge 대상 브랜치에 추가, 'a, b, c' 커밋은 parent를 Init 하나만 가짐)
Squash Merge는 병합할 브랜치의 모든 커밋을 하나의 커밋으로 Squash한 새로운 커밋을 Base 브랜치에 추가하는 방식으로 병합하는 것을 의미한다.

 

아래와 같이 pull-request할 때 옵션으로 선택할 수 있다.