서버 호스팅 강의 02 - Git과 Git 브랜치 전략

 

서버를 세팅하기 전에, 여러 사람이 모여 소스코드를 통합하기 위해 사용하는 Git에 대해 알아보겠습니다.

이렇게 개발되고 통합되는 소스코드를 기반으로 웹 서버에서 프로그램이 작동합니다.

 

 

다른 SCM과 차별화되는 Git 기능은 분기 모델입니다.

•원활한 컨텍스트 전환 . 아이디어를 시도하기 위해 브랜치를 만들고, 몇 번 커밋하고, 브랜치했던 곳으로 다시 전환하고, 패치를 적용하고, 실험 중인 곳으로 다시 전환하고, 병합합니다.

•역할 기반 코드라인 . 항상 프로덕션에 사용되는 항목만 포함하는 브랜치, 테스트를 위해 작업을 병합하는 또 다른 브랜치, 일상적인 작업을 위한 여러 개의 작은 브랜치가 있습니다.

•기능 기반 작업 흐름 . 작업 중인 새 기능마다 새 브랜치를 생성하여 기능 간에 원활하게 전환할 수 있도록 한 다음, 해당 기능이 메인 라인에 병합되면 각 브랜치를 삭제하세요.

•일회용 실험 . 실험할 브랜치를 만들고 그것이 작동하지 않을 것임을 깨닫고 삭제하면 됩니다. 즉, 다른 사람이 볼 수 없는 작업을 포기합니다(그동안 다른 브랜치를 푸시한 경우에도 마찬가지입니다).

 

특히, 원격 저장소에 푸시할 때 모든 브랜치를 푸시할 필요는 없습니다. 브랜치 중 하나만 공유하거나 몇 개 또는 모두 공유하도록 선택할 수 있습니다. 이는 사람들이 아이디어를 병합하거나 다른 사람과 공유할 방법과 시기를 계획할 필요 없이 새로운 아이디어를 자유롭게 시도할 수 있는 경향이 있습니다.

 

이와 같은 브랜치 특성을 어떻게 사용하는지에 따라 브랜치 전략이 달라집니다.

 

 

Git은 빠릅니다 . Git을 사용하면 거의 모든 작업이 로컬에서 수행되므로 어딘가에 있는 서버와 지속적으로 통신해야 하는 중앙 집중식 시스템에서 속도가 크게 향상됩니다. 커밋, 차이점, 로그, 업데이트 부분은 다른 형상 관리 도구인 SVN보다 1~2배 더 빠릅니다. Git이 느린 곳 중 하나는 초기 복제 작업입니다. Git은 최신 버전만이 아닌 전체 기록을 다운로드하기 때문입니다. 

 

Git을 포함한 모든 분산 SCM의 가장 뛰어난 기능 중 하나는 분산된다는 점입니다. 이는 소스 코드의 현재 팁을 "체크아웃"하는 대신 전체 저장소를 "복제"한다는 의미입니다. 모든 사용자는 기본적으로 기본 서버의 전체 백업을 갖게 됩니다. 이러한 각 복사본은 충돌이나 손상이 발생할 경우 주 서버를 교체하기 위해 푸시될 수 있습니다. 

 

Git이 사용하는 데이터 모델은 프로젝트의 모든 부분에 대한 암호화 무결성을 보장합니다. Git에 Commit하면 생기는 커밋 ID가 다름을 의미하는 것 같습니다.

 

대기장소는 스테이징 에어리어라고 부릅니다. 다른 시스템과 달리 Git에는 "스테이징 영역" 또는 "인덱스"라는 것이 있습니다. 이는 커밋을 완료하기 전에 커밋의 형식을 지정하고 검토할 수 있는 중간 영역입니다. Git이 다른 도구와 다른 점 중 하나는 작업 디렉터리에 있는 다른 수정된 파일을 모두가 아닌 일부 파일을 빠르게 스테이징하고 커밋할 수 있다는 것입니다.

 

Git은 오픈 소스 라이센스 인 GNU General Public License 버전 2.0 에 따라 출시됩니다 . Git 프로젝트는 무료 소프트웨어를 공유하고 변경할 수 있는 자유를 보장하기 위해 GPLv2를 사용하기로 결정했습니다. 즉, 소프트웨어가 모든 사용자에게 무료인지 확인하는 것입니다. 이 허가를 가진 프로그램을 사용하여 새로운 프로그램을 만들게 되면 파생된 프로그램 역시 같은 카피레프트를 가져야 한다.

 

 

한 사람 또는 여러 사람이 개발을 한다고 가정해볼게요.

