Git 협업 워크 플로우

Feature Branche 워크 플로우 

• 메인 아이디어 : 중앙 집중형 워크플로우처럼 마스터 브랜치에서만 작업하지 말고, feature(신규 기능, 버그 수정, 최적화, ..)마다 브랜치를 만들어서 작업하라.
• 특정 feature 브랜치에서 수행할 작업이 모두 끝나면 마스터 브랜치에 merge하면 된다.
• 이후엔 해당 feature 브랜치는 삭제하는게 좋다.
• 마스터 브랜치를 최종 배포판으로 만드는 효과가 있다.

cf)feature branch에서 끝난 작업을 master branch로 옮길 때는 master에서 feature branch를 merge한다음 push해야 한다. 하지만 이를 축약해주는 pull request(PR)가 있다.

 

pull request(PR) 

• 이를 통해 master branch에 합치려고 하면 코드 리뷰 과정을 무조건 거쳐야 한다.
• 주의할 점으로는 원격 저장소에 저장되어 있는 커밋들에 대해서만 mege가 이뤄진다.
• PR은 깃허브에서 동작하기 때문에 깃허브에서 처리해줘야 한다.

PR 충돌 해결

• 로컬 환경에서 충돌을 발생하게 한 브랜치에서 타겟 브랜치를 merge를 시킨다. 예를 들어 feature1에서 master로 pr을 했을 때 충돌이 발생했다면 feature1에서 master를 merge한 다음 충돌을 해결해주면 된다. 이후 master 브랜치에서 feature1을 merge한 다음 push하면 자동으로 PR 충돌이 해결되고 PR이 이루어진다.
• 전체 과정은 다음과 같다.

git merge master (feature1)
--fix conflicts--
git switch master (master)
git merge featur1 (master)
git push origin master (master)

 

---

 

Fork & Clone 워크플로우

• 하나의 프로젝트에 대해 모든 개발자가 각자 깃허브에 해당 프로젝트 저장소의 복사본을 가지는 워크플로우이다.
• 코드 기여자가 수천, 수만에 이르는 대형 오픈소스 프로젝트 같은 프로젝트에 어울린다. 모두를 초대할 수 없기 때문이다.
• 여기서 fork는 깃허브 저장소를 복사해서 내 깃허브 계정에 복사본 저장소를 만드는 행위를 말한다.
• 기존에 푸쉬할 수 있는 권한이 없는 상태에서 탈피할 수 있다.
• 작업한 내역을 원본 저장소에 PR을 날릴 수 있다.
• 원본 저장소에서 변경이 발생했을 때 복사본 저장소에 pull을 할 수 있다. git remote add original <원본 저장소 url>을 통해서 로컬 환경을 구축할 수 있다. 이때도 마찬가지로 권한이 없는 이상 원본 저장소엔 push 할 수 없다.