[GitHub] 나의 개인 프로젝트 관리 전략?

KimJiHong·2023년 12월 5일

branch flow git github issue

Server Development

목록 보기

1/3

프로젝트 관리를 마음 먹은 이유

기존에 나는 API 관련해서 개인 토이 프로젝트식으로 만들고, 나중에 해당 기능과 비슷하게 구현할 때 기억이 잘 안나면 예전에 제작한 것을 참고하려고 내가 만든 프로젝트를 GitHub 에 올려두었다.

하지만, 내가 최근에 리포지토리 정리할 겸 예전에 만든 프로젝트들을 봤었을 때, 만든지 얼마 안된 프로젝트는 커밋 내역으로 내가 뭘 했는지 기억이 났지만 더 이전에 만든 프로젝트는 커밋 내용을 보고 "이걸 왜 만들었더라..?" 라는 생각이 들었다.

창피하지만 밑의 커밋을 보면 그냥.. 답이없다.

~~(아무리 생각해도 대체 무슨 생각으로 커밋한지 모르겠다..)~~

그래서 나는 지금부터라도 GitHub의 Branch와 Issue를 적극 활용한 좀 더 체계적인 커밋으로 미래의 내가 예전의 프로젝트를 봤을 때 무엇을 하려고 만든 프로젝트인지 복기할 수 있도록 구성하려고 한다.
(이 생각을 조금이라도 빨리 했어야했다.)

Branch 와 Issue 를 사용한 전략

나는 개인 프로젝트에서 branch 의 종류 중 main, develop, feature 이 3가지 브랜치를 사용해 프로젝트를 나누고, Issue 탭을 개발할 부분, 개선할 부분, 오류 수정 등을 작성하는 일종의 "노트" 식으로 사용할 생각이다.

main branch
최종 완성(배포)본을 담고 있는 주요 브랜치 (master)
develop branch
전체 개발 작업이 진행되는 중인 브랜치 (main 에서 파생)
feature branch
특정 기능이나 작업을 개발할 별도의 브랜치 (develop 에서 파생)

Branch 의 종류는 ?

main branch : 최종 배포본을 관리하는 주 브랜치

develop branch : 개발이 진행되는 중인 브랜치

feature branch : 특정 기능을 개발하는 별도의 브랜치

release branch : 배포 전 테스트 및 마무리 작업을 위한 브랜치

hotfix branch : 긴급한 오류나 버그 수정을 위한 브랜치

예를 들어, User 정보에 대한 API를 구축할 때는 develop 브랜치에서 feature 브랜치를 파생해서 해당 API를 구축하고 구축이 완료되면 develop 브랜치로 merge 하고, develop 브랜치에서 모든 작업이 완료되면 develop 브랜치의 내용을 main 으로 merge 해서 최종 완성(배포)본을 보여줄 생각이다.

흐름은 아래 사진과 같다.

즉, main 브랜치에서 개발을 위한 develop 브랜치를 파생시키고 feature 브랜치에서 기능별 개발을 진행 후 develop 으로 merge 하는 흐름이다.

Flow 적용

이제 위에서 구상한 전략대로 develop 과 feature 를 적용해서 사용해보자!

develop, feature 브랜치 생성

먼저 테스트를 위해 project-test 라는 리포지토리를 만들고 간단하게 README.md 를 생성하여 main 브랜치를 생성했다.

그 다음, 해야할 일은 내가 무엇을 구현할 것인가? 또 어떻게 구현할 것인가를 적어야 한다.
나는 Issue 탭에 내가 새롭게 개발(추가)할 기능에 대해 상세히 기록해 내가 무엇을 개발할 것인지 명시했다.

해당 Issue 는 개발을 위해 생성한 Issue 이므로 feature 라는 Label을 만들어 현재 이슈의 목적을 명시해주고 Submit new issue 를 눌러 새 이슈를 생성해줬다.

이제, develop 브랜치와 특정 기능을 개발할 feature 브랜치를 생성하자.

branch 의 네이밍 규칙은?

정해진 형식은 없지만 main, develop 은 원래 이름 그대로 사용하는 경우가 일반적이고, feature 브랜치는 feature/{issue-number}-{feature-name} 으로 사용하는 경우가 일반적이다.
참고 : https://ej-developer.tistory.com/75

