바이브코딩

이슈만들기부터 릴리즈까지 깃허브 실전편

브랜치에서 작업 후 PR로 검수 요청하고, 문제 없으면 메인에 머지한 뒤 릴리즈로 버전을 공식 기록한다.

3줄 요약

  • 이슈(issue)로 할 일을 기록하고, 브랜치에서 작업한 뒤 push하면 PR을 만들 수 있다.
  • PR은 메인에 합치기 전 검수 단계이고, 문제 없으면 머지 후 브랜치를 삭제한다.
  • 릴리즈는 완성된 버전을 v1.0.0처럼 공식으로 기록해두는 것이다.

push까지 성공했는데 그 다음은 뭘 해야할 지 갑자기 막막해진다. 브랜치는 왜 만드는지, PR은 어떻게 요청하는거고, 머지하고 어떻게 해야하는지, PR 배너도 사라지고, 하나씩 진행하다 보면 막히는 게 생긴다. 직접 진행하면서 정리한 이슈만들기부터 릴리즈까지 끝까지 할 수 있도록 도와주겠다.

이슈(Issue) 만들기

먼저 어떤 기능을 추가해야 하는지 텍스트로 기입해두는 게 중요하다. 메모장에 따로 적어둘 수 있지만 해당 메인 파일에 적어둬야 바로 알 수 있다. 깃허브에서 메모를 할 수 있는 곳이 Issue이다. 처음엔 간단하게 한 줄만 적어도 된다. 팀으로 일하게 되면 그때 체크리스트, 스크린샷 등 상세하게 작성하면 된다.

  1. 상단 Issue 클릭
  2. 이슈 제목 및 내용 입력 후 생성 버튼 클릭
  3. Issue 탭에서 생성한 이슈 확정

브랜치(Branch) 만들기

수정해야 할 내용을 이슈에 입력하고 나서 수정을 진행해야 한다. 앞서 메인 자체를 바로 수정하는 건 리스크가 있을 수 있다고 했기에 복제본인 브랜치를 먼저 만들어서 작업을 시작한다. 예전에는 터미널에 명령어로 checkout을 썼는데 지금은branch/switch를 쓴다. 찾아보면 checkout이 많이 나오는데 같은 기능이라고 보면 된다. 브랜치이름은 영어 소문자로 생성해야 한다.

  1. git branch 브랜치이름 (해당 브랜치 생성)
  2. git switch 브랜치이름 (해당 브랜치로 이동)
  3. git switch -c 브랜치이름 (해당 브랜치 생성 후 이동)
  4. git push origin 브랜치이름 (깃허브 저장소로 올리기)
  5. 생성된 브랜치 확인

git switch -c 브랜치이름 명령어로 하면 생성부터 브랜치 이동까지 한 번에 할 수 있다. 해당 명령어를 적어도 가능하고 클로드코드에 브랜치생성 해달라고 직접 요청해도 가능하다. ai에 생성해 달라고 하면 브랜치이름도 자동으로 같이 만들어준다. 브랜치를 만들었다고 해서 바로 올라가지는 않는다. 로컬 저장소에 만들어진 상태이고 다시 깃허브로 push를 해야한다.

Pull Request

git push를 하고 깃허브 레포 메인으로 가면 노란 배너가 뜨는 경우가 있다. 배너가 보이면 클릭해서 PR을 만들 수 있다. Pull Request인데, 당겨지기를 요청한다는거다. 즉, 자신이 만든 파일이 메인 코드로 합쳐지기를 요구하는 것이다. 그런데 배너가 사라진 경우 두 가지 방법이 있다. AI에 PR을 만들어달라고 요청하거나, 깃허브에서 직접 Pull requests 탭 → New pull request 버튼으로 만들 수 있다.

혼자할 경우 테스트하고 PR을 바로 넘어갈 수 있겠지만 팀 협업으로 넘어가면 제대로 검수를 해야한다. 잘못된 브랜치 코드 하나가 메인에 합쳐지면 전부 문제가 생길 수 있기 때문이다. 그래서 PR을 두고 검수를 먼저 한다.

직접 PR 만들기

  1. 깃허브 메인 레포 Pull requests
  2. 브랜치 선택 후 Create pull request
  3. Create pull request , PR 생성 완료

AI로 PR 만들기

  1. PR 생성 요청 (AI가 물어보는 경우가 많음)
  2. 깃허브 브랜치로 확인 (또는 링크 클릭)
  3. Development → 생성한 이슈 선택

Merge

브랜치로 만든 코드가 이상이 없을 경우 메인으로 합친다. 합치고 나서 나중에 헷갈릴 수 있기에 생성한 브랜치를 없애는 경우가 많다. 간혹 작업한 브랜치와 메인 코드가 충돌 할 수 있는데 그때에는 충돌을 해결하고 메인과 합치는 작업을 해야한다. 그리고 만든 issue를 수동으로 없애는 게 아니라 PR로 연결해두면 자동으로 완료 시킬 수도 있다. closes #이슈번호를 입력해두면 머지할 때 해당 이슈가 자동으로 닫힌다.

  1. Merge pull request
  2. Delete branch
  3. Issue에서 생성한 이슈 close로 변경
  4. (옵션) 메인과 충돌 시 해결 후 진행

Release

머지까지 완료 되었다면 이제 버전을 공식으로 기록하는 차례다. 사용자에게 만든 코드를 내보내는 단계(릴리즈)만 남았다. 어플이나 프로그램 보면 버전 1.2 업데이트 같이 본 경우가 많을텐데 그 때 버전 변경 등에 대해서 사용자가 확인하는 부분이 릴리즈가 된 파일이라고 보면 되겠다.

  1. 저장소 릴리즈 선택
  2. 태그 선택 (보통 버전을 넣는 경우가 많음. v1.0.0)
  3. 릴리즈 타이틀 선택 (예. v1.0.0 LMS 첫 번째 릴리즈)
  4. Generate release notes 클릭 (머지한 내용 추가)
  5. Publish release

첫번째 릴리즈를 확인할 수 있다. 아래 소스코드로 알집 파일을 내려 받을 수 있다.

다음에는 팀 협업을 어떻게 깃허브로 할 수 있는지 확인해보겠다.

관련글

팀원 초대부터 코드 리뷰까지 깃허브 협업편

클로드코드 하나로 끝내는 깃허브 Push

왕초보도 바로 이해하고 시작하는 깃허브
꼭 알아야 할 용어
이슈(Issue)
정의 깃허브에서 수정하거나 추가해야 할 내용을 기록해두는 곳
쉽게 말하면 코드 작업 전에 적어두는 메모
브랜치(Branch)
정의 메인 코드를 기반으로 만든 독립적인 작업 공간
쉽게 말하면 원본은 그대로 두고 복사본을 만드는것
PR(Pull Request)
정의 브랜치에서 작업한 코드를 메인에 합쳐달라는 요청
쉽게 말하면 내가 수정한 내용 검토 해달라고 올리는 것
머지(Merge)
정의 PR이 승인된 후 브랜치를 메인에 합치는 작업
쉽게 말하면 검토 완료된 복사본을 원본에 반영하는 것
충돌(Conflict)
정의 브랜치와 메인이 같은 파일을 동시에 수정했을 때 발생하는 오류
쉽게 말하면 같은 파일을 동시에 고치면 생기는 오류
릴리즈(Release)
정의 완성된 버전에 태그를 붙여 공식으로 기록해두는 것
쉽게 말하면 앱 업데이트할 때 보이는 "버전 1.2 업데이트" 같은 것