사실 토이 프로젝트를 만들 때는 대체로 배포하기 위한 목적이 아니기 때문에 main 브랜치 하나로 관리가 가능하다.
그러나 개인 프로젝트를 오픈소스에 배포하거나 서비스로 출시한다면?
개발하는 과정을 모두 서비스 사용자에게 보여줄 필요는 없다. 이럴 땐 브랜치를 잘 활용하여 배포본을 main으로 관리하고 업데이트를 위해 dev 브랜치나 feat 브랜치를 사용하면 된다. 개인 프로젝트 관리방법을 차례대로 알아보자.
1. 레포지토리 만들고 로컬로 가져오기
README파일을 만들지 않으면 레포지토리에 따로 브랜치가 생기지 않는다. 아예 비어있는 상태이다.
반면, 시작할 때 README 파일을 만들면 main이라는 default 브랜치가 생긴다. 아래과정을 한 번에 처리한 것이다.
(Repo에 1 commit 이라는 표시가 있다., 확인해보면 "initial commit" 이라는 커밋메시지가 자동으로 들어가있다.)
$ git init
$ touch README.md
$ git add .
$ commit -m "initial commit"
이제 git clone 명령을 통해 로컬저장소로 정보를 가져온 다음, git log를 통해 확인해보자
$ git clone 원격저장소_주소
$ git log
commit 91eca875d10cad5919acc00c4c004fdd2383c2bb (HEAD -> main, origin/main, origin/HEAD)
Author: BigBell <90585081+pythonstrup@users.noreply.github.com>
Date: Sun Feb 13 16:05:43 2022 +0900
Initial commit
2. 개인 프로젝트 관리를 위해 필요한 브랜치
브랜치의 종류는 총 5가지가 있다.
① Main
② Develop
③ Feature (또는 Topic)
④ Release
⑤ Hotfix
여기서 사용할 것은 ①, ②, ③ 이다.
main branch는 기존 브랜치로 배포 가능한 상태만 담을 것이다.
develop branch은 다음 버전 출시를 위해 사용하는 브랜치로 배포 가능한 상태가 되면 main과 합병(merge)한다.
feature branch 또는 topic branch는 새로운 기능을 개발하거나 버그를 수정해야할 때마다 develop branch에서 분기해 나오는 브랜치이다. 대체로 로컬저장소에서만 관리하는 브랜치이다. 개발이 완료되면 develop branch와 병합한다. 상황에 따라 1개가 될 수도 있고, 여러 개의 feat 브랜치를 가질 수도 있다.
이제 브랜치를 만들어보자. feat 브랜치를 통해 개발을 진행할 것이기 때문에
feat 브랜치 생성과 동시에 체크아웃을 진행하도록 하겠다.
$ git branch dev
$ git checkout -b initial_feat
git branch를 통해 확인해보면 아래와 같이
$ git branch
dev
* initial_feat
main
3. feat 브랜치와 dev 브랜치의 합병(merge)
현재 feat 브랜치에서 초기 환경설정을 위해 작업을 진행했고, 세팅이 완료됐다고 해보자.
$ git log
commit f9937bc6f74b8fd952cf689afd7510e8ec1ab652 (HEAD -> initial_feat)
Author: BigBell <pythonstrup@gmail.com>
Date: Sun Feb 13 16:44:38 2022 +0900
세팅완료
commit 91eca875d10cad5919acc00c4c004fdd2383c2bb (origin/main, origin/HEAD, main, dev)
Author: BigBell <90585081+pythonstrup@users.noreply.github.com>
Date: Sun Feb 13 16:05:43 2022 +0900
Initial commit
그냥 dev branch를 단순히 세팅완료로 옮기는 fast-forward merge를 할 수도 있지만,
만약 합병 로그를 남기고 싶다면 아래와 같은 명령어를 사용해야한다.
# dev쪽으로 병합하기 위해 HEAD를 옮김
$ git checkout dev
# 병합실행
$ git merge --no-ff initial_featvi 에디터로 들어가 질텐데 그냥 나오자.
만약 fast-foward 방식으로 하고 싶다면 --no-ff 부분을 빼면 된다.
로그를 확인하면 합병 로그가 남은 것을 확인할 수 있다.
$ git log
commit 1d2d40b72c2ce73244639108d83d75c0ead4fb17 (HEAD -> dev)
Merge: 91eca87 f9937bc
Author: BigBell <pythonstrup@gmail.com>
Date: Sun Feb 13 16:57:14 2022 +0900
Merge branch 'initial_feat' into dev
commit f9937bc6f74b8fd952cf689afd7510e8ec1ab652 (initial_feat)
Author: BigBell <pythonstrup@gmail.com>
Date: Sun Feb 13 16:44:38 2022 +0900
세팅완료
commit 91eca875d10cad5919acc00c4c004fdd2383c2bb (origin/main, origin/HEAD, main)
Author: BigBell <90585081+pythonstrup@users.noreply.github.com>
Date: Sun Feb 13 16:05:43 2022 +0900
Initial commitfeat 브랜치는 바로 삭제해도 상관없지만, 혹시 모를 상황을 대비 남겨놨다가 브랜치가 너무 많아지면 정리하는 것을 추천하고 싶다.
4. main branch(배포본)으로 병합하기
dev 브랜치에서의 개발이 끝나 main과 합칠 때가 됐다. main으로 체크아웃해주자.
처음 main으로 체크아웃하면 그동안 남겨놓은 파일이 없기때문에 .git 디렉토리와 README밖에 없지만
당황하지 말자. merge를 실행하면 모든 파일이 정상적으로 생성될 것이다.
$ git checkout main
로그를 확인해보면 main과 dev가 병합된 것을 확인할 수 있다.
$ git merge --no-ff dev
$ git log
commit 1a45aec564309e98b13ccbb470f95b4d36c92da8 (HEAD -> main)
Merge: 91eca87 454c580
Author: BigBell <pythonstrup@gmail.com>
Date: Sun Feb 13 17:15:53 2022 +0900
Merge branch 'dev'
commit 454c580cd31e9269ba5d0f7eb58cdf3d43809223 (dev)
Merge: a1d7bd1 4aadca2
Author: BigBell <pythonstrup@gmail.com>
Date: Sun Feb 13 17:13:14 2022 +0900
Merge branch 'board_feat' into dev
commit 4aadca23804f9d05a3d61c64368352e50d4ce447 (board_feat)
Author: BigBell <pythonstrup@gmail.com>
Date: Sun Feb 13 17:10:40 2022 +0900
3.게시판 완료
여기서 프로젝트에 버전번호와 함께 태그를 달아주자.
깃로그를 확인하면 태그가 달려있는 것을 확인할 수 있다. git tag -n을 통해서 확인해도 된다.
$ git tag project1.0.0
$ git log
commit 1a45aec564309e98b13ccbb470f95b4d36c92da8 (HEAD -> main, tag: project1.0.0)
Merge: 91eca87 454c580
Author: BigBell <pythonstrup@gmail.com>
Date: Sun Feb 13 17:15:53 2022 +0900
Merge branch 'dev'
...
...
$ git tag -n
project1.0.0 Merge branch 'dev'
이제 main과 dev를 푸시를 해주면 끝이 난다. --tags를 붙여주지 않으면 태그가 생성되지 않으니 주의하자.
위에서 얘기했다시피 main과 dev는 실제 사용이 가능한 상태이기 때문에 push를 해주지만,
feature branch는 비공식적인 성격을 가지고 있기 때문에 로컬저장소에 가지고 있는 것을 추천한다.
$ git push --tags origin main
$ git checkout dev
$ git push origin dev
태그를 생성하면 원격 레포지토리에서도 확인할 수 있다.
태그를 이용하면 버전관리를 할 수 있기 때문에 main 브랜치(배포본)을 push할 때는 tag 를 달아주는 것이 좋다.
