[ASAC 06] Git (6) - branch 를 이용한 버전 관리 진행 및 git-flow 전략

flavor_blue·2024년 8월 30일

git

목록 보기

6/8

이번에는 branch를 이용한 버전 관리를 진행 해 보겠다. Git 및 Github를 사용하는 가장 큰 이유는 다수의 사용자(개발자)를 위한 분산 버전 관리이다. 지난번 올렸던 로또 프로그램을 가장하여 시나리오를 하나 만들어 보겠다.

시나리오

개발자 flavor_blue는 로또 프로그램 개발팀의 개발자A로 입사했다. 기존에 잘 작동하던 lotto 프로그램을 유지보수하는 업무를 진행하는 개발자 A는 분산 버전 관리 프로그램인 git을 통해 개발팀의 github에 연결하여 main 코드를 다운 받는다. 자잘한 기능에 대해 추가 및 수정을 진행하고, commit 후 main에 push를 한 뒤 배포를 진행 했더니, 갑작스럽게 치명적인 이슈가 발생하여 모든 사용자가 프로그램을 사용할 수 없게 되었고, 이로 인해 회사에 막대한 책임이 생기며 회사는 망하게 되었다.

main에 직접 수정하면 안돼?

~~조금 극단적으로 표현 했지만,~~ 이렇듯 실제 개발시에 1개의 브랜치 (특히 master 혹은 main)만 사용하는 것은 상당한 위험을 동반한다. 그래서 main 브랜치는 대부분 "가장 원활하게 동작하는 상태의 프로젝트"가 등록되어 있다. 업데이트 시 이슈가 발생해도 롤백을 진행하면 언제든 다시 정상 동작 할 수 있는 상태의 브랜치를 말한다.

테스트 및 배포를 위한 Zone 구성 및 Git 브랜치 전략

현업에서는 이러한 문제를 방지하기 위해 업무 별로 Zone을 나누어 구성한다.

Local Zone

실제 개발을 진행하며, 디버깅 및 로컬 테스트를 수행하는 로컬 환경이다. 주로 개발자의 컴퓨터 구역이 된다. 웹 개발자의 경우, 자신의 개발용 PC에 RDBMS도 설치하고, 개발용 IDLE도 설치하고, 가상으로 올리기 위한 WAS 프로그램도 설치하여 개발을 진행하고, 해당 과정에서 테스트까지 진행하게 된다.

Develop Zone

Local Zone 에서 개발 및 테스트를 다 완료하였으면, Develop Zone에 업로드하여 테스트를 진행한다. 주로 같은 프로젝트 인원 혹은 같은 회사 인원들을 대상으로 테스트를 진행한다. 기존의 로컬 서버보다 더 많은 데이터를 미리 넣어둔 뒤 테스트를 진행 하기에 Local Zone 보다 운영에 더 가까운 환경이며, Local 에서 혼자 진행할 때 보다 더 많은 케이스를 경험하고 대처할 수 있다. 간단하게 개발서버라고 생각해도 좋다.

Staging Zone

운영 환경에 가장 가까운 Zone이다. 최종 배포전 네트워크 및 인프라 환경에 대한 마지막 테스트이다. Staging Zone은 운영 환경과 최대한 비슷하게 구현하기 때문에 네트워크 환경이나 더 많은 데이터를 대상으로 테스트를 진행할 수 있기 때문에 마지막 테스트 환경이라고 생각할 수 있다. 허나 아무래도 운영 서버를 하나 더 만드는 것인 만큼, 비용적으로 부담이 많이 되기 때문에 Staging Zone을 구비하지 않는 회사들도 있다.

Production Zone

대망의 운영 존이다. 실제 유저가 사용하는 환경이며, 개발 및 수정등에 신중해야 하고, 제약이 심하다. 개발 및 테스트를 완료하면 실제 유저들이 사용할 수 있게 해당 환경에서 배포해야 한다.

Git 에서의 Branch 전략, git-flow

원칙은 모든 배포는 격리된 브랜치에서 작업을 완료한 뒤 PR을 통해 배포를 위한 브랜치에 머지해야 한다. 중요도에 따라 3가지의 브랜치로 나뉜다.

Master / Main : 배포 브랜치

버그 발생에 대한 불확실성이 낮고, 무결하여 운영존에 치명적 문제 발생 시 롤백할 수 있는 커밋의 집합이다.

Develop (Staging) : 테스트 브랜치

