VHAL_

Git Branch란?

Git Branch는 Git에서 코드를 분기하여 관리하는 개념입니다.
Git에서는 기본적으로 master라는 하나의 브랜치를 가지고 있으며, 이 master 브랜치에서 새로운 브랜치를 만들어 작업을 진행합니다. 

☁️ Git Branch 전략이란

Git 브랜치 전략은 여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 활용하기 위한 work-flow
입니다. 개발 프로젝트를 효율적으로 관리하고, 코드 품질을 유지하며, 협업을 원활하게 하기 위해 브랜치를 사용하는 체계적인 방법이며 프로젝트의 규모와 팀의 협업 방식에 따라 다양한 전략을 사용할 수 있습니다.

git branch 전략이 중요한 이유는?

만일 브랜치 전략이 없는 팀이라면, 어떤 상황이 발생할까요?

저는 깃을 잘 모르고, 무작정 깃허브를 활용하여 협업 팀 프로젝트를 진행하였을 때 많은 문제점을 경험했었습니다 ..

어떤 브랜치가 최신 브랜치인지 알기 어려웠고, 팀원 사이에 소통이 부족했을 때 어디에 push를 해야 하고 어떤 브랜치를 끌어와야 하는지 혼란스러웠습니다. 또, 버그 수정을 할 때 어떤 브랜치를 기준으로 수정해야 할지 알기 어려웠습니다.

이러한 문제점들을 다 겪으니 브랜치 전략 도입의 중요성을 꺠달을 수 있었습니다 ..

장점은 각 전략마다 조금씩 차이가 있으며, 이 외에도 다양하지만 일부 요약하여 작성하였습니다.

• 동시 작업이 편하다
  • 여러 사람이 독립적으로 작업하고, 커밋을 할 때, 자신의 브랜치에서 변경 사항을 커밋하게 됩니다.
  • 브랜치가 병합될 때만 충돌을 해결하면 되니, 아무 규칙이 없는 것보다 충돌 시점이 명확해지기에 생산성을 높일 수 있습니다.
• 목적이 명확한 브랜치
  • 애플리케이션의 상태에 몇 가지가 있는데, 안정된 프로덕션, 테스트 환경, 기능 추가 환경... 등이 있습니다. 여러 기능별 브랜치(안정된 버전의 코드만이 관리되는 브랜치, 테스트 환경을 위한 브랜치, 기능 추가를 위한 브랜치)를 네이밍을 통해 구분하면 각각의 브랜치에 대해서 추가적인 설명을 할 필요 없이 명확하게 관리할 수 있습니다.
• 배포 파이프라인 관리가 편함
  • 브랜치가 네이밍으로 명확하게 구분이 되어있다면, 조건을 설정하기 쉽습니다.
  • 특정 타입의 브랜치에 push 되었을 때, pull request를 만들었을 때 같은 조건에 따른 스크립트를 만들어둔다면 CI/CD를 구축하기 쉽습니다.
• 버전 관리가 편리하다
  • 서버에 문제가 생겼을 때, 어떤 브랜치로 돌아가서 롤백을 해야 하는지에 대한 것들이 명확합니다.
  • 안정된 브랜치가 어떤 것인지 명확하기에, 롤백 과정에 대한 의사결정을 줄일 수 있습니다.

☁️ Git Branch 전략의 종류는?

그렇다면 브랜치 전략의 종류는 어떻게 될까요?

Git Flow, Github Flow, GitLab Flow 등 이 외에도 다양하지만 주로 널리 사용디는 Git Flow와 Github Flow를 기준으로 설명드리겠습니다.

Git Flow 전략

기본적인 브랜치 이름은 feature, develop, release, hotfix, master 5가지로 구분됩니다. 

master, develop 2가지 브랜치는 '항시 유지되는 메인 브랜치'이며 feature, release, hotfiix 3가지 브랜치는 'merge되면 사라지는 보조 브랜치'입니다.

 Git Flow 브랜치 구조

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

