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
커밋 메세지에 사용자와 기계 모두가 이해할 수 있는 의미를 부여하기 위한 스펙
www.conventionalcommits.org
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 앞에 '+'를 붙여서 진행한다'Git' 카테고리의 다른 글
| Git - 명령어 / HELP (0) | 2022.08.01 |
|---|---|
| GitHub (0) | 2022.07.10 |
| Git(global information tracker) (0) | 2022.07.10 |
