솔직히 깃은 아직도 헷갈리는 상태로 팀플에 투입된거라 걱정스러웠다 ^0^;;
팀플할 때 필요하거나 공부해야할 내용들을 다시 기록해봤다.
깃모지
설치는 다했고 터미널 명령어만 정리
git add .
gitmoji -c
git push origin develop
(우리팀에서 현재 만든 브랜치가 develop라서! master라면 master라고 쓰면 되겠죠?)
커밋 메세지 형식
:gitmoji: (type): (function details)
gitmoji
🐛: 고칠때
✨: 새로 만들때
🔥: 지울때
🚀: 배포 관련types
- feat : 새로운 기능 추가 (apis)
- fix : 버그 수정
- refactor : 코드 리팩토링
- test : 테스트 코드
- chore : 빌드 업무 수정, 패키지 매니저 수정 등
- add : 기능도 아니고 문서도 아닌 무언가를 수정할 때
- delete : 삭제
- update : 버전 업데이트
- rename : 이름 변경
- move : 코드나 파일 이동
- modify : 수정
- correct : 문법 오류, 타입 변경, 오타 등
ex) ✨ feat: fetchproduct
브랜치/PR형식
브랜치 이름 형식
(type) / (function details)
ex) feat/fetchproduct
PR형식
:gitmoji: (type): (function details)
ex) 🐛 modify: fetchproduct
브랜치
- 브랜치 생성
git checkout -b (브랜치명)
- 브랜치 확인
git branch
- 브랜치 이동
git checkout (브랜치명)
- 브랜치 삭제
삭제하고자 하는 브랜치가 아닌 곳으로 이동한 뒤 아래의 명령어를 통해 삭제한다.
git branch -d (브랜치명)
이슈
이슈는 작업의 버그 수정, 새로운 추가될 기능, 개선해야하는 기능 등등 모든 것이 될 수 있다. 모든 활동 내역에 대해 이슈를 등록하고 그 이슈를 기반으로 작업을 진행한다. 그리고 이슈를 만들면 이슈를 열었다(open)라고 하고, 작업이 끝나 이슈를 정리하면 이슈를 닫았다(close)라고 말한다.
하지만, 이슈에서 label과 assignees를 아무리 부여해도 무언가 부족하다. 각 기능별 서로 유사한 이슈들이 존재하며, 이 관련된 이슈들을 찾거나 해당 기능들이 얼마나 구현되었는지 파악하기 위해선 일일히 추적해야한다.
=> 이를 돕는 기능이 바로 MileStone기능이다. 마일스톤은 말그대로 이정표 역할을 하며, 이슈들을 그룹화한다.
마일스톤
마일스톤이란 프로젝트가 도달해야 하는 목표지점을 지정해두는 것이다. 예를 들어, 3주동안의 프로젝트라면 Projects를 만든 것과 같이 주 단위의 목표를 나눠서 Week1, Week2, Week3로 할 수도 있고, 어떤 A라는 기능을 만들어야 한다면 그 기능에 대한 마일스톤을 만들 수도 있다. 그래서 진행상황을 표현할 수 있다.
=> issue들의 그룹, 이정표로써 진행 상황을 표현
풀리퀘스트(PR)
Pull Request의 약자 => 서버에 업데이트 되어 있는 내용을 받아오는 것.
- 즉 남의 저장소 내용을 내가 가져가서 업데이트 한 뒤에
'이 부분 제가 이렇게 바꿨는데, 제가 작업한 부분도 적용해 주세요!'라는 요청을 보내는 것이다.
매일 최소 1회 이상의 푸시와 풀 리퀘스트
=> 회의가 끝나고 푸시하고 내 로컬을 최신화, 코드를 merge
팀프로젝트
- Develop branch에서 git pull upstream develop
- 새로운 브랜치 만들기
git checkout -b (브랜치 이름)- 새로운 브랜치에서 작업하기
- 완료후
git add .
git commit -m ”커밋 이름”
git push origin (작업했던 브랜치 이름)- Git hub에서 PR보낼 때 꼭
본인 레파지토리의 작업했던 브랜치 —> upstream develop branch- PR merge 후 1번으로 반복
