💡
우리는 평소 소스코드나 문서를 다룰 때, 너무 많은 복사본이 있다거나, 수정본에서 원본으로 되돌리고 싶은데 어렵다거나 하는 상황적 문제를 종종 마주한다. 이럴 때에는 '버전 관리'를 통해 많은 문제를 해결할 수 있다. 지금부터 알아볼 Git도 '버전 관리 시스템'에 속하는 프로그램 중 하나이다. 우선 '버전 관리'와 '버전 관리 시스템'이 무엇인지 알아보고, Git과 Git Workflow에 관해서 파헤쳐 보자.

📌 버전 관리 시스템

버전 관리

: 소프트웨어 개발 및 유지 보수 과정에서 발생하는 소스 코드, 문서 등의 생성, 변경 이력, 삭제 이력 등을 관리하는 것이다.

버전 관리의 필요성

우리는 다음의 상황에서 버전 관리가 필요함을 인지한다.

• 너무 많은 복사본이 있어 어떤 것이 최신 파일인지, 어떤 버전이 어떻게 수정된 것인지 알기 어렵다.
• 잘 작동하는 코드에 새로운 기능을 추가하다가 원인을 알 수 없는 오류가 발생해서, 이전 상태로 돌아가고 싶은데 수정사항이 많이 돌아갈 수가 없다.
• 여러 명이서 동시에 작업을 할 때, 여러 명이 동시에 여러 파일을 수정해 오류 또는 충돌이 발생한다(혹은 동시에 편집할 수 없어 한참 동안 기다려야 했다).
• 여러 명이서 작업을 할 때, 누가 어떤 부분을 어떻게 수정했는지 알 수가 없다.

버전 관리 시스템(VCS, Version Conrtol System)

: 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 불러올 수 있는 시스템이다. 버전 관리 시스템은 크게 Local VCS, Centralized VCS, Distributed VCS로 나눌 수 있다.

• 로컬 버전 관리 시스템(Local VCS)
  간단한 데이터베이스를 이용해 파일의 이력(변경 정보)을 관리하는 시스템이다. 대표적인 VCS인 RCS(Revision Control System)은 파일에서 변경되는 부분(Patch)만 기억해두고, 버전 변경은 해당 버전까지의 일련의 변화들(Patch Set)을 적용/해제하는 식으로 동작한다.

• 중앙 집중식 버전 관리 시스템(CVCS, Centralized VCS)
  파일 및 변경 이력 등을 서버로 옮겨 관리하는 시스템이다. 중앙의 서버가 파일들과 이들의 변경 이력을 관리하고, 각 클라이언트는 서버에 접속해서 특정 버전의 스냅샷(snapshot)을 받아서 사용하는 형태로 동작한다. 대표적으로 SVN(SubVersion), CVS(Concurrent Versions System) 등이 있다.
  중앙 집중식 버전 관리 시스템의 문제점은 다음과 같다.

  • 모든 버전 관리 관련 동작은 서버에서 처리되어야 하므로 서버의 부하가 크다.
  • 서버가 죽거나 장애가 발생하면 버전 관리가 이루어지지 않는다.
  • 오프라인 상태에서는 버전 관리 시스템을 사용할 수 없다.
  • 모든 버전 관리 관련 동작은 적어도 한 번 서버를 경유해야 하므로 속도가 느리다. 하다못해 로그를 보는 것조차 서버에서 데이터를 받아 와야 하므로 느리다.
  • 서버에서 데이터가 망가지거나 삭제되면 복구하기 매우 어렵다.

• 분산식 버전 관리 시스템(DVCS, Distributed VCS)
  서버가 파일 및 변경 이력 등을 독점하는 것이 아니라, 각 클라이언트들이 모두 서버의 백업본을 가지는 방식이다. 대표적으로 Git, Mecurial, Bazaar 등이 있다.

💡
분산식 버전 관리 시스템에서도 가장 유명하고, 가장 널리 쓰이는 것이 Git이다. Git이 무엇이고, 어떤 특징을 가지는지 알아보자.

📌 Git

Git은 우리에게 리눅스로 유명한 리누스 토르발즈가 2005년에 개발한 분산 버전 관리 시스템으로, 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 파일에 대한 작업을 조율하는 데 사용된다. 즉, 주로 여러 명의 개발자가 하나의 소프트웨어 개발 프로젝트에 참여할 때, 소스 코드를 관리하는 데 사용된다.

Git의 특징

• 로컬저장소에 저장 후 서버에 업로드하는 방식이다.
• 작업은 로컬에서 진행하고, 업로드만 네트워크를 사용하므로 속도가 빠르다.
• 각각의 개발자가 Branch에서 개발한 뒤, 본 프로그램에 합치는 Merge 방식을 통한 병렬 개발이 가능하다.
  (Branch와 Merge를 이용하기에 동시 업로드 시 충돌 가능성도 낮음)
