Chingu Handbook - Git으로 협업하기

soyeon·2022년 4월 19일

TIL

목록 보기

17/32

근황

요즘 Chingu 프로그램을 통해 팀을 구해서 팀 프로젝트를 진행중이다.
나, 한국인 친구, 베트남 친구 이렇게 3명의 프론트엔드 개발자들이 만나게 됐고, 이제 막 기획을 마치고 본격적으로 코딩에 들어갔다.
첫 개발 팀플이기도 하고 많이 떨림. 사실 영어할 줄도 모르는데 파파고의 힘으로... 어찌저찌 진행하고 있다.
아무튼 git으로 협업하게 됐는데 Chingu 프로그램에서 git으로 협업하는 방법을 제공하고 있다.
근데 문제는 전부 영어다. 노션이라서 사이트 번역도 제대로 안돌아가서 보기에 불편하다.
그래서 보기 편하게 번역기 돌려서 한국어로 정리하려고 한다.

Git으로 협업하기

깃 브랜치 요약

3단계로 나뉜다.

작업 브랜치: 각 팀원이 변경 및 버그 수정을 할 때 생성되는 개별 브랜치다.
기본 브랜치 4가지: 버그, 피처(기능), 리팩터(refactor), 스타일
예시: feature/course-review(기능/과정 검토)
개발 브랜치: 다음 릴리즈의 코드를 반영한다. 개발자는 Working 브랜치에서 작업한 다음 이 브랜치로 pull한다. 풀 리퀘스트(이하 PR)를 통해 동료들의 검토를 받아야 함.
마스터 브랜치: development 브랜치에서 풀 리퀘스트를 통해 업데이트 되는 브랜치. 이 브랜치는 항상 사용자가 볼 수 있는 현재 프로덕션을 반영한다.

작업 과정(워크플로우)

1. CLONE: 뼈대가 되는 레포가 깃허브에 만들어짐 => 각자 개인 컴퓨터에 clone => 각자 작업 브랜치 생성하고 개발 작업 (예: 버그 수정)
2. 커밋: 대부분의 코딩 작업들은 각자 팀원들의 컴퓨터에서 진행된다. 자주 커밋 해라 커밋은 각자 별개의 목적이 있어야한다.
3. Push Origin: 변경사항은 해당 작업 분기로 자주 푸쉬되어야 한다. 컴퓨터에 문제가 생겼을 경우 나머지 팀이 작업을 계속 할 수 있음.
4. Pull Origin: 작업 브랜치를 내 컴퓨터로 가져와야 할 경우 ex)다른 팀원의 작업을 도울 때
5. 개발 브랜치: 해당 기능을 테스트한 후 풀 리퀘스트를 거쳐 개발 브랜치로 넘어가도록 한다.
6. 마스터 브랜치로 Pull: 꼼꼼하게 테스트한 후, 풀 리퀘스트를 통해 마스터 브랜치로 넘긴다.
7. 릴리즈: 마스터 브랜치로 넘어가면 해당 콘텐츠를 유저들이 사용할 수 있는 프로덕션으로 릴리즈할 준비가 된거임.

깃 브랜치

마스터 브랜치

프로덕션 서버에 배포될 브랜치
테스트를 완벽하게 통과하고 승인된 버젼만 이 분기로 푸쉬된다.
프로젝트 관리자 담당

개발 브랜치(Development Branch)

새로운 기능 개발 및 변경사항을 통합하는 브랜치
팀원들의 컴퓨터 => 풀 리퀘스트 => 개발 브랜치로 이동

기능 브랜치(Feature Branches)

개발 브랜치로 넘어간 다음 기능이 완성되면 다시 merge 한다.
규칙

새 브랜치를 만들거나 merge할 때 orign 레파지토리에서 변경사항을 가져와 업데이트해서 로컬 저장소를 최신 상태로 만든다.
변경 사항을 merge 했으면 해당 변경 사항을 origin 레파지토리로 push해서 팀원들이 사용할 수 있도록 한다.
⭐적어도 하루 한 번씩 개발 브랜치로 pull해서 병합 충돌을 줄인다.
브랜치의 이름은 버그, 기능(feature), 리팩터(refactor), 스타일(style)로 시작해야한다.
설명은 하이픈(-)으로

"bug/fixed-all-caps" "feature/giant-duck-modal" "refactor/add-prop-types" "style/everything-is-black"

여러 팀원이 같은 기능을 작업하는 경우 개인 기능 브랜치와 팀 기능 브랜치를 사용하는 것이 편리할 수 있다. 이 때는 아래와 같이 이름을 짓는다.

