0. 들어가기 앞서서 용어 정리

용어	설명	이번 발표 사용
저장소 (repository)	프로젝트 파일과 해당 파일의 변경 이력이 저장되는 곳이다. 로컬 저장소, 원격 저장소 두 종류가 있다.	✅
커밋 (commit)	파일 또는 디렉토리의 변경 사항을 로컬 저장소에 기록한다. 커밋은 변경 내용, 작성자, 날짜 같은 정보와 함께 고유한 ID를 가진다. ID를 통해 특정 시점의 프로젝트 상태로 돌아갈 수 있다.	✅
브랜치 (Branch)	작업을 분리하기 위한 수단이다. 주로 “master” 또는 “main” 브랜치가 주 브랜치로 사용된다. 기능 추가, 버그 수정 등을 위해서 새로운 브랜치를 생성하여 작업한다.	✅
병합 (Merge)	두 브랜치의 변경 사항을 하나로 합치는 과정이다.	✅
충돌 (Conflict)	두 브랜치를 병합할 때 같은 파일의 같은 부분이 다르게 수정되어 Git이 병합할 수 없는 상황이다	❌
풀 (Pull)	원격 저장소의 변경 사항을 로컬 저장소로 가져오고 자동으로 현재 브랜치와 병합하는 과정이다.	✅
푸시 (Push)	로컬 저장소의 변경 사항을 원격 저장소로 업로드하는 과정이다.	✅
패치 (Fetch)	원격 저장소의 최신 history를 로컬 저장소로 가져오지만, 현재 작업 중인 브랜치와는 병합하지 않는다.	❌
스태이징 (Staging)	커밋 전 변경 사항을 준비하는 단계이다.	❌
태그 (Tag)	특정 커밋을 참조하기 위한 레이블이다.	❌
체크아웃 (Checkout)	다른 브랜치로 전환하거나 특정 버전의 파일을 작업 디렉토리로 가져오는 과정이다.	✅
클론 (clone)	원격 저장소의 복사본을 로컬 저장소에 생성한다.	❌
포크 (Fork)	다른 사용자의 원격 저장소를 자신의 원격 저장소로 복사하는 과정이다.	❌
풀 리퀘스트 (Pull Request)	PR은 하나의 브랜치에서 다른 브랜치로 변경사항을 병합하기 위한 요청이다.	✅

1. git branch 전략

---

여러 개발자가 하나의 저장소에서 작업을 할 때 협업을 좀 더 효과적으로 하기 위해

git branch 에 대한 규칙을 정하고 저장소를 잘 활용하기 위한 workflow 를 정의하는 것을 바로 git branch 전략이라고 합니다.

❓ 이러한 Git Branch 전략은 왜 필요한가

여러 명의 개발자가 동시에 작업할 때 가장 빛을 발하는데요, 각자 다른 기능을 담당하는 브랜치를 사용하여 작업하면,

개발 중인 기능이나 수정사항이 서로 독립적이게 되며 영향을 주지 않고 동시에 진행될 수 있습니다.

또한, 각각의 브랜치가 특정 기능, 이슈에 대응하여 특정 작업을 추적하고, 필요한 경우 작업 단위의 Rollback 이 가능하여 프로젝트 관리의 유연성을 향상시켜줍니다.

각각의 태그는 Release 를 원하는 버전 단위로 관리할 수 있도록 하여, 배포 안정성을 향상시켜줍니다.

❓브랜치 전략이 없으면 어떤 일이 발생하는가

• 어떤 브랜치가 최신 브랜치지?
• 어떤 브랜치를 끌어와서 개발을 시작해야 하지?
• 어디에 Push를 보내야 하지?
• 핫픽스를 해야하는데 어떤 브랜치를 기준으로 수정해야할까?
• 배포 버전은 어떤 걸 골라야하지?

Git Branch 전략은 여러가지가 있지만, 대표적으로 여러 프로젝트에서 널리 사용되고 있는 두가지 대표 브랜치 전략인 Git Flow 와 GitHub Flow 에 대해서 알아보도록 하겠습니다.

1.1 Git Flow

---

가장 전통적으로 많이 사용되는 방식이다.

• 기본적인 가지의 이름은 아래의 5가지로 구분하곤 한다.
• feature > develop > release > hotfix > master
• 위 순서들은 왼쪽으로 갈수록 포괄적인 가지이며 master branch를 병합할 경우 그 왼쪽에 있는 hotfix 등 모든 가지들에 있는 커밋들도 병합하도록 구성하게 된다.
• 5가지 중, 항시 유지되는 메인 브랜치 master, develop 2가지와 merge 되면 사라지는 보조 브랜치 feature, release, hotfix 3가지로 구성된다.

1.1.1 브랜치 별 설명

1.1.1.1 메인 브랜치(master, develop)

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

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

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

1.1.1.2 보조 브랜치

보조 브랜치는 피처 브랜치(feature branch) 또는 토픽 브랜치(topic branch)를 말한다.

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

