[Git] Git 개념과 흐름 / Branch 전략

Git

 

 소스코드를 효과적으로 관리하기 위해 개발된 '분산형 버전 관리 시스템'

 Git을 사용하면 소스코드가 변경된 이력을 쉽게 확인할 수 있고, 특정 시점에 저장된 버전과 비교하거나 특정 시점으로 되돌아 갈 수 있음.

 

 

Git 저장소

 

1. 원격 저장소 : 파일이 원격 저장소의 전용 서버에 저장, 관리되며 여러 사람이 공유하기 위한 저장소

ex) Github, Bitbucket 등

2. 로컬 저장소 : 내 PC에 파일이 저장되는 개인 전용 저장소

 

 

Git 저장소 만들기

 

 Git으로 관리하기를 원하는 저장소에 접근하여 git init 명령어 사용

-> 해당 폴더에 .git이라는 하위 디렉토리가 생성되며, 해당 폴더에 저장소에 필요한 뼈대 파일이 들어 있음.

 

 

기존 저장소 Clone 하기

 

기존에 생성되어 있는 Git 저장소를 복사해 사용하고 싶을 때, git clone 명령을 사용해 저장소를 로컬에 복사할 수 있음.

ex) $ git clone https://github.com/user_name/repo_name

 

 

Git status / Git add / Git commit

 

[Untrack <-> Staged]

 

 처음 Git 저장소에 파일을 생성해도 추적되지 않는 상태(Untracked)이며, 해당 파일을 관리하려면 add 명령어를 통해 Staged 상태로 만들어야함.

 

$ git status

 

 git status 종류

 

1. Changes to be commited

 - Staged 영역에 넘어가 있는 변경 내용

2. Changes not staged for commit

 - 아직 워킹 디렉토리에서 Stage 되지 않은 변경 내용

3. Untracked files

 - 아직 Git 저장소가 관리한 적 없는 새로운 파일

 

위와 같이 3 종류의 분류로 확인이 가능함.

 

$ git add <파일/디렉토리 경로>

 

 아직 Git에서 관리하지 않는 파일 / 변경 내용을 스테이징 영역으로 넘기는 명령어

 

 git add 옵션

 

1. git add <파일/디렉토리 경로>

 - 작업 디렉토리 변경 내용의 일부만 스테이징 영역으로 넘길 때 사용

2. git add .

 - 현재 디렉토리의 모든 변경 내용을 스테이징 영역으로 넘길 때 사용

   (현재와 하위 디렉토리)

3. git add -A

 - 작업 디렉토리 내의 모든 변경 내용을 스테이징 영역으로 넘길 때 사용

   (상위 디렉토리 포함)

 

$ git commit

 

 git add를 통해 스테이징 영역에 위치한 파일을 커밋

 

 git commit 옵션

 

1. git commit -m

 - 커밋 메시지를 입력 후 commit

2. git commit -a

 - git add 과정을 생략하고 tracked 상태의 파일을 자동으로 스테이징 영역에 추가하여 커밋

3. git commit -v

 - 커밋 메시지에 마지막 커밋과 staging area의 차이를 기록

 

 

fork ~ Pull Request 흐름 정리

$ git clone https://github.com/user_name/repo_name -b branch_name --single-branch

 

 1. 타인의 Github repository를 로컬 repository로 Clone 한다.

 -b branch_name : 해당 브랜치를 가져옴.

 --single-branch : 특정 브랜치 하나만 clone 함.

 

$ git add

 

2. 변경된 파일을 tracked 상태로 변경.

 

$ git commit -m "msg"

 

3. 메시지와 함께 tracked 상태의 파일들을 반영

 

$ git push origin branch_name

 

4. 원격 저장소에 공유

 - origin : 원격 저장소(remote)의 주소

 - branch_name : 현재 브랜치를 의미(master 등)

 

5. PR(Pull Request)

 Github 웹에서 내가 fork하여 commit 한 내역을 원본 repository의 관리자가 확인하고, merge 여부를 결정함.

 

 

Branch 전략 - Git Flow

 

 Git Branch 전략은 권한, 생명주기, 디버깅 등을 고려하여 코드 품질 향상, 가독성 향상을 목적으로 하여 세워진다.

 

Git flow 전략

위 그림은 Git Flow 전략으로, 다음과 같이 구성되어 있다.

 

1. master : 제품으로 출시될 수 있는 브랜치

2. develop : 다음 버전 개발을 위한 브랜치

3. feature : 기능 개발을 위한 브랜치

4. release : 이번 버전 출시 준비 브랜치

5. hotfix : 출시된 버전 버그 수정을 위한 브랜치

 

 처음에는 master와 develop 브랜치로 시작하여, develop 브랜치에서 상시로 버그를 수정한 커밋들이 추가된다.

새로운 기능 추가를 위해 develop 브랜치에서 feature 브랜치를 시작하여 작업 완료 시 develop 브랜치로 merge된다.

develop 브랜치에 이번 버전에 포함될 모든 기능이 merge 되었다면, QA를 위해 develop 브랜치로부터 release 브랜치를 생성한다. QA를 진행하며 발생한 버그들은 release 브랜치에 수정되며, QA를 모두 통과했다면 release 브랜치를 master와 develop 브랜치로 merge하여 마지막으로 master 브랜치에서 버전 태그를 추가한다.

 

 기존에 다른 사람들과 함께 프로젝트를 진행했던 경험에서는 '버전'이라는 개념이 잡혀있지 않고, 하나의 완성된 어플리케이션 만을 향해 달려갔기 때문에, Git Flow 전략에서 feature 브랜치와 develop 브랜치의 두 가지 개념만 사용했던 것 같다는 생각을 했다.

 실무에서는 계속해서 서비스를 유지해야하기 때문에 버전이라는 개념이 중요하고, 브랜치 전략이 얼마나 중요한지 이제서야 깨닫게 된 듯 하다.

 

 

 

References

https://techblog.woowahan.com/2553/ 우아한 형제들 기술 블로그

https://git-scm.com/book/ko/v2/ Git Documentation - Book