Git flow와 branch merge에 대해서

9월 3일부터 회사에서 일을 시작하게 되었다.

기존에는 개인적인 소스코드 관리를 위해 깃을 사용하고 있었지만 실제 회사에서 하는 것 처럼

복잡하게 관리를 하진 않았다.

그래서 실제 업무투입 전, 어느정도 확실히 개념을 잡아놔야 개발에만 집중할 수 있다는 생각이 들었고

이렇게 포스팅을 통해 내용을 정리한다.

먼저 아래의 사진을 보자.

구글에서 Git flow라고 검색하면 나오는 사진이다.

위 내용을 정리해보자면 다음과 같다.

- master 브랜치에서는 큼지막한 버전 단위로 관리를 한다. v1, v2, v3처럼

- 보통 개발을 하면 master에서 develop이라는 브랜치를 하나 생성한다.

- develop에서 feature라는 또다른 브랜치를 생성하고 개발한다.

- feature에서 세부 기능들이 하나씩 완료되면 develop 브랜치로 pull request를 한다.

- develop 브랜치에서 merge한다.

- 배포 완료단계까지 개발이 완료되면 develop 브랜치에서 master 브랜치로 pull request를 한다.

- master 브랜치에서 merge한다.

위와 같은 flow를 가지고 있다. 그런데 위 그림을 살펴보면 hotfixes라는 것도 있다.

이는 배포 단계에서 급하게 수정해야할 버그와 같은 사항을 위한 브랜치이다.

급한 수정이 필요한 경우에는 hotfix라는 브랜치를 하나 만들고 수정한 후 pr, master브랜치에서 merge하면 된다.

이제 실제 사용법을 익혀보자.

나는 Source tree처럼 GUI형태의 툴을 선호하지 않는다.

따라서 기본적인 터미널을 통해 CLI에서의 사용법을 설명한다. (저장소는 Bitbucket을 사용하고 있지만 Github, Gitlab 전부 동일하다)

먼저 원격 저장소를 하나 생성한다.

(설명했던대로 나는 Bitbucket을 사용한다)

그리고 터미널을 실행시키고 차례대로 따라한다.

(쉽게 말해서 디렉토리 생성 -> git 초기화 -> commit -> 원격 저장소 연결 -> push 한 것이다)

위처럼 해준 이후 원격 저장소로 들어가보면 우리가 생성한 master라는 파일이 업로드되어 있을 것이다.

이제 아래의 명령어로 dev라는 새로운 브랜치를 생성한다.

git checkout -b dev

(-b 옵션을 줄 경우, 브랜치가 존재하지 않으면 생성하고 해당 브랜치로 switch해준다)

브랜치를 생성하고 git branch 명령어를 통해 생성된 브랜치를 확인해보면

성공적으로 dev라는 브랜치를 만들었고 현재 dev브랜치를 사용하고 있음을 알 수 있다.

이제 아래의 명령어를 입력하여 dev 브랜치에서 새로운 파일을 하나 생성하고 커밋한다.

touch dev

git add .

git commit -m "dev commit"

git push origin dev

다시 git checkout master를 통해 master로 이동한 이후 파일 목록을 살펴보면

dev브랜치에서 생성한 dev파일이 존재하지 않는 다는 것을 알 수 있다.

여기서 git merge dev 명령어를 입력하면 dev 브랜치와 머지를 할 수 있다.

merge한 이후 파일 목록을 살펴보면 dev 브랜치에서 생성한 dev라는 파일이 생겼고,

git log를 통해 살펴보면 아래와 같이 dev에서 commit한 commit로그가 생겼음을 알 수 있다.

참고로 위 내용에서 dev에서 push이후 pull request를 보내주지 않고

바로 master에서 merge를 했다.

일반적인 경우에는 dev에서 Pull request를 하면 master에서 conflict등의 오류가 없는지 확인한 이후

merge한다.