develop 브랜치에는 기존에 잘 작동하는 개발코드가 담겨있으며, 

보조 브랜치는 새로 변경될 개발코드를 분리하고 각각 보존하는 역할을 한다.

즉, 보조 브랜치는 기능을 다 완성할 때까지 유지하고, 다 완성되면 develop 브랜치로 merge 하고 결과가 좋지 못하면 버리는 방향을 취한다.

1.1.1.3 릴리즈 브랜치(release branch)

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

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

develop 브랜치에 버전에 포함되는 기능이 merge 되었다면 QA를 위해 develop 브랜치에서부터 release 브랜치를 생성한다. 

배포 가능한 상태가 되면 master 브랜치로 병합시키고, 출시된 master 브랜치에 버전 태그(ex, v1.0, v0.2)를 추가한다.

release 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop 브랜치에도 적용해줘야 한다.
그러므로 배포 완료 후 develop 브랜치에 대해서도 merge 작업을 수행해야 한다.

1.1.1.4 핫픽스 브랜치(hotfix branch)

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

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

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

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

release 가지가 생성되어 관리되고 있는 상태라면 해당 가지에 hotfix정보를 병합시켜 다음번 배포 시 반영이 정상적으로 이루어질 수 있도록 해준다.

Hotfix는 보통 다급하게 버그를 고치기 위해 생성되는 가지이기 때문에 버그를 해결하면 보통 제거하는 일회성 가지다.

1.1.2 Git Flow 정리

---

1.1.2.1 신규 기능 개발

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

1.1.2.2 라이브 서버로 배포

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

1.1.2.3 배포 후 관리

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

1.2 GitHub Flow

---

release branch가 명확하게 구분되지 않은 시스템에서의 사용이 유용하다.

GitHub 자체의 서비스 특성상 배포의 개념이 없는 시스템으로 되어있기 때문에 이 flow가 유용하다.

웹 서비스들에 배포의 개념이 없어지고 있는 추세이기 때문에 앞으로도 Git flow에 비해 사용하기에 더 수월할 것이다.

hotfix와 가장 작은 기능을 구분하지 않는다. 모든 구분사항들도 결국 개발자가 전부 수정하는 일들 중 하나이기 때문이다. 이 대신 구분하는 것은 우선 순위가 어떤 것이 더 높은지에 대한 것이다.

1.2.1 흐름

---

1.2.1.1 브랜치 생성

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

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

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

1.2.1.2 개발, 커밋, 푸쉬

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

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

1.2.1.3 PR 생성

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

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

1.2.1.4 리뷰, 토의

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

1.2.1.5 테스트

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

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

1.2.1.6 최종 Merge

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

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

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

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

1.3 ❗ Git Flow 와 GitHub Flow 중 어떤 전략을 사용해야 할까?

Git Flow 와 GitHub Flow 중 어떤 전략을 사용하는게 좋을까요? 다양한 관점에서 두 전략을 비교해보겠습니다.

1. 브랜치 수: Git Flow는 다양한 종류의 브랜치를 사용하는 반면, GitHub Flow는 단일 브랜치 (master) 를 사용합니다.

2. 배포 방식: Git Flow는 release 와 hotfix 브랜치를 통해 명확한 배포 절차를 갖추고 있습니다.

   반면에, GitHub Flow는 단순하며 지속적인 배포를 강조하며, master 브랜치에서 배포를 수행합니다.

3. 복잡성: Git Flow는 복잡한 프로젝트나 대규모 팀에서 사용하기 좋습니다.

   그러나 이는 작은 팀이나 개인 프로젝트에 적용하기에는 많은 브랜치와 과정이 불필요하고 부담스러울 수 있습니다.

   GitHub Flow 는 단순하며 빠른 개발 및 배포를 위해 사용됩니다.

각각의 전략은 장, 단점이 존재하기에 프로젝트의 규모, 요구 사항 및 팀의 작업 방식에 맞추어 적절하게 채택하는 것이 좋습니다.

Git Flow는 더 많은 제어와 복잡성을 가지고 있어 특정 기능이나 수정을 빠르게 배포해야 할 경우 등에서 유연성이 다소 떨어집니다.

그러나 그만큼 배포 안정성과 버전 관리 및 롤백 등 체계적인 운영이 가능합니다.

GitHub Flow 는 테스트와 검증 절차를 거치지 않고 바로 master 브랜치로 Merge 되므로 위험성을 가지고 있습니다.

하지만 그만큼 단순하고 빠르게 기능을 테스트하고 Agile 하게 배포할 수 있기 때문에, 주로 각 환경의 구분이 명확하지 않고 작은 규모의 프로젝트에 적합한 전략입니다.

💡 참고 자료

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

[GitHub] 기본 용어 정리

[GIT] 📈 깃 브랜치 전략 정리 - Github Flow / Git Flow

Git Branch 전략 비교 - Git Flow vs GitHub Flow

Git branch 전략(Git-Flow, Github-Flow, Gitlab-Flow)