• 인터넷 연결이 되지 않은 곳에서도 개발을 진행할 수 있으며, 분산 버전 관리이기 때문에 중앙 저장소가 삭제되어도 원상복구가 가능하다.
• 히스토리 관리 기능이 잘 제공되어, 히스토리 관리가 용이하다.

Git의 기본 용어

• Repository : 저장소 // 저장소는 히스토리, 태그, 소스의 가지치기 혹은 branch에 따라 버전을 저장한다. 작업자가 변경한 모든 히스토리를 확인할 수 있다.
• Working Tree : 저장소를 어느 한 시점을 바라보는 작업자의 현재 시점
• Staging Area : 저장소에 커밋하기 전에 커밋을 준비하는 위치 // 커밋하고 싶은 파일을 넣어두는 곳이다.
• Commit : 현재 변경된 작업 상태를 점검을 마치면 확정하고 저장소에 저장하는 작업 // 즉, 새로운 버전의 파일을 저장하는 것이다.
• Head : 현재 작업 중인 branch
• Branch : 가지 또는 분기점 // 작업을 할 때 현재 상태를 복사하여 Branch에서 작업을 한 후에 완전하다 싶을 때 병합(merge)한다.
• Merge : 다른 Brabch의 내용을 현재 Branch로 가져와 합치는 작업

Git의 기본 명령어

• git help : 도움말 기능(가장 많이 사용하는 21개의 깃 명령어 출력). 'git help [명령어]'를 입력 시, 해당 깃 명령어의 설정과 사용에 대한 도움말 출력
• git init : Git 저장소(repository)를 초기화
• git status : 저장소 상태 체크
• git branch : 새로운 브랜치 생성
• git add : 'staging 영역'에 변경 내용 추가 // 다음 commit 명령 전까지 변경분을 staging 영역에 보관해 변동 내역을 저장해 둔다.
• git commit : staging area에 있는 변경 내용을 묶고 정의
• git log : 커밋 내역 확인
• git push : 로컬 컴퓨터에서 서버로 변경사항을 "push"
• git pull : 서버 저장소로부터 최신 버전을 "pull"
• git clone : 서버 저장소의 데이터를 로컬 컴퓨터로 복사 (서버 저장소의 데이터를 그대로 가져옴) (cf. 프로젝트에 처음 투입될 때 사용)
• git checkout : 작업하기 원하는 브랜치로 이동
• git merge : 개별 branch에서 마친 작업을 master branch로 병합

// 로컬 저장소에 새로운 버전의 파일을 저장하는 commit, 로컬 컴퓨터에서 서버로 변경 사항을 보내는 push는 다른 개념이다. commit과 push를 혼동하지 않도록 유의하자.

📌 Git Workflow

Git은 브랜치로 작업을 관리하는데, 팀에서 브랜치를 어떻게 사용할지에 대해 정해둔 규칙을 Workflow라고 한다. Git을 사용한 가장 대표적인 Workflow는 Git flow, Github flow, Gitlab flow가 있다.

Git flow

브랜치의 역할이 명확하고 대규모 프로젝트에 적합한 workflow이다. 5개의 브랜치로 관리하며 2개의 메인 브랜치인 master, develop과 3개의 보조 브랜치인 feature, release, hotfix로 나뉜다.

• master
  제품으로 출시하는 브랜치, 실제 배포 중인 상용 버전이다.
• develop
  다음 출시 버전을 개발하는 브랜치, 실제 작동 중인 버전의 다음 버전을 개발하기 위한 메인 스트림이다.
• feature
  기능을 개발하는 브랜치로, 실제 개발을 할 때 가장 많이 사용하는 브랜치이다. 일반적으로 (develop 브랜치에서 뻗어 나와) 기능별 브랜치를 생성하고 기능 개발을 마치면 develop 브랜치로 합쳐진다.
• release
  새로운 버전을 배포하기 위한 브랜치이다. develop에서 뻗어 나와 다시 develop으로 합쳐지거나 배포 준비가 끝났으면 master로 합쳐진다. 주로 버그를 수정하는 디버깅만 커밋한다.
• hotfix
  상용 제품에서 버그가 발생했을 때 처리하는 브랜치이다. 버그 픽스를 위한 브랜치로 디버깅만 커밋하며, 보통 일회성으로만 사용한다. master 브랜치에서 뻗어 나와 버그를 모두 수정하면 master와 develop에 합쳐진다(merge).