가운데 열처럼 개발하는 사이트의 특성에 따라 여러 기능들이 있을 거에요.

각가 무엇을 개발할지에 따라 역할을 나누고, 기능 별로 브랜치를 나눠 개발을 시작하겠죠.

이렇게 개발하면 브랜치 별로 구현이 구분되기에, 특정 브랜치의 commit 기록을 통해 개발 과정을 확인할 수 있습니다.

 

잠시 소스코드를 작성하고 add, commit, push 하는 것이 무엇인지 살펴보겠습니다.

 

 

Git을 사용한다면, 위 그림을 이해하고 있어야 합니다.

먼저 로컬 영역과 리모트 영역. 로컬은 개발자 각각의 PC를 의미하고,

리모트는 git 서버에서 하나로 통합되고 관리되는 저장소를 의미합니다.

 

로컬 영역은 Working directory, Staging Area, .git directory로 구분됩니다.

먼저 Remote 영역에서 git clone 명령어로 내 PC에 원격 저장소의 소스코드를 가져옵니다.

그 후에 브랜치를 분기하고, 개발을 시작합니다. 그러면 가져온 코드에 새로운 코드를 추가하게 되겠죠.

 

그렇게 변경사항이 생깁니다. 소스코드를 개발하는 것은 Working directory에서 이뤄집니다.

이 코드를 git add 명령어를 통해 Staging Area로 임시 저장합니다.

이때 git add 주의사항은 점( . ) 을 찍으면 현재 위치를 포함한 하위 소스코드의 모든 변경사항이

Staging Area로 올라가므로 임시 저장할 파일만 골라서 적절 디렉토리 또는 확장자를 이용해 add 합니다.

 

Staging Area에서 변경 사항이 잘 올라갔는지 확인합니다.

git diff 또는 git status 명령어를 사용하여 확인할 수 있습니다.

확인이 되었으면 커밋 메시지와 함께 commit을 하고, 원격 저장소로 push합니다.

여기서 주의할 점은 pull을 제때 받지 않아서 push할 브랜치와

내 로컬 브랜치의 상태가 달라 충돌이 일어나는 경우가 있습니다.

 

Push된 소스코드는 원격 저장소에 브랜치와 함께 새로 업데이트 됩니다.

그 후 원격 저장소에서는 소스코드들을 합치기 위해 상위 브랜치로 merge 합니다.

원격 저장소는 merge 하기 전에, 이 소스코드가 상위의 소스코드와 충돌 나는지 확인해줍니다.

 

이렇게 소스코드를 병합하고, 충돌을 방지하며 형상 관리가 진행됩니다.

 

 

소스코드를 개발하고, 원격 저장소에 push 했습니다.

원격 저장소에서는 여러 코드들을 관리하며 통합을 시작합니다.

이때 git의 브랜치 특성에 따라 여러 git 브랜치 전략을 세워 소스코드를 통합하고 배포할 수 있습니다.

 

여러 브랜치를 활용하는 방법인 Git 브랜치 전략의 필요성은, 만약 하나의 브랜치에서만 개발을 진행한다면

내가 작업 중인 파일을 누군가 건드릴 수 있고, 커밋 히스토리가 뒤죽박죽 섞이게 될 것입니다.

브랜치를 나눠 진행하면 여러 기능을 여러 사람이 병렬적으로 개발할 수 있습니다.

 

그럼 대표적인 git 브랜치 전략에 대해 알아보겠습니다.

 

 

대표적인 git 브랜치 전략에 공통적으로 등장하는 세가지가 있습니다.

분기, 개발, 병합입니다. 이것들이 어떻게 사용되는지 보시면 좋을 것 같습니다.

 

그리고 master 브랜치가 어떤 용도로 사용되는지, 나머지 브랜치들의 용도는 무엇인지,

하나로 유지되는 브랜치는 무엇이고, 여러 개로 나누고 삭제하는 브랜치는 무엇인지

이 사항들도 확인하면 쉽게 이해하실 수 있습니다.

 

 

Git flow는 master, develop, feature, release, hotfix 총 5종류의 브랜치를 사용합니다.

Master 브랜치는 제품 출시와 관련된 브랜치 이기에 하나로 유지됩니다.

Develop 브랜치는 추가 기능을 통합하는 브랜치라서 하나로 유지됩니다.

Feature 브랜치는 기능마다 생성하고, 개발이 끝나면 삭제합니다.

Release 브랜치는 develop에서 master로 넘어가기 전에 테스트를 진행해봅니다.

Hotfix 브랜치는 release에서 예방하지 못해 maste에서 발생한 버그를 빠르게 수정합니다.

 

