티스토리툴바

Front End

Github로 프로젝트 다루기

Github Repository

Github의 Repository는 원격 코드 저장소이기도 하지만, 개발 프로젝트에 대한 코드와 주요 정보를 공유하는 수단으로써 사용할 수 있다.

Github 리포지토리에 꼭 필요한 파일

  • README.md

    Github의 프로젝트(리포지토리)에 들어가면 가장 먼저 확인할 수 있는 정보. 일종의 소개 페이지로, 마크다운 방식으로 작성하며 어떻게 오픈 소스를 활용할 수 있는지에 대한 상세한 정보를 담는 것이 일반적이다.

  • .gitignore

    Git으로 관리하지 않는 파일 모음. 개인이 따로 관리해야 하는 중요한 secret token이나 다른 동료와 공유할 필요가 없는 설정 파일 등 공유할 필요가 없는 파일을 기록하면 Git이 이를 파악하지 않고 push 대상에도 제외된다.

  • LICENSE

    해당 코드의 라이센스를 표기한다. Github에 public하게 공개되어도 라이센스에 따라 사용유무가 갈릴 수 있기 때문에 사용한다면 라이센스를 잘 확인해야 한다.

프로젝트 관리에 활용 가능한 Github 기능

  • Issue

    말 그대로 프로젝트에 새로운 기능을 제안하거나 버그를 찾아 제보하는 등의 프로젝트 이슈.

  • Milestone

    이정표 역할을 하며, 태스크 카드(Issue)를 그룹화 하는데 사용한다. Milestone에 연결된 태스크 카드(Issue)가 종료되면 Milestone마다 진행 상황이 업데이트 되는 것을 볼 수 있다. 이 기능을 통해 연관된 이슈의 추적과 진행 상황을 한눈에 파악할 수 있는 장점이 있다.

  • Pull Request

    내가 작업한 내용을 중요 branch에 합칠 수 있는지 확인하는 요청. Github에서는 PR에서 커밋한 코드를 따로 선택해 해당 부분에 코멘트를 달 수 있는데, 현장에서도 PR을 보며 코멘트를 남기면서 코드 리뷰를 진행하기도 한다.

  • Project

    Github 내에서 업무 관리를 해줄 수 있게 돕는 새로운 기능. 칸반 보드를 생성하고 칸반으로 업무 르흠을 관리할 수 있다. 🤝칸반(Kanban)

Git branch

브랜칭(branching)은 기존 개발중인 메인 개발 코드를 그대로 복사해 새로운 기능 개발을 메인 개발 코드를 건드리지 않고 할 수 있는 버전 관리 기법이다. 처음 Git 리포지토리를 생성하면 나오는 main 브랜치에서만 작업을 하다가 새로운 기능 개발을 위해 feature 브랜치를 새로 생성한다면, 기존 main 브랜치에서의 작업은 유지하고 새로운 feature 브랜치에서 자유롭게 코드를 추가 및 삭제할 수 있다.

브랜치 생성 / 변경 (git switch)

Git이 바라보는 곳을 HEAD라 하는데, HEAD를 변경하는 작업을 switch라고 부른다. 

# feature라는 브랜치를 새로 생성하는 경우, -c를 붙인다.
git switch -c feature

# checkout이라는 명령어도 사용할 수 있다.
git checkout -b feature

# 기존에 있던 main 브랜치로 HEAD를 변경하려면, -c를 붙이지 않는다.
git switch main
git checkout main

브랜치 병합 (git merge)

기능 개발이 끝나면 브랜치를 main 브랜치와 합칠 수 있다.

# 기능 개발이 진행되었다면
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"
# 머지를 위해 main 브랜치로 전환
git switch main
# main 브랜치로 feat/todo 브랜치를 병함
git merge feat/todo

실제 프로젝트 개발 시에는 브랜치를 로컬에서 합치기 보다 Github의 PR 기능을 이용해 변경 내역을 충분히 확인하고 난 다음에 merge하는 경우가 더 많기 때문에 로컬에서 머지하지 않고 feature 브랜치를 push하여 PR하는 것이 권장된다.

# 기능 개발이 진행되었다면
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"
# Github 리포지토리로 푸시
git push origin feat/todo
# Github에서 Pull Request 진행

브랜치 삭제(git branch -d)

머지된 feature 브랜치는 이미 dev 브랜치에 기록이 완벽히 남아있기 때문에 굳이 남겨둘 이유가 없어 삭제를 권장한다. 원격 리포지토리에서 PR이 성공적으로 마무리되면, 브랜치를 삭제하는 버튼을 눌러 쉽게 삭제할 수 있다.

로컬 리포지토리에서의 브랜치 삭제는 아래의 명령어로 할 수 있다. 

git branch -d <브랜치명>

Git은 원활한 버전 관리를 위해 브랜치가 합쳐지지 않으면 삭제하지 못하도록 설정되어 있는데, 종종 다 만들지 못한 기능의 기록을 삭제해야 하는 경우도 발생한다. 이 때는 -D 옵션을 쓰면 삭제가 가능하다. 단, 머지되지 않은 브랜치 삭제는 버전 기록 시스템과 잘 맞지 않기 때문에 잘못 만든 기능이라도 돌아갈 여지를 만들어두는게 좋을 수도 있다. 이 경우 팀 및 회사 정책을 따르는 것이 좋다.

