근황
요즘 Chingu 프로그램을 통해 팀을 구해서 팀 프로젝트를 진행중이다.
나, 한국인 친구, 베트남 친구 이렇게 3명의 프론트엔드 개발자들이 만나게 됐고, 이제 막 기획을 마치고 본격적으로 코딩에 들어갔다.
첫 개발 팀플이기도 하고 많이 떨림. 사실 영어할 줄도 모르는데 파파고의 힘으로... 어찌저찌 진행하고 있다.
아무튼 git으로 협업하게 됐는데 Chingu 프로그램에서 git으로 협업하는 방법을 제공하고 있다.
근데 문제는 전부 영어다. 노션이라서 사이트 번역도 제대로 안돌아가서 보기에 불편하다.
그래서 보기 편하게 번역기 돌려서 한국어로 정리하려고 한다.
Git으로 협업하기
깃 브랜치 요약
3단계로 나뉜다.
- 작업 브랜치: 각 팀원이 변경 및 버그 수정을 할 때 생성되는 개별 브랜치다.
기본 브랜치 4가지: 버그, 피처(기능), 리팩터(refactor), 스타일
예시: feature/course-review(기능/과정 검토)
- 개발 브랜치: 다음 릴리즈의 코드를 반영한다. 개발자는 Working 브랜치에서 작업한 다음 이 브랜치로 pull한다. 풀 리퀘스트(이하 PR)를 통해 동료들의 검토를 받아야 함.
- 마스터 브랜치: development 브랜치에서 풀 리퀘스트를 통해 업데이트 되는 브랜치. 이 브랜치는 항상 사용자가 볼 수 있는 현재 프로덕션을 반영한다.
작업 과정(워크플로우)
- CLONE: 뼈대가 되는 레포가 깃허브에 만들어짐 => 각자 개인 컴퓨터에 clone => 각자 작업 브랜치 생성하고 개발 작업 (예: 버그 수정)
- 커밋: 대부분의 코딩 작업들은 각자 팀원들의 컴퓨터에서 진행된다. 자주 커밋 해라 커밋은 각자 별개의 목적이 있어야한다.
- Push Origin: 변경사항은 해당 작업 분기로 자주 푸쉬되어야 한다. 컴퓨터에 문제가 생겼을 경우 나머지 팀이 작업을 계속 할 수 있음.
- Pull Origin: 작업 브랜치를 내 컴퓨터로 가져와야 할 경우 ex)다른 팀원의 작업을 도울 때
- 개발 브랜치: 해당 기능을 테스트한 후 풀 리퀘스트를 거쳐 개발 브랜치로 넘어가도록 한다.
- 마스터 브랜치로 Pull: 꼼꼼하게 테스트한 후, 풀 리퀘스트를 통해 마스터 브랜치로 넘긴다.
- 릴리즈: 마스터 브랜치로 넘어가면 해당 콘텐츠를 유저들이 사용할 수 있는 프로덕션으로 릴리즈할 준비가 된거임.
깃 브랜치
마스터 브랜치