기록 11 . 깃허브 플로우(Github Flow)

지피티랑 이야기해서 일단 플로우를 정리해둔다.

 

1 .먼저 작업 중이던 거 있으면 최소 여기까지는 해 두기.

# 지금 작업중-branch 위에서
git status          # 뭐가 변경됐는지 확인
git add .           # 바뀐 거 모두 올리고
git commit -m "WIP: 진행 중 작업"   # 임시 커밋이라도 하나 남겨두기

 

0. 전체 작업 흐름 (한 사이클 요약)

1. 로컬 main 기준 최신화
2. main에서 작업용 브랜치 생성 (a-branch)
3. 브랜치에서 작업 → 커밋 → 원격으로 푸시
4. (필요 시) 작업 도중 main 변경분을 rebase로 가져오기
5. GitHub에서 PR 생성 → 리뷰 → main에 머지
6. 머지 후 브랜치 정리 (로컬/원격 브랜치 삭제)

이제 시작!

2. main 최신화

항상 새로운 작업을 시작하기 전,
그리고 rebase 하기 전에는 무조건 main을 최신으로 맞추고 시작.

설명

1. main 브랜치로 이동
2. 원격(origin/main)에서 최신 내용 가져오기

# 1) main으로 이동
git switch main

# 2) 원격 main 가져오기 + 병합
git pull origin main

 

 

 

3. 작업 브랜치 만들기 (a-branch)

설명

• 항상 main에서 새 브랜치를 딴다.(기존에 브랜치가 작업중인사람은 기존브랜치로 돌아간다 그냥  아래부분 패스!!!
• 돌아갈경우 (git switch "원래브랜치명")
• 브랜치 이름은 작업 내용을 담게 짓는 게 좋음.
  • 예: feature/a-login, fix/a-bug-123 (우리는 일단 "이름(닉네임)-branch" 로 작업예정)

# main 최신 상태에서 새 브랜치 생성 + 이동
git switch -c a-branch
# 또는
git checkout -b a-branch

 

 

 

4. 브랜치에서 작업 / 커밋 / 원격 푸시

설명

1. 코드 변경
2. 변경 파일 스테이징
3. 커밋
4. 원격 저장소에 해당 브랜치 푸시

0번에서 이미 커밋했다면 무시 
# 작업 후 변경 내용 확인
git status

0번에서 이미 커밋했다면 무시 
# 변경 파일 스테이징
git add .

0번에서 이미 커밋했다면 무시 
# 커밋
git commit -m "feat: 로그인 화면 구현"

# 최초 1회: 원격 브랜치 생성 + 연결
git push -u origin a-branch

# 그 다음부터는
git push

 

 

5. 작업 도중 main이 변경되었을 때: rebase로 따라잡기

팀원들이 먼저 PR을 머지해서 main이 앞서나가면,
내 브랜치(a-branch)를 최신 main에 rebase 해서
충돌을 미리 해결하고, 기록도 깔끔하게 유지한다.

설명 – 아침 루틴/작업 전 루틴 예시

1. 원격 정보 가져오기 (fetch)
2. 로컬 main 최신화 (위에서 한 것과 같은 절차)
3. 다시 작업 브랜치로 이동
4. origin/main 기준으로 rebase
5. 충돌 나면 해결 후 rebase 계속
6. rebase 한 뒤에는 force-push(with-lease) 로 원격 브랜치 갱신

명령어 (브랜치: a-branch)

# 0) 원격 변경 내역 가져오기
git fetch origin

# 1) main 최신화
git switch main
git pull origin main

# 2) 작업 브랜치로 복귀
git switch a-branch

# 3) 최신 main 위로 rebase
git rebase origin/main

 

충돌나면

# 충돌 파일 수정 후
git add <충돌_해결한_파일들>

# rebase 계속 진행
git rebase --continue

rebase 후 원격 브랜치 업데이트

# rebase로 커밋 히스토리가 바뀌었으므로 강제 푸시 (with-lease 권장)
git push --force-with-lease origin a-branch

6. PR 생성 → main에 머지

이 부분은 GitHub UI에서 진행.

1. GitHub에서 a-branch 페이지로 이동
2. “New pull request” 클릭
3. base: main, compare: a-branch 확인
4. PR 제목/설명 작성 → 생성
5. 코드 리뷰 → 승인
6. Merge 방식: 보통 Squash and merge 또는 Rebase and merge 사용
   • 팀 규칙 하나 정해서 그대로 쓰면 된다.

(이 단계는 CLI 명령어보다는 웹에서 처리하는 게 일반적이라 설명만.)

이제 킷 정리할때 뒤쳐진 메인을 위로 끌어올리기

 

git switch main
git pull origin main      # main 최신화​

다시 풀리퀘스트 바로아래있는 조금전의 Push건을 최신으로 끌어올리기위한 리베이스.

 

git switch a-branch
git rebase main           # 최신 main 위에 내 커밋들 다시 쌓기
git push --force-with-lease origin a-branch  # 브랜치에 변화가 없는지 체크한후 합치기 
#나의경우 브랜치를 나혼자만 사용할 계획이므로 상관없지만..

 

 

7. 머지 후 브랜치 정리(이건 개인브랜치를 계속 사용할경우 무시, 기능별로 새로 브랜치를 만드는 경우만 해당 )

PR이 main에 머지되었다면:

1. 로컬 main을 다시 최신으로 맞추고
2. 더 이상 필요 없는 브랜치는 삭제한다.

설명

• main 기준을 항상 깨끗하게 유지
• 사용이 끝난 브랜치는 로컬 + 원격 둘 다 삭제해서 리스트 정리

명령어

# 1) main 최신화
git switch main
git pull origin main

# 2) 로컬 브랜치 삭제
git branch -d a-branch

# 3) 원격 브랜치 삭제
git push origin --delete a-branch