로컬에서 개발 및 테스트를 완료하면 마지막 테스트를 위해 사용하는 브랜치이다. Staging Zone을 위한 브랜치를 따로 둘 수도 있지만, 조금 과한 정책으로 치기도 한다. 로컬 영역에서 개발을 완료하면 PR 요청을 진행하여 개발 브랜치에 업로드하고, 테스트를 준비한다.

Feature : 개발 브랜치

Develop 브랜치를 기점으로 새 브랜치를 만들어 개발하는 브랜치이다. 로컬에서 개발할 때 Feature 브랜치를 받아 쓰며, 브랜치의 이름은 회사의 내규에 따라 정해진다고 한다. 작업의 이름이 될 수도 있고, 개발자 명이 들어갈 수도 있고 다양하다.

💫PR 이란?
pull request 의 줄임말로, 코드를 수정 했으니 내 수정내용을 적용시켜 달라는 의미를 가진다. Feature 브랜치에서 개발이 완료 됐을 경우, develop branch에 해당 내용을 pull request 한다.

실습

위의 내용을 바탕으로 기존의 lotto45 브랜치를 영역화 해보도록 하겠다.

git checkout 'branch name'

checkout 명령어는 다른 브랜치로 이동시켜주는 명령어다. 다만 브랜치는 기존에 존재한 경우에만 이동이 가능한데, 이러한 부분을 스킵하고 바로 만들면서 이동하게 해주는 옵션이 바로 -b 옵션이다.

git checkout -b develop

또한, 브랜치는 새로 만들려면 참조하는 브랜치가 있어야 한다. 최초 생성(git init) 시 main(혹은 master)브랜치가 생성되는데, 해당 브랜치에서 checkout -b 를 사용하면 해당 브랜치를 기반으로 하는 신규 브런치가 생성된다. git branch -a 명령어를 사용하여 생성된 브랜치 목록을 조회할 수 있다.

방금 생성된 브런치를 확인할 수 있다.

빨간색 부분은 remotes 즉, 원격 저장소의 브랜치 상태를 보여주는 것이다. 해당 내용으로만 확인 해 보면 로컬에는 develop branch 가 있지만, 원격 저장소에는 develop branch가 없는 상황 이다. 해당 내용을 github repository 에 업로드 하고 싶다. commit 을 만들어 push를 진행 해 주면 된다. 그러나, commit이 되지 않는다. 왜냐하면 기존에 수정된 내용이 없기 때문이다.

비어있는 내용을 커밋 후 푸시하기 위해선 --allow-empty 옵션을 사용하면 된다.

git log를 사용하여 현재 쌓여있는 commit을 확인할 수 있다.

push를 진행 해 주자.

원격 저장소에 잘 push 가 됐다!

Github 페이지에서도 확인 가능하다!

다시 한 번 신규 브랜치를 만들어보자. 위의 내용에서 Feature에 해당하는 부분이다. 실질적으로 내가 개발하는 환경에 대한 브랜치를 생성 할 것이다. ~~이름에 대한 규칙은 뭐... 일단 마음대로 해 보겠다.~~

몇 가지 작업을 진행한 뒤, git status 를 입력해 상태를 확인하자

작업 내역
	1. 코드 클린 진행.
    2. .gitignore 추가, >> /out 항목 추가
    3. out 폴더 삭제 : 빌드시 생성되는 파일.

git add . 명령어를 사용하여 변경 사항들을 스테이징 영역에 업로드하자.

💡문서 파일 작성시 출력되는 warning: in the working... LF will be replaced by CRLF~ 의 의미는?

git 은 리눅스 기반의 프로그램이기 때문에 윈도우의 줄바꿈과 처리 방식이 다르다.해당 warning 메시지는 처리 방식을 자기가 잘 변환했다는 의미를 내포한다. 경고문을 보고싶지 않으면 git config --global core.autocrlf true 명령어를 사용한다.

커밋을 진행하자. 다만 이번에는 작업 내역이 좀 많다. 저 내용을 한 줄에 다 넣을 순 없으니까 다른 방법을 찾아보도록 하자.

기본적인 git commit 명령어만 사용하면, commit 메시지를 입력할 수 있는 부분의 에디터로 넘어가게 된다.

해당 에디터를 이용하여 위의 작업 내역을 추가 해 주자.

내용 입력 후, 저장 및 종료를 진행하자

간단한 vi or vim 에디터 사용법

입력 모드 : 최초 접근 후, Insert kye 입력.

해당 모드 종료 시 esc 키 입력.

저장 : 입력모드 종료 된 상태에서 :w 입력.

종료 : 입력모드 종료 된 상태에서 :q 입력.

두개 같이 사용하려면 :wq 입력.