Project - Trilo

팀 구성 👪

BackEnd	BackEnd	FrontEnd	FrontEnd	Design

땃쥐	LUKAS	‍♂Oliver	Bangtae	Joy

확인하기 (👈 클릭)

사용자는 google, naver, kakao 소셜 서비스와 연동하여 우리 서비스에 로그인할 수 있습니다.
각각의 사용자는 '여행'을 생성합니다. 이 때 여행의 기간을 지정할 수 있고, 변경할 수 있습니다.
- 여행의 특정 날짜에 일정을 추가할 수 있고, 일정을 다른 날짜로 드래그 앤 드롭 기능을 통해 이동시킬 수 있습니다.
- 특정 날짜 외에도, 임시보관함에 임시적으로 일정을 등록해둘 수 있습니다.

upstream : tril-be의 공식 github 리포지토리
- upstream은 정말 필요한 경우가 아닌 이상, 직접적인 merge를 금지합니다.
origin : 개발자 각각이 자신의 github에 fork한 리포지토리
local : 개발자 각각의 로컬 환경 git 리포지토리

개발자는 fork한 origin 리포지토리를 로컬환경에서 git clone 명령어를 통해 clone해오고, upstream을 리포지토리 등록하여 개발하면 됩니다.

[TRL-티켓번호] Type: 커밋 제목 

커밋에 대한 설명

Type	설명
feat	새로운 기능 추가, 확장
test	테스트 코드 작성, 테스트 리팩토링(프로덕션 코드 변경 X)
refactor	코드 리팩토링
docs	문서(API 문서, README.md) 작업, 수정
fix	버그를 고쳐야하는 경우, 요구사항 변경으로 인해 코드를 일부 수정해야하는 경우
infra	CI/CD 및 인프라(외부 아키텍처) 관련 스크립트
chore	잡다한 작업들(메서드 명, 순서 변경, 의존성 추가 등...)

JIRA를 사용하여 티켓(이슈)를 관리합니다. 새로 추가하거나 수정하여 반영해야하는 기능을 정하고 JIRA에서 해당 기능에 대응하는 티켓을 발행합니다.
개발자는 자신이 맡은 기능의 브랜치를 local에서 생성합니다. 이 때 이름은 JIRA 티켓 번호를 가져와서 TRL-xxx__...와 같이 짓습니다.
TRL-xxx_... 브랜치에서 기능을 작업하고 커밋 1개 단위로 origin에 push 합니다.
- 처음 push 할 때 PR을 생성합니다. 이제 커밋 push시마다 해당 PR에 커밋이 하나씩 붙습니다.
- 이 과정에서 CI 빌드테스트의 문제가 있을 시 해당 커밋을 로컬에서 수정하여 amend하고 push --force를 통해 덮어씌워 정상적으로 빌드되도록 합니다.
코드리뷰를 거쳐서 해당 브랜치를 dev에 병합해도 된다고 허락받으면 PR을 게시자 스스로 squash-merge 합니다.
이후 작업자들은 작업 브랜치를 해당 PR 뒤에 리베이스하여 올립니다. squash-merge를 하기 때문에 충돌이 나지 않는다면 rebase를 하지 않아도 되지만, 충돌이 날 경우에는 필수적으로 rebase하면서 충돌을 해결하야합니다. (가장 이상적인건 충돌이 나지 않도록 일감(티켓, 이슈)을 잘 나누는 것입니다.)

로컬에서 작업 후 커밋을 했는데 직전 커밋의 문제점을 발견했을 경우 git commit --amend 명령어를 통해 새로운 커밋으로 덮어씌웁니다.
해당 티켓 브랜치 커밋 이력을 수정하려면 rebase -i 명령어를 이용해 커밋 순서를 조작하거나, 커밋명을 변경하거나 복수의 커밋을 병합하는 것을 적극적으로 사용하세요.
- 혹시 origin 브랜치에 이미 작업물을 올렸다면 push --force 를 사용하세요. 이 명령어는 기존 origin 에 있던 브랜치 대신 지금 로컬에서의 브랜치를 강제로 덮어씌우는 것으로 보시면 됩니다. 단, 해당 브랜치의 PR을 다른 코드리뷰어가 리뷰 진행 중일 경우 사전 조율이 필요합니다.
브랜치를 특정 버전으로 다시 되돌리고 싶다면 reset 명령어를 사용합니다. --hard 옵션은 해당 커밋 이후의 변경점을 모두 지워버리고, mixed는 추가 작업물을 로컬에 그대로 남긴채 되돌립니다.