Git Project flow
💡 작업 시 주의 사항
- 실질적인 코드 작업은 Dev Branch가 아닌 Feature Branch에서 진행된다.
Dev Branch는 만약을 위한 백업용 Branch 이다- merge한 후에는 동일한 파일에서 코드수정을 하지 않는다
Project Git Flow
(1) 개발 할 master 레파지토리를 fork하여 복사해온다
//일반적으로 master repositories를 upstream이라고 부른다
(2) 복사해온 레파지토리를 git clone 으로 local에 가져온다
(3) master 레파지토리와 local을 연결한다
pull 명령을 통해 local의 dev Branch를 최신화 한다
(4) 최신화 된 코드베이스로 새로운 기능을 개발할
feature Branch를 만든다
git switch -c _______Branch________
(5) 기능개발이 끝나면 해당 Branch를 본인의 프로젝트
repositories에 Feature Branch에 push한다
git add .
git commit -m "커밋메세지 규칙에 맞추어 작성"
git push origin ______branch_______
(6) 해당 Branch를 프로젝트 master Branch로 Pull Request를 보낸다
(7) 코드를 확인한 뒤 merge하고 local의 dev에서 git pull (local 최신화)한다
(8)origin의 dev브랜치에 최신화된 local의 dev브랜치를 push한다. (origin dev 최신화)
(9) 모든 과정이 끝나면 dev -> master로 merge (프로젝트 마무리)
블로그를 참고하며 정리 한 내용
GitHub는 Git을 바탕으로 하는 코드 호스팅 플랫폼이다
네트워크상의 서버에 있는 저장소를 remote repository라고 하며, 이 remote에 있는 저장소를 git clone하면 local repository가 된다
-
타인의 repository를 복사하게 된다면,
원래 소유자의 remote repository와 내가 fork한 remote repository 사이에도 upstream과 downstream이라는 관계가 형성된다 -
기존 소유자의 remote를
upstream
내가 fork한 remote를origin이라는 용어를 사용하곤 한다.
참고자료
금일부터 시작되는 first project를 준비하는 과정에서
Dev 최신화 과정부터 최종 merge하는 과정까지 이론상으로 배우게 되었다.
upstream이라는 용어를 처음 만나게되어 검색해보았다가 새로운 내용도 추가적으로 알게 되었다.
후에 프로젝트 팀원분과 레파지토리 생성 후 플로우에 맞추어 연습해보며 익숙해지는 시간을 가졌다.
이전에 연습과정으로 팀원들과 진행할 때와 다르게 규칙에 대해서도 다시 배울 수 있는 좋은 시간이였다.
위 과정으로 각자 개발하는 기능이 다르기 때문에 서로 충돌하지 않으면서 최신화 버전을 유지한다는 걸 알게 되었다
앞으로 (최대한) 실수하지 않고 프로젝트를 마무리 하고싶다!
