fork에서 시작해서 PR을 보낼때까지의 흐름
- fork를 하여 나의 저장소로 프로젝트를 가져온다. 이 때, fork한 저장소는 원본 저장소와 연결되어 있다.
- fork한 프로젝트를 자신의 컴퓨터로 clone한다. 이 때, single-branch 옵션을 주어 특정 브랜치만 가져올 수 있다.
- 자신의 컴퓨터에서 수정 후 commit을 한다.
- push를 하여 자신의 원격 저장소에 올린다.
- push완료 후 자신의 github저장소에서 Pull Request를 보낸다.
- PR을 받은 관리자는 코드 변경내역을 확인하고 Merge여부를 결정하게 된다.
git add와 commit
git add 명령어로 commit할 파일들을 올려놓는 가상 영역인 staging area에 작업한 특정 파일을 올릴 수 있다.
git commit 명령어로 로컬 저장소의 현재 브랜치의 staging 영역에 변경 내용을 반영한 commit을 올릴 수 있다.
git push 명령어로 로컬 저장소의 변경 내용을 원격 저장소로 보낼 수 있다.
branch&Pull Request를 사용하는 이유
- 여러 명이 협업을 하여 프로젝트를 개발할 때는 서로 충돌이 발생할 수 있고, 프로젝트가 커질수록 기능이나 버전 관리의 어려움이 있다.
- 원본 저장소에 대한 권한은 마스터만 가지고, 브랜치를 나눠서 작업한다.
- 작업 후 PR하면 바로 원본 저장소에 적용되지 않는다. 마스터는 이 PR한 내용들 중 필요한 내용들만 merge해서 프로젝트에 반영시킬 수 있다.
Git Workflow 전략의 필요성
- 프로젝트를 버전별로 관리할 수 있다.
- 개발작업 히스토리를 커밋 로그를 활용해서 한눈에 보기 쉽다.
- 버그가 발생했을 때 대응이 더 쉽다. 개발중인 기능들에 영향을 주지 않고 현재 배포버전에서 hotfix 브랜치를 따서 긴급대응하는게 용이하다.