✅ Git flow의 작업 과정
1. 개인 작업은 develop에서 feature 브랜치를 따서 작업한다. 개인 작업이 끝나면 develop에 병합한다.
2. develop 브랜치에서 배포 준비가 끝나면 release 브랜치로 분할한다.
3. release 브랜치에서 디버깅하고 문제가 없으면 master와 develop 브랜치에 합친다.
4. master 브랜치를 배포한다.
5. 만약 배포 버전에서 문제가 생겨 급하게 수정해야 하면 hotfix 브랜치를 따서 작업한다.
6. hotfix에서 버그 픽스가 끝나면 master와 develop에 합친다.

Github flow

하나의 메인 브랜치인 master 브랜치를 중점으로 운용하며 pull request를 활용하는 방식의 workflow이다.
(+ pull request는 "작업한 코드가 있으니 내 브랜치를 pull해 검토, 병합해달라"라는 의미)

• github flow는 브랜치의 용도가 명확하게 분류되지 않기 때문에 브랜치를 생성할 때 어떤 작업을 위한 브랜치인지 명확하게 작성해야 한다.
• 일반적으로 feature 브랜치의 작업은 local 저장소가 아닌 원격 저장소에 저장한다.
  

✅ Github flow의 작업 과정
1. 개인 작업은 feature 브랜치에서 작업하며 작업이 끝나면 pull request를 생성한다
2. pull request에서 코드 리뷰 후에 문제가 없으면 master 병합한다.
3. master에 병합하면 바로 배포 작업을 수행한다. (CI 자동화 권장?)

Gitlab flow

master와 develop 2개의 메인 브랜치로 관리하는 방식의 workflow이다. 이는 항상 최신 버전의 버전을 유지하지 않아도 되며 배포 버전과 개발 버전을 따로 둘 수 있다는 장점이 있다.

✅ Gitlab flow의 작업 과정
1. develop 브랜치는 githubflow의 develop 브랜치와 같은 역할을 한다. (항상 최신 버전의 코드를 관리하며 작업을 하는 메인 브랜치)
2. develop 브랜치가 배포되기 적합하다고 판단되면 master 브랜치에 merge한다.

📌 Merge 전략

Git은 한 브랜치에서 작업한 내용을 Main 브랜치에 병합(Merge)할 수 있는 다양한 방법들을 제공한다. 이러한 방법들을 Merge 전략이라고 부른다.

Merge Commit [3-way Merge]

: 모든 브랜치의 commit log와 merge log가 동시에 기록되는 방식이다. 기본 머지라고도 불리는 Create a merge commit은, 모든 브랜치의 커밋이 히스토리에 기록되기 때문에 모든 커밋 정보를 상세하게 파악할 수 있으나 그만큼 히스토리가 복잡해지는 단점이 있다.

Squash and Merge

: 여러 개의 commit을 하나로 합친 후 merge하는 방식이다. 작업 완료된 브랜치의 커밋은 새로운 커밋으로 모두 합쳐져 main 브랜치에 하나의 커밋으로 기록되고, 기존의 작업 완료된 브랜치는 삭제된다. Create a merge commit과 비교하자면, 상세한 커밋 기록에 관한 정보를 잃을 수 있으나 그만큼 히스토리가 간결해진다.

Rebase and Merge

: Rebase 기능을 사용해 브랜치를 merge하는 방식으로, 신규 branch의 시작점을 main의 가장 최근 커밋으로 (강제로) 옮기는 것이다. rebase 덕분에 merge된 이후의 로그를 보았을 때 하나의 브랜치에서 연속적으로 작업한 것과 같은 로그를 확인할 수 있다는 것이 특징이며, 이 때문에 얼마든지 항상 원하는 수준으로 rollback이 가능하다. 하지만 강제성을 가지는만큼, (rebase 작업이 필요해지는 상황에) 발생할 수 있는 충돌을 잘 해결해야 한다.

Rebase란?
메인브랜치가 있고, 새로운 브랜치를 만들어 두 브랜치가 각각 추가적인 커밋을 한 경우에서 새로운 브랜치의 시작점을 강제로 옮기는 것이다.
쉽게 말하자면, 서로 전혀 상관이 없는 두 기능을 만들었고, 그 기능이 완벽하게 구현됐다면 둘을 합치지 않을 이유가 없다. 이때 새롭게 만들어낸 브랜치의 시작점을, 메인 브랜치의 마지막 커밋 지점으로 강제로 옮겨서 하나로 만드는데, 이를 rebase라 한다.

Fast-forward Merge란?
메인브랜치가 있고 새로운 브랜치를 만들었는데, 메인브랜치는 새로운 변경사항이 없고 새로운 브랜치만 변경사항이 있는 상황에서, 단순히 새로운 브랜치를 메인브랜치로 옮기는 것을 말한다.
(옆으로 뻗은 하나의 가지를 메인으로 슥 옮겨오는 것이다.)