Udacity Nanodegree Style Guide
summary에 제목, description에 내용을 적으면 아래와 같은 형태로 게시된다
위 convention 참고해서 아래와 같은 형태로 작성 (github desktop 사용 시 편리)
Summary | (분류) : (주요 내용)
------- | ----------------------
| (주요 세부 내용)
Desc. | - (항목 1)
| - (항목 2) ...
기능 1개를 구현하기 위해 개인 브랜치를 분리해서 merge 후
해당 브랜치가 제거되기까지의 사이클을 제시한다.
github desktop을 활용하면 편리하게 브랜치를 관리할 수 있다.
ex) boss의 새로운 패턴을 추가하는 과정, develop이 개발 메인 브랜치이며 현재 develop인 경우
# 1. 분류 / 모듈 - 세부 개발 내용 의 형태로 브랜치를 생성
각 항목 내에서는 snake case로 처리해야 한다 (foo_bar)
git checkout -b feature/boss-new_pattern
# 2. 개발한 내용을 중간에 저장하는 commit 작성
git commit -m 'feature: boss pattern' -m ....
# --------- 여기서부터 협업에 영향을 줄 수 있는 부분 ---------
# 3. develop 브랜치 최신화 (여기서 다른 사람이 작업한 내용이 최신화)
git checkout develop
git pull origin develop
# 3. feature 브랜치로 돌아와서 rebase 실행 (다른 사람 작업 내용이 내 브랜치에 적용됨)
git checkout feature/boss-new_pattern
git rebase develop
# 4. 충돌이 발생한 경우
여기서 conflict된 부분을 처리해야 하며 필요 시 논의를 진행해야 할 수 있다.
타인의 개발 내용을 의도치 않게 변경할 수 있기 때문
# 5. 충돌 파일들을 수정하고 본인의 브랜치 rebase를 마무리
git add .
git rebase --continue
# 6. 개발한 branch 전체를 remote에 업로드
git push -u origin feature/boss-new_pattern
# 7. github 웹페이지에서 pull request, peer review, merge
# 8. github 웹페이지를 통해 origin에 올라간 본인 feature 브랜치 처리
시간 흐름 →→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→
develop │───────────────────────────────────┯──────────────────────┯────────
│ │ │ merge
│ │ │
feature └───────────────────────────────────┴──────────────────────┘
생성 Commit 1,2,3 rebase PR & Review
작업단계 초기분기 충돌해결 / 동기화 리뷰 / 승인 / 병합
커밋상태 Initial 최종 커밋
명령어 checkout -b rebase develop PR → merge → delete