✔️ 메인 브랜치

메인 브랜치는 master 브랜치와 develop 브랜치 두 종류를 말한다.

master 브랜치는 배포 가능한 상태만을 관리하는 브랜치를 말하며,

develop브랜치는 다음에 배포할 것을 개발하는 브랜치이다.

즉 develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행합니다.

✔️ 보조 브랜치

보조 브랜치는 feature branch를 말한다

• 가지가 뻗어나오는 곳 : develop
• 뻗어나갔던 가지가 다시 합쳐지는 곳 : develop
• 이름 설정 : master, develop, release-*, hotfix-*를 제외하기만 하면 자유롭게 이름 설정이 가능하다.
• 새로운 기능을 추가할 때 주로 사용하는 가지이다.

master 브랜치에서 develop 브랜치를 만들었고,

develop 브랜치에서 다시 feature 브랜치를 나눠 작업을 하고 있는 것을 그림을 통해 알 수 있다. 

develop 브랜치에는 기존에 잘 작동하는 개발코드가 담겨있으며, 보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 한다. 즉, 보조 브랜치는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge 하고 결과가 좋지 못하면 버리는 방향을 취한다. 보조 브랜치는 보통 개발자 저장소에만 있는 브랜치고, origin에는 push하지 않는다.

✔️ 릴리즈 브랜치(release branch)

릴리즈 브랜치는 배포를 위한 최종적인 버그 수정 등의 개발을 수행하는 브랜치를 말한다.  

• 가지가 뻗어나오는 곳 : develop
• 뻗어나갔던 가지가 다시 합쳐지는 곳 : develop, master
• 이름 설정 : release-*
• 새로운 제품을 배포하고자 할 때 사용하는 가지이다.

develop 브랜치에 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성한다. 배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그(ex, v1.0, v0.2)를 추가한다. release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop 브랜치에도 적용해줘야 한다. 그러므로 배포 완료 후 develop 브랜치에 대해서도 merge 작업을 수행해야 한다. 

✔️ 핫픽스 브랜치(hotfix branch)

핫픽스 브랜치는 배포한 버전에서 긴급하게 수정할 필요가 있을 때 master 브랜치에서 분리하는 브랜치를 말한다.  

• 가지가 뻗어나오는 곳 : master
• 뻗어나갔던 가지가 다시 합쳐지는 곳 : develop, master
• 이름 설정 : hotfix-*
• 제품에서 버그가 발생했을 경우에는 처리를 위해 이 가지로 해당 정보들을 모아준다. 버그에 대한 수정이 완료된 후에는 develop, master에 곧장 반영해주며 tag를 통해 관련 정보를 기록해둔다.

버그를 잡는 사람이 일하는 동안에도 다른 사람들은 develop 브랜치에서 하던 일을 계속할 수 있다.

이 때 만든 hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge 하여 문제가 되는 부분을 처리해줘야 한다.

release 가지가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다. Hotfix는 보통 다급하게 버그를 고치기 위해 생성되는 가지이기 때문에 버그를 해결하면 보통 제거하는 일회성 가지다.

Git flow 흐름

• 앞에서 적었던 기본 구조 5개 중 가장 많이 사용되는 가지는 master와 develop가 되며 정상적인 프로젝트를 진행하기 위해서는 둘 모두를 운용해야 한다.
• 나머지 feature, release, hotfix branch는 사용하지 않는다면 지우더라도 오류가 발생하지 않기 때문에 깔끔한 프로젝트 진행을 원한다면 지워뒀다가 해당 가지를 활용해야 할 상황이 왔을 때 만들어줘도 괜찮다.
• 대부분의 작업은 develop에서 취합한다 생각하면 되며 테스트를 통해 정말 확실하게 더 이상 변동사항이 없다 싶을 때 master로의 병합을 진행하게 된다.
• master가 아닌 가지들은 master의 변동사항을 꾸준히 주시해야 한다.

1. 신규 기능 개발

