Git Flow 브랜치 전략이란?

브랜치 전략 중의 하나로 많은 회사와 팀에서 기본으로 사용하는 경우가 많다.

브랜치 전략은 뭐지?

여러 작업자가 하나의 레파지토리를 사용하는 환경인 경우

레파지토리를 효과적으로 활용하기 위한 규칙을 부여하는 것.

분기, 병합, 생성 등등 각 브랜치에 같은 규칙을 팀원들이 지키면서 진행하는 것.

Git Flow 브랜치 전략의 특징

1. 용도에 맞게 브랜치를 분리한다.

main : 운영에 배포 될 수 있는 코드를 모아둔 브랜치

develop : 다음 버전의 코드를 모아둔 브랜치. 운영환경에 업뎃시 main으로 merge함

feature : 새로운 기능을 위한 브랜치로 develop 브랜치에서 생성 후 완료되면 develop으로 merge

release : 새로운 버전 배포를 위한 브랜치. develop 브랜치에서 생성한다. 배포 전 버그 수정을 위해 사용되며, 배포 준비가 완료되면 main,develop에 모두 merge한다.

hotfix : 빠르게 수정해야 하는 경우 main을 빠르게 변경해야 할 때 사용. main브랜치에서 생성하고, 버그 수정 후 main과 develop에 merge한다. 

1-1. 브랜치 생성 : main > develop > feature1, featue2, release 

1-2. 작업 후 머지 : feature > develop > release > main

2. 배포주기가 잦지 않은, 명확한 릴리즈 기간, 주기적인 버전이 있는 경우 적합

3. release브랜치를 따로 관리함으로 인해, 각 버전별을 동시에 관리 및 유지보수 하기에 편리함

4. 규모가 있는 팀 또는 롤백이나 다양한 버전을 필요호 하는 팀에서 유리

-> 보통 모바일 앱에서 적합하다고 하나, 서비스 운영을 통해 버그관리를 할 때도 사용. 

GitHub Flow는 뭐지?

git flow의 브랜치가 많다보니 자주 사용하지 않는 브랜치의 규칙을 학습해야 하기에

정말 필요한 경우가 아니라면 혼란을 가중시킬 수 있는데, 

이때 대안으로 사용하기 좋은 전략이다. 

1. main브랜치에만 엄격한 규칙이 적용되고, 그 외 브랜치는 규칙이 없음

main : 언제든 배포가 가능한 상태 유지. merge전 엄격한 테스트 필요

그외 브랜치 : main에서 생성하고 나머지 규칙은 없음. 단, 브랜치명, 커밋 메시지는 어떤 것을 담고 있는지 명확하게 작성. 작업 완료 후 main으로 PR작성. PR리뷰 완료 후 main으로 merge시 CI/CD를 거쳐 배포 진행

CI/CD 란? 자동화를 통합하는 앱 제공 방식으로 통합/지속적인 서비스(배포)를 뜻함.
CI : 지속적인 통합. 빌드/ 테스트를 자동화 과정
CD: 지속적인 서비스 제공. CI작업을 끝낸 뒤 실행. 지속적인 서비스(배포)

2. 잦은 배포가 필요할 때

3. 규칙이 간단해서 git에 익숙하지 않은 사람이 있을 때, 작은 프로젝트에 유리.

git merge <new branch>

Fast-forward merge

main과 새로운 브랜치의 형상이 동일한 경우.

main브랜치에서 새로 A라는 브랜치로 작업 후 commit을 하고,

main브랜치는 A브랜치를 분기한 곳에서 따로 commit을 한 게 없다면

merge를 할 때, A브랜치의 내용이 그대로 main브랜치로 흡수되며 추가 commit이 발생되지 않는다.

분기는 되었으나, main 브랜치가 변화가 없었기 때문에 분기점은 동일하기에,

추가로 작업한 신규 브랜치가 main이 되어도 문제가 없다.

Recursive Merge

main과 새로운 브랜치의 형상이 다른 경우

main브랜치와 새로운 브랜치가 각각 commit이 되어 있어 형상이 다를 때,

병합시에는 새로운 commit이 발생된다.

시간순서대로 두개의 브랜치가 합쳐지기 때문에 commit hash에 변함이 없다. 

Squash Merge

git merge --squash <new branch>

새로운 브랜치의 커밋들이 하나로 합쳐져서 병합이 된다.

이전 커밋 내용을 하나로 모아 병합이 되기 때문에

merge log가 깔끔한 장점이 있으나,

새로운 브랜치에서 커밋한 내용이 자세히 보기 힘든 점은 있다. 

Rebase Merge

# new
git rebase <new branch>
git checkout <main branch>
# main
git merge <new branch>

새로운 브랜치에서 commit한 게 main브랜치에 배치되고, 추가 커밋없이 병합이 된다.

이때, 두 브랜치 형상의 동일 여부에 따라 fast-forward 또는 recusive merge가 진행된다.

Git reset [옵션] 이전의 특정 커밋id

사용하면 해당 커밋으로 되돌리는 역할을 합니다.

리셋을 할 때에는 --soft --mixed --hard 세가지 옵션이 있는데요.

어떤 옵션을 선택하느냐에 따라 세가지의 작업영역.

working directory, staging area, repository 에

내가 현재까지 작업한 게 어디까지 남아있게 되는지가 달라지게 됩니다. 

우선 soft로 하게 되면, repository만 이전 커밋과 동일하게 바뀌기 때문에,

나머지 working directory, staging area에는

현재 작업이 그대로 남아있는 상태라고 보시면 됩니다.

mixed는 내 작업 공간인 working directory에만 현재 작업이 남아있고,

staging area와 repository는 이전 커밋과 동일하게 바뀝니다.

hard는 세 작업영역이 모두 이전 커밋과 동일하게 바뀝니다.

새로운 작업이 모두 제거 되기 때문에 커밋한 작업이 불필요할 때 외엔 권장되지 않습니다.

구글 애드센스를 붙여서 소확행을 노려보려고

승인 받은 뒤로 일단 다 설정해두었는데 너무 뜬다..

스킨도 바꾸고 설정에서 모두 해제를 눌러도 뜨는 건 왜일까.

반영하는 데 시간이 좀 걸리는건가..?

적당히 떴으면 좋겠는데 방문하는 분들 입장을 생각하니

참 민망해진다..😅