(사진 출처 : https://techblog.woowahan.com)
이제 더이상 master(=main)에서만 작업하지 말자!!
브랜치 이름은 반드시 정해져있는건 아니지만 실무에서 통상적으로 이렇게 나눠서 쓴다.
-
develop(=dev)
개발시 메인이 되는 브랜치 -
feature
세부 기능을 구현할 때
- develop에서만 개발하지 않고 기능별로 feature 브랜치를 생성→develop에 merge (ex: 게시판 목록 브랜치 생성 후 이동
git checkout -b feature-boards) - git issue에서 어떤 기능을 구현할지 적고 그 이슈번호를 feature에 적으면 구분하기 쉽다.
(ex: 이슈 번호가 20번->git checkout -b feature-#21
- master
개발이 끝나고 배포할 때 - release
기능 구현이 끝나고 버그만 잡을 때 이용
develop에서 release로 브랜치 이동한 뒤 디버깅이 끝나면 master로 합치기 - hotfixes
배포 후 생각지 못한 긴급 버그가 발생했을 때 이용
hotfixes 브랜치에서 디버깅→다시 master로 합치기
브랜치 명령어
브랜치 이동
git checkout 이미있는브랜치이름
브랜치 생성하고 그 브랜치로 이동
git checkout -b develop
(예시: develop 브랜치로 이동)
모든 브랜치와 현재 위치해있는 브랜치 확인
git branch
브랜치 삭제
git branch -D 삭제할브랜치이름
팀에서의 git 프로세스
-
팀장은 팀 레파지토리 master에 초기 보일러플레이트를 push하고 develop으로 옮기기
(이 때, 개인은 팀 레파지토리에 접근할 수 없도록) -
팀원은 팀 레파지토리를 fork 하고 git clone한다.
-
remote 등록하기
git remote add upstream 팀레파지토리주소 -
팀원들은 각자 다른 기능을 맡아 서로 다른 파일에서 작업한 뒤 push한다.
이때 develop 내용을 따와서 feature에서 작업해야 한다.
같은 파일을 두 명이상 작업하고 있으면 안된다.
- develop에서
git checkout -b feature-#이슈번호 git add .git commit -m "커밋 메세지"git push origin feature-#이슈번호
- 팀 레파지토리에 pull request를 보낸다. 이후 코드확인 뒤 팀장이 merge (다같이 확인 후 merge 예정!)
- 각 팀원들은 각 기능 구현이 완료된 코드를 받은 뒤 작업한다.
팀 develop 코드를 받아오기git pull upstream develop
이때 본인의 develop(또는 master)에서 받아와야 한다.
주의점
- 같은 기능을 두 명 이상 같이 개발하면 안됨 (merge시 충돌 위험성이 있음)
- 하루에 두번이상 Pull Request(PR)날릴 때 각 PR이 의존되면 안됨
- 가급적 최소 1일 1 PR하기
- 공통기능은 한명이 맡고 잘 구현되어야 함 (예: 로그인)
개발 공부한 걸 올립니다