1. 개발자는 develop 브랜치로부터 본인이 신규 개발할 기능을 위한 feature 브랜치를 생성한다. 
2. feature 브랜치에서 기능을 완성하면 develop 브랜치에 merge를 진행하게 된다.

2. 라이브 서버로 배포

1. feature 브랜치들이 모두 develop 브랜치에 merge 되었다면 QA를 위해 release 브랜치를 생성한다. 
2. release 브랜치를 통해 오류가 확인된다면 release 브랜치 내에서 수정을 진행한다.
3. QA와 테스트를 모두 통과했다면, 배포를 위해 release 브랜치를 master 브랜치 쪽으로 merge하며,
4. 만일 release 브랜치 내부에서 오류 수정이 진행되었을 경우 동기화를 위해 develop 브랜치 쪽에도 merge를 진행한다.

3. 배포 후 관리

1. 만일 배포된 라이브 서버(master)에서 버그가 발생된다면, hotfix 브랜치를 생성하여 버그 픽스를 진행한다.
2. 그리고 종료된 버그 픽스를 master와 develop 양 쪽에 merge하여 동기화 시킨다.

Github Flow 전략

GitHub Flow는 간단하고 직관적인 브랜치 전략으로, 빠르게 변화하는 프로젝트나 소규모 팀에서 주로 사용됩니다.

기본적으로 master 브랜치에 대한 규칙만 정확하게 정립되어 있다면 나머지 가지들에 대해서는 특별한 관여를 하지 않으며 PR(Pull Request)기능을 사용하도록 권장합니다.

GitHub-Flow 특징

• release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용하다.
• GitHub 자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용하다.
• 웹 서비스들에 배포의 개념이 없어지고 있는 추세이기 때문에 앞으로도 Git flow에 비해 사용하기에 더 수월할 것이다.
• hotfix와 가장 작은 기능을 구분하지 않는다. 모든 구분사항들도 결국 개발자가 전부 수정하는 일들 중 하나이기 때문이다. 이 대신 구분하는 것은 우선 순위가 어떤 것이 더 높은지에 대한 것이다.

Github-Flow 흐름

1. 브랜치 생성

Github-flow 전략은 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 시작된다.

단, 이때 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요하다.

• master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치다. 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
• 새로운 브랜치는 항상 master 브랜치에서 만든다
• Git-flow와는 다르게 feature 브랜치나 develop 브랜치가 존재하지 않는다.
• 그렇지만, 새로운 기능을 추가하거나 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 작성해주도록 하자

2. 개발 & 커밋 & 푸쉬

개발을 진행하면서 커밋을 남긴다.
이때도 브랜치와 같이 커밋 메세지에 의존해야 하기 때문에, 커밋 메세지를 최대한 상세하게 적어주는 것이 중요하다.

• 커밋메시지를 명확하게 작성하자
• 원격지 브랜치로 수시로 push 하자
• Git-flow와 상반되는 방식
• 항상 원격지에 자신이 하고 있는 일들을 올려 다른 사람들도 확인할 수 있도록 해준다
• 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다

3. PR(Pull Request) 생성

피드백이나 도움이 필요할 때, 그리고 merge 준비가 완료되었을 때는 pull request를 생성한다

• pull request는 코드 리뷰를 도와주는 시스템
• 이것을 이용해 자신의 코드를 공유하고, 리뷰받는다.
• merge 준비가 완료되었다면 master 브랜치로 반영을 요구한다.

4. 리뷰 & 토의

Pull-Request가 master 브랜치 쪽에 합쳐진다면 곧장 라이브 서버에 배포되는 것과 다름 없으므로, 상세한 리뷰와 토의가 이루어져야 한다.

5. 테스트

리뷰와 토의가 끝났다면 해당 내용을 라이브 서버(혹은 테스트 환경)에 배포해본다.

배포시 문제가 발생한다면 곧장 master 브랜치의 내용을 다시 배포하여 초기화 시킨다.