이 브랜치 전략은 주기적으로 배포하는 서비스에 적합하고, 버전 관리가 필요한 서비스에 적합합니다

 

 

그러나 웹 어플리케이션에서는 Git flow 사용이 과하다는 의견이 있습니다. 바로 git flow를 만든 사람의 주장입니다.

버전관리나 public API에는 적합하지만, 웹 어플리케이션은 단일 버전만을 이용하므로 필요가 없다는 의견입니다.

차라리 조금더 간단한 github flow가 어울린다고 합니다.

 

대표적인 git 브랜치 전략 3가지는 git flow, github flow, gitlab flow인데, 나머지도 이어서 보겠습니다.

 

 

Github flow는 master 하나를 두는 방식입니다. 그 외에는 개발자 재량에 맡긴다고 합니다.

별도의 브랜치에서 기능 개발을 하고, push한 다음에, 코드를 검토하고 승인하면

master에 반영하여 바로 배포하는 식입니다. 굉장히 간단합니다.

 

 

Github flow에서 병합 주기를 짧게 한다면 trunk-based 방식이 됩니다.

기능 개발과 병합을 자주하여 개발 브랜치는 짧게 유지하며 CI/CD를 자주 사용합니다.

짧게 유지되는 브랜치가 양동이를 닮았다고 하여 trunk-based라고 불립니다.

 

 

지나치게 간단한 github flow를 보완한 것이 gitlab flow입니다.

그러나 배포, 환경, 릴리즈, 소스 통합 등 다양한 궁금증이 남아있었기에 이를 해결하고자 gitlab flow라는 방식을 새로 고안하였습니다.

 

- 배포 기간이 정해진 경우 발생하는 통합 이슈 해결책

- 서버 환경에 따른 브랜치 구성 방법

- 릴리즈 버전이 master와 분리되어 운영되어야 하는 상황 타개법

 

등을 보완하여 추가적인 가이드를 제공합니다.

그 중에서도 이슈를 생성하여 유지보수가 용이하게 관리하자고 합니다.

이슈란 병합이나 코드리뷰와는 다르게 특정한 주제를 작성할 수 있는 Git의 기능입니다.

 

 

지금 촬영하고 있는 서버 호스팅 강의에서는 어느정도 완성된 코드를 바로 서버에 올릴 것이기에

Git 브랜치 전략을 사용하지는 않을 겁니다.

 

저는 지난 프로젝트에서 웹 서비스를 구축하며 master, develop, feature 브랜치를 주로 사용하였습니다.

Release나 production 브랜치도 사용해보려고 했지만 필요가 없었습니다.

Feature에서 개발하여 develop으로 merge하고, merge된 코드를 바로 CI/CD 과정을 거쳐 서버를 업데이트 하였습니다.

그리고 하나의 저장소에서 FE와 BE 작업을 동시에 진행했기에 FE와 BE 소스코드를 통합하는 용도로

master 브랜치를 사용하였습니다. 기능 개발 후 병합만 하는 과정은 간단한 trunk-based 방식을 닮았네요.

 

Git 브랜치 전략에는 정답이 없으니, 필요한 대로 구성해보시면 좋을 것 같습니다.

 

마지막으로 이전에 정리했던 git commit 메시지 규칙, 브랜치 삭제 이유, 자주 쓰는 명령어를

간단하게 보여드리고 마무리 짓도록 하겠습니다.

 

Git 명령어는 공식 사이트에 더 자세하게 나오니까 참고하시면 좋을 것 같습니다.

 

 

감사합니다.

 

---

 

참고:
git flow 전략
- https://inpa.tistory.com/entry/GIT-%E...
- https://hyeon9mak.github.io/git-branc...
- https://sungjk.github.io/2023/02/20/b...
- https://techblog.woowahan.com/2553/
- https://nvie.com/posts/a-successful-g...
- https://tech.mfort.co.kr/blog/2022-08...

웹 개발에 적합한 git flow
- https://hudi.blog/git-branch-strategy/
- https://blog.hwahae.co.kr/all/tech/9507

github action testing
- https://velog.io/@adam2/GitHub-Action...

브랜치 삭제 이유
- https://yeon-kr.tistory.com/200
- https://velog.io/@koyk0408/git-%EA%B9...

브랜치 이름 패턴
- https://junjunrecord.tistory.com/131

gitlab flow
- https://brownbears.tistory.com/605
- https://docs.gitlab.com/ee/topics/git...

git 충돌이 발생하는 경우
- https://www.atlassian.com/ko/git/tuto...

git commit 컨벤션
- https://overcome-the-limits.tistory.c...

자주 쓰는 명령어
- https://wecandev.tistory.com/152