$ git checkout -b feature-a/master # team-wide branch$ git checkout -b feature-a/maria # Maria's personal branch$ git checkout -b feature-a/nick # Nick's personal branch
특별한 이유가 없으면 merge한 후 업스트림 레파지토리에서 개인 기능 브랜치를 삭제한다.

git 커밋

커밋할 때 필요한 것들

하나의 커밋에서 여러 개를 바꾸지 말자. 한 종류의 변경사항만 있어야 한다.
버그를 수정하고, 리팩토링 한다고 하면두가지 일을 한 커밋에서 하지 말고 개별 커밋으로 분할한다.
기능 구현과 해당 테스트는 동일한 커밋에서
일찍 자주 커밋해라 이해하기 쉽고 문제가 생길 경우 되돌릴 수 있음.
커밋은 논리적으로 이루어져야 한다. 커밋 B가 커밋 A의 변경 사항에 따라 달라지는 경우 커밋 A가 B보다 먼저 와야 한다.
⭐제목은 명령형으로 작성한다. ex) "Clean your room", "Close the door".
풀 리퀘스트에서 제기된 이슈를 해결했을 때 풀 리퀘스트를 다음과 같이 참조한다.
[PR139]Fix typo in introduction to user guide

팁: 요약하는 게 어려우면 한 번에 많은 변경 사항을 만드는 것일 수도 있다. 작은 커밋을 위해 노력해라

커밋 제목 짓기

적절한 커밋 제목은 항상 다음 문장을 충족시킬 수 있어야 한다.
If applied, this commit will (your subject line here)
예시:

If applied, this commit will refactor subsystem X for readability
If applied, this commit will update getting started documentation
If applied, this commit will remove deprecated methods
If applied, this commit will release version 1.0.0
If applied, this commit will merge pull request #123 from user/branch

커밋 본문 규칙

무엇을, 어떻게, 왜를 설명한다.

왜 변경 사항을 만들었는지 (이전에 어떻게 작동햇는지, 그리고 무엇이 잘못되었는지)
지금은 어떻게 작동하는가
왜 이 방식을 선택했는가
어떤 사이드 이펙트가 있을지

풀 리퀘스트

풀 리퀘스트 작성하기

목표 적기 예시: 상자 밖을 클릭하면 로그인 창이 닫힙니다.
눈으로 확인할 수 있는 사항이면 스크린샷이나 GIF를 첨부한다.
작업을 한 이유 관련 링크와 함께 간략하게 적기
⭐원하는 피드백이 뭔지 명확하게 작성하기 : 코드, 기술적 접근 방식, 디자인 등등..
⭐언제 피드백을 받고 싶은지 명확하게 작성하기 : 풀 리퀘스트가 진행 중인 작업일 경우 [WIP] 붙이기
@유저이름으로 참여하기 바라는 사람들 태그 걸고 그 이유 작성

풀 리퀘스트 리뷰하기

이슈 파악하기: 수정되거나 추가되는 기능이 뭔지 확인하기. 풀 리퀘스트의 설명을 읽고 관련 이슈를 확인한다. 만일 이해가 잘 안가면 제출자한테 설명을 요청하기.
브랜치에서 버그 혹은 부족한 부분을 재현하기: 못하겠으면 제출자랑 얘기해
pull을 체크하고 테스트하기: 기능이 제대로 작동하는지, 문제가 해결되었는지, 부작용이 있는지, 확인하기. 예를 들어 필드 값에 따라 작동하는 경우 문자열,null,숫자,날짜 등을 사용해보기.
대상 브랜치를 merge하기: pull이 제출된 이후 브랜치에서 린터가 업데이트되었을 수도 있다. (무슨 말인지 모르겠음;)
코드를 읽어라: 모르는 거 있으면 제출자한테 물어본다.
한줄씩 확인해라: 스타일 가이드를 위반했는지, 변수 이름이 이상한지, 추상화한 것들이 이해가 잘 가는지, 테스트 가능한 방식으로 정리되어 있는지 확인해라.
개선할 부분 제안하기: 수정이 필요한 코드의 행과 함께 수정 사항에 대해 명시적으로 말하기. 문제를 파악할 수 없다면 스크린샷이나 영상 찍어서 다른 팀원들과 공유해서 리뷰에 도움 주기.
당신이 첫번째 검토자고, 수정 사항이 적어보이면 다른 적합한 사람한테 전달해서 다시 살펴보도록 한다.
코드 병합하기 : 모든 게 제대로 작동하는 것 같으면 다음 브랜치에 병합한다. pull의 라벨을 확인해서 backporting이 필요한지 확인하고, 필요한 경우 backport를 해준다.
백포트: 상위 버전의 기능을 하위 버전에 반영해 주는 것