6. 최종 Merge

라이브 서버(혹은 테스트 환경)에 배포했음에도 문제가 발견되지 않았다면 그대로 master 브랜치에 푸시를 하고, 즉시 배포를 진행한다.

대부분의 Github-flow 에선 master 브랜치를 최신 브랜치라고 가정하기 때문에 배포 자동화 도구를 이용해서 Merge 즉시 배포를 시킨다.

master로 merge되고 push 되었을 때는, 즉시 배포되어야한다

• GitHub-flow의 핵심
• master로 merge가 일어나면 자동으로 배포가 되도록 설정해놓는다. (CI / CD)

☁️ Git Flow vs Github Flow 비교하기

결론적으로, 1개월 이상의 긴 호흡으로 개발하여 주기적으로 배포, QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 git-flow가 적합하다. 하지만 수시로 릴리즈 되어야 할 필요가 있는 서비스를 지속적으로 테스트하고 배포하는 팀이라면 github-flow와 같은 간단한 work-flow가 적합하다.

Git이란 무엇인가

Git은 분산 버전 관리 시스템으로, 파일의 변경 이력을 기록하고 협업을 가능하게 하는 도구입니다.

Git을 사용하면 코드와 파일의 변화를 시간순으로 기록하고, 이전 상태로 되돌리거나 여러 사람이 동시에 같은 프로젝트에서 작업할 수 있습니다.

☁️ 기본 개념

1. Repository와 Commit

• Repository(저장소)
  Git에서 파일의 변경 이력을 관리하는 공간으로, 프로젝트의 전체 상태와 이력을 저장합니다. 저장소는 로컬(Local) 저장소와 원격(Remote) 저장소로 나뉩니다.
  • 로컬 저장소: 사용자 컴퓨터에 저장된 Git 저장소.
  • 원격 저장소: GitHub, GitLab 같은 서버에 저장된 Git 저장소.
• Commit(커밋)
  변경된 파일의 상태를 기록한 스냅샷입니다. Git은 커밋 단위로 변경 사항을 추적하며, 각 커밋은 고유한 해시값을 가집니다.

2. Branch와 Merge

• Branch(브랜치)
  브랜치는 저장소의 독립적인 작업 공간으로, 프로젝트의 기본 흐름(main)에서 분기하여 새로운 작업을 할 수 있습니다.
• Merge(병합)
  브랜치에서 작업한 변경 사항을 다른 브랜치(main 등)와 통합하는 작업입니다.

3. Staging Area와 Working Directory

• Working Directory (작업 디렉터리): 현재 사용자가 작업 중인 파일들이 있는 공간입니다.
• Staging Area (스테이징 영역): 커밋 전에 변경 사항을 임시로 저장하는 공간으로, 커밋할 파일들을 준비하는 단계입니다.
• Repository (저장소): 커밋된 파일들이 영구적으로 저장되는 공간입니다.

☁️ File Status Lifecycle

Git에서 파일은 다음 4가지 상태 중 하나에 속합니다:

1. Untracked (추적되지 않음)
   • Git이 추적하지 않는 새로운 파일입니다.
   • git add 명령어로 파일을 스테이징 영역에 추가하면 Staged 상태로 전환됩니다.
2. Unmodified (변경되지 않음)
   • Git이 추적하고 있으며, 마지막 커밋 이후 변경되지 않은 파일입니다.
   • 이 상태의 파일은 커밋 내용과 동일하므로 아무 작업도 필요하지 않습니다.
3. Modified (수정됨)
   • Git이 추적 중인 파일이 변경되었지만, 아직 스테이징 영역에 추가되지 않은 상태입니다.
   • git add 명령어로 변경된 내용을 스테이징 영역에 추가할 수 있습니다.
4. Staged (스테이징됨)
   • 변경된 파일이 스테이징 영역에 추가되어 커밋 준비가 된 상태입니다.
   • git commit 명령어로 변경 사항을 저장소에 커밋할 수 있습니다.