GitHub - Git branch

1. 브랜칭(branching)

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

 

2. Git branch

 1) main 브랜치

• main 브랜치는 사용자에게 언제든 배포할 수 있으며, 사용자에게 언제든 제품으로 출시할 수 있는 브랜치이다
• 회사에 따라서 master, prod, production 등으로 사용하기도 한다
• 일정 기준을 충족했고, 핵심 기능이 완성되었으면 main 브랜치로 배포할 수 있다
  - 대표적인 기능이 완성되어 있다
  - 기존 기획했던 레이아웃이나 전체적인 디자인이 대부분 완성되어 있다
  - 클라이언트, 서버, 데이터베이스가 공개된 웹에서 정상적으로 통신할 수 있다
  - 최소한의 보안이 마련되어 있다
   : 브라우저에서 개발 버전에서 사용하던 secret이나 유저의 비밀번호가 노출되지 않도록 한다
   : 유저의 기밀 정보 조회를 위해 인증 토큰, 세션이 필요하도록 한다

 

 2) dev 브랜치

• 다음 버전 배포를 위한 개발 중인 브랜치이다
• main 브랜치에서부터 브랜치를 생성한다
• main 브랜치와 dev 브랜치는 Github 리포지토리에 항상 업데이트 되어있어서 팀원의 코드 리뷰를 받고 진행한다
• 가능하면 모든 팀원이 확인 가능하도록 코멘트를 Github Pull Request에 남기는 것을 권장한다

 

 3) 보조 브랜치

• feature 브랜치라고 한다
• feature 브랜치는 기능 개발, 리펙토링, 문서 작업, 단순 오류 수정 등 다양한 작업을 기록하기 위한 브랜치이다
• 분류를 세세하게 나누는 경우에는 refactor, fix, docs, chore와 같이 세세하게 커밋 메시지나 브랜치명에 prefix를 달기도 한다
• 아래는 feature 브랜치 이름과 커밋 메시지의 예시이다

hash (브랜치 명) 커밋 메시지
2f85eea (feat/create-todo) feat: Todo 추가 기능
2ad0805 (fix/var-name) fix: 변수 네이밍 컨벤션에 맞게 변수명 변경 (ismale => isMale)
e7ce3ad (refactor) refactor: 불필요한 for 루프 삭제

• feature 브랜치는 보통 각 개인의 로컬 리포지토리에서 만들고 작업한다
• feature 브랜치는 기능 개발을 위한 브랜치이기 때문에 2명 이상 같이 작업하는 경우가 없다
• 커밋 기록을 남기는 일반적인 rebase-and-merge 와 커밋 기록을 정리하는 squash-and-merge 등의 merge가 있다
• 일반적으로 feature 브랜치는 머지하고 나서 삭제하지만, 복원해야 할 필요성이 있는 경우는 남겨두기도 한다

▶ 커밋 메시지의 예시 : https://www.conventionalcommits.org/ko/v1.0.0/ 

Conventional Commits

 

 

3. 브랜치 생성 및 변경(git switch)

 1) 브랜치 생성

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

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

feature 브랜치로 이동한다
git switch feature

기존에 있던 main 브랜치로 HEAD를 변경 시에는 -c를 붙이지 않는다
git switch main
git checkout main

 

 

4. 브랜치 합치기(git merge)

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

feature 브랜치에서 기능 개발
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의 pull request 기능을 이용하여 변경 내역을 충분히 확인한다
  - 로컬에서 머지하지 않고 feature 브랜치를 push하여 pull request를 요청하는 것이 문제 발생을 감소시킨다

기능 개발이 진행
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"

Github 리포지토리로 푸시
git push origin feat/todo

Github에서 Pull Request 실행

 

5. 브랜치 삭제(git branch -d)

• 머지된 feature 브랜치는 이미 dev 브랜치에 기록이 완벽하게 남아있기 때문에 남겨둘 이유가 없으므로 삭제한다
• 원격 레포지토리에서 pull request가 성공적으로 마무리되면, 아래 스크린샷처럼 브랜치를 삭제하는 버튼을 눌러 쉽게 삭제할 수 있다

• 로컬 리포지토리에서 브랜치 삭제는 git branch -d <브랜치명> 으로 할 수 있다

git branch -d feat/todo

• Git은 버전 관리를 위해서 브랜치가 합쳐지지 않으면 삭제하지 못 하도록 설정되어 있다
  - 미완성 기록을 삭제하고 싶을 경우에 -D 옵션을 쓰면 삭제할 수 있다
  - 머지되지 않은 브랜치 삭제는 버전 기록 시스템의 사용 목적과는 맞지 않는다
  - 미완성 기록이라도 해당 기능으로 돌아가야 할 수도 있으므로 남겨두는 것을 권장한다

git branch -D feat/todo

 

6. Git 문제 발생 대처안

 

 

7. Git Error  대처방법

 1) reject error

•  ! [rejected]        master -> master (non-fast-forward))
• git push 또는 git push origin main 등의 명령을 실행해도 reject를 동반한 에러가 발생할 경우 대처 방법이다

 ! [rejected]        master -> master (non-fast-forward)

push 하고져 하는 디렉토리에서

git init 
로 초기화 한 후
git remote add origin {git push 주소}
로 다시 연결을 진행한다
다시
git push 또는 git push origin main
을 하여도 에러가 발생한다면...

git push origin +main
처럼 main 앞에 '+'를 붙여서 진행한다