Git flow

Git flow는 많은 개발자의 사랑을 받아온 Git 브랜칭 전략이다. 대규모 개발 프로젝트를 제작해 하나의 소프트웨어 릴리즈 버전을 명확하게 나누고 다양한 버전을 배포해야 하는 개발 환경에는 적합하지만, 빠르게 제작하고 배포하고 고객의 피드백을 받는 애자일한 개발 팀에 적용하기에는 다소 복잡하다. Git flow가 시작된 Vincent Driessen의 블로그 원문에서도 아래와 같은 조언이 담겨있다. 이 조언처럼 주어지는 개발 현장의 상황에 맞게 Git flow를 정하는 것이 중요하다.

웹 애플리케이션은 대개 보통 지속적으로 배포되고, 배포를 되돌일 일이 없다. 또한 여러 버전을 배포하지 않아도 된다.

이런 소프트웨어(웹 애플리케이션)는 내가 2010년 작성했던 블로그에서 생각했던 타입의 소프트웨어가 아니다. 당신의 팀이 지속적 배포를 원한다면, Github flow와 같은 간단한 워크플로우 도입을 제안한다. 굳이 애써 git-flow를 우겨넣지 않아도 된다.

만약 당신의 소프트웨어가 엄격한 버저닝이 필요하고, 여러 버전을 배포해야 하는 경우에는 git-flow는 당신의 팀에 잘 맞을 수 있고, 계속 읽어주길 바란다.

Coz’ Git flow

원조격에 해당되는 Git flow에서 파생된 여러 Git flow도 있는데, 대표적으로 Github flow, Gitlab flow가 있다. 그 중 Coz’ Git flow는 Git flow를 단순화한 전략으로, 핵심 브랜치와 보조 브랜치로 나누어 관리하는 방식이다.

  • 핵심 브랜치(main / dev)

    Github 리포지토리에 늘 업데이터 되어있어야 하며, 팀원의 코드 리뷰를 받고 진행하는 것이 정석이다. 엄밀한 코드 리뷰가 어렵다면 같이 모여 코드에 대해 이야기를 나누고 배포 상황을 점검하는 스탠드업 회의를 열 수도 있다. 격식이 필요하진 않지만, 가능하면 모든 팀원이 확인 가능하게 개선이 필요한 코드에 코멘트를 Github PR에 남기는 것이 권장된다.

핵심 브랜치: main

사용자에게 언제든 제품으로 출시할 수 있는 브랜치

사용자에게 언제든 배포할 수 있는 브랜치로, 회사에 따라 master, prod, production 등 다양하게 불린다. ‘언제든 배포한다’ 는 의미 역시 회사나 팀 별로 다를 수 있지만, 최소한의 기준은 다음과 같다 볼 수 있다.

  • 대표적인 기능의 완성됨
  • 기존 기획한 레이아웃과 전체적인 디자인이 대략 완성됨
  • 클라이언트, 서버, 데이터베이스가 공개된 웹에서 정상 통신 가능함
  • 최소한의 보안이 마련됨
    • 브라우저에서 개발 버전에서 사용하던 secret이나 유저의 비밀번호가 노출되는가?
    • 유저의 기밀 정보 조회를 위한 인증 토큰, 세션이 꼭 필요한가?

핵심 브랜치: dev

다음 버전 배포를 위한 개발 브랜치

다음 버전 배포를 위한 개발 브랜치로, 보통 main 브랜치에서부터 브랜칭을 한다. 가능하면 프로젝트 팀원과 프론트엔드/백엔드의 결과를 합쳐서 확인해볼 수 있을 정도로 준비되어야 한다. CI/CD 파이프라인이 잘 구축되어 있다면 dev 브랜치의 코드도 배포를 해두고 수시로 확인할 수 있다.

보조 브랜치 : feature

기능 개발, 리팩토링, 문서 작업, 단순 오류 수정 등 다양한 작업을 기록하기 위한 브랜치로, 분류를 세세하게 나누기를 원하는 회사에서는 refactor, fix, docs, chore와 같이 세세하게 커밋 메세지나 브랜치 명에 prefix를 달기도 한다. 많은 경우 feature 브랜치는 머지 후 삭제를 하지만, 복원 필요성이 있는 경우 남겨두기도 한다.

보통 각 개인의 로컬 리포지토리에서 만들고 작업하며, 기능 개발을 위한 브랜치이므로 2명 이상 같이 작업하는 경우가 드물어 브랜치 생성이나 삭제에 대해 크게 두려워 할 필요는 없다. 작은 기능이라도 브랜치를 새로 만들고, 자주 커밋하고, 자주 원격 Github 리포지토리에 push하여 팀원들과 결과를 공유하는 것이 바람직하다. 개인 로컬 리포지토리에서 너무 오래 작업하면 쉽게 발견할 수 있는 오류도 발견되지 않을 수 있기 때문에, 더 나은 코드를 위한 피드백을 받는 방법을 택하는 것이다.

Git 작업 중 문제 발생 시 Flow Chart


Uploaded by N2T

티스토리툴바