# develop 브랜치 생성
$ git branch develop

# feature/{issue-number}-{feature-name} 생성 및 HEAD 이동
$ git checkout -b feature/1-test

# 현재 branch 확인
$ git branch
  develop
* feature/1-test
  main

feature 에서 develop 으로 merge

현재 feature 브랜치에서 기능을 개발 완료했다고 가정하기 위해
study.txt 파일을 만들고 내가 만들 기능을 작성한 issue 번호를 '#' 태그와 함께 커밋에 넣었다.

$ git add .

# issue 번호와 커밋 연결
$ git commit -m "issue #1 done. closes #1"

Commit 양식은 어떻게 해야할까?

<type>[optional scope]: <description> 형식으로 <type> 은 커밋의 종류를 나타내는 것으로 "feat" (새 기능 추가), "fix" (버그 수정), "docs" (문서 수정) 등을 사용한다. [optional scope] 와 <description> 는 각각 범위를 명시적으로 작성하는 것과 간결한 설명을 나타낸다.
ex) feat: Add new feature
참고 : https://siyoon210.tistory.com/56

git을 통해 issue #{issue-num} done. closes #{issue-num} 으로 커밋하면
git이 해당 이슈번호를 추적해서 자동으로 커밋이 연결되고, close 또는 closes 를 통해서 해당 이슈를 자동으로 닫게하여, 종료 되었음을 알릴 수 있다.

이제 feature 브랜치에서 develop 브랜치로 merge 를 통해 완료된 개별 구현을 병합하자!

# feature 브랜치를 develop 브랜치로 merge를 위해 HEAD 이동
$ git checkout develop

# merge 실행
$ git merge --no-ff feature/1-test

단순히 feature 브랜치의 작업을 develop 으로 merge 하는 fast-forward merge 가 있지만 merge 로그를 남기고 싶으면 --no-ff 옵션을 사용해서 위 사진과 같이 로그를 남길 수 있다.

이제 develop 브랜치를 원격 리포지토리로 push 한 뒤 리포지토리를 확인해보자.

원격 리포지토리로 push
$ git push origin develop

위 사진처럼 "#" 태그에 의해서 해당 issue 번호와 연결되어 링크를 통해 볼 수 있다!

develop 에서 main 으로 merge

이제, develop 브랜치에서 개발이 끝났다고 가정하고 main 브랜치(배포)로 병합 시켜보자!
main 브랜치로의 merge를 위해 HEAD 를 main 으로 옮기면
main 브랜치에서는 feature 브랜치의 작업한 파일이 없어 파일이 나타나지 않지만
develop 브랜치에서 main 브랜치로 merge 시 작업한 파일을 병합시켜서 파일이 나타나게 된다.

# main 브랜치와 병합을 위해 HEAD 이동
$ git checkout main

# merge 실행
$ git merge --no-ff develop

위 사진처럼 feature -> develop -> main 의 merge 로그가 남는다.

해당 main 브랜치를 좀 더 체계적으로 관리하기 위해서는 tag 를 통해 프로젝트의 특정 시점을 식별할 수 있고, develop 에서 main 브랜치로 merge 해 배포한 프로젝트가 오류나 버그가 생겼을 때 이전 버전으로 롤백이 가능하기 때문에 tag 를 생성하고 현재 프로젝트의 버전 정보와 함께 원격 리포지토리로 push 하는게 좋다!

# v1.0.0 태그 생성
$ git tag v1.0.0

# 원격 리포지토리에 tag (버전 정보)와 함께 push
$ git push --tags origin main

main 브랜치에 push 시 생성했던 # 태그를 통해 명시했던 해당 issue 도 자동으로 닫히고
v1.0.0 이라는 tag 정보와 함께 main 브랜치에 저장된다.

issue 에 개발 세부 내용을 자세히 설명하고 커밋과 연결해서 내가 개발한 부분의 내용과 변경사항을 커밋 로그에서 확인할 수 있고, tag 를 통해 개발 단계를 기록하여 특정 시점의 커밋 로그와 비교해서 종합적으로 변경 사항을 확인할 수 있게 구성하였다.