혼자 깃을 쓸 때는 master에 푸쉬를 했었다
협업은 master에 푸쉬를 하는 것이 아니다
먼저, 개발과 배포를 위한 branch를 만든다
배포를 위한 branch가 Master
개발을 위한 branch가 develop => 이것의 우리의 master branch
<명령어>
git branch 하면 브렌치 확인가능 => 초록색 확인
git checkout -b 이름
: 없는 브렌치를 만들어서 이동가능
git checkout 이름
: 브렌치로 이동
develope에서 작업을 하다가 master로 merge해야 한다
master를 초록색으로 만들고 yarn start해야 배포
협업한다
게시판 담당자가 바로 develope에서 만드는 것이아니다
feture 브렌치를 만들고 그 내용을 develope에 추가하는 것이다
각각의 기능에 대한 브렌치를 만들어서 develope에 합친다
개발이 마무리 되면
release 브렌치를 만들어서 오류를 잡는다
버그가 없으면 master로 머지하고 master를 배포한다
미처 발견하지 못했던 버그가 있다면 hotfixes 브렌치에서 버그를 수정한다
<<순서>>
회사 레파지토리 master branch에 초기 보일러 플레이트를 푸쉬해놓는다
팀원 모두 이 레파지토리에 직접 푸쉬하지 않는다.
팀원들은 자신의 깃허브 계정에 회사레파지토리를 포크한다 (forking repository 방식)
팀원들은 각자 자신의 레파지토리에 있는 것을 clone한다
팀원들은 각자 맡은 기능을 feature 브렌치 내에서 개발한다.
이 때, 각자 서로 다른 기능을 개발해야한다
같은 파일을 개발하고 있으면 하나로 합칠 수가 없다
개발 완료 후 자신의 레파지토리에 push한다
master에 있는 것도 develop으로해놓고
팀원 각각은 develop 브렌치에 pull request를 보낸다
이후 코드 리뷰 시간에 다 같이 확인한다
문제가 없는 것은 merge 하면 develop 브렌치에 추가되는 것
문제가 되는 것은 reject 하면 pull request가 취소된다
업데이트가 된 dev 원본 (Upstream)을 pull 해야 한다
🔥 push는 origin
🔥 pull은 upstream
주의사항!
1. 같은 기능을 두 명 이상 같이 개발해서는 안된다
2. 하루에 2번 이상 PR을 날릴 때, 각 PR이 의존하면 안됨 (하나의 기능을 제대로 만들어서 PR을 보내거나, 아예 다른 기능, 다른 컴포넌트를 보내자)
3. 가급적 1일 1커밋(PR)
4. 공통기능, 공통컴포넌트 (잘만들어야함)
실습하기
공용레파지토리를 포크한다
내 레파지토리에 와서 git 주소 복사 후
내 로컬에 git clone git주소 하여 파일을 받아온다
develop 브렌치로 전환하기
이슈에 내 할일 정리하기
내 할일 번호에 맞게 브렌치 따기
잠깐) 브렌치를 따는 위치에 따라 폴더, 파일 내용이 달라질 수 있다!!! feature-#1에서 myboards를 만들었다면...브렌치를 따아먄 myboard가 있다
항상 최신화되는 develop에서 브렌치를 따야하는 것이 좋다
다시 upstream을 연결하고
자신의 브렌치에 push 한다
file changed 에서 파일 확인하고
merged
upstream이 업뎃되었따
최신 upstream으로 받아 새로운 폴더, 파일이 생긴다
