ddanddan18
commented
4 years ago Git Workflow
git에 대한 자세한 내용은 Practice Session #2 참고~ workflow 내용이 다 들어있음
1. 해결하고자 하는 문제(기능 개발 / 버그 픽스 등등)을 깃헙 이슈에 올린다. (Label 붙이고 등등)
이슈에 대한 답글로 누가 해결할 건지(A) assign한다.
2. A는 브랜치를 판다 (깃 브랜치 네이밍 컨벤션 엄수)
Git Branch Naming 규칙
feature/some-new-feature-#1 (feature/yujin-login-#1)
refactor/change-code-to-new-pattern-#1 (refactor/fixed-store-structure-#1)
bugfix/login-not-working-or-something-#1 (bugfix/login-logout-error-#1)
hotfix/typo-or-style-issue-#1 (hotfix/fixed-me-being-an-idiot-#1) git checkout -b branch-name
git push --set-upstream origin branch-name
또는 vscode에서 왼쪽아래 브랜치 - 분기만들기를 한다 (base브랜치에서 파야하는 경우는 ...분기에서 브랜치만들기)3. 코딩 & Commit Message Convention을 준수해서 커밋한다.
한 커밋에는 하나의 내용만! small commit >>>>>>>>> large commit
git config commit.template ./.gitmessage.txt
을 통해서 commit message template 설정 후
git commit
을 통해 템플릿을 채워 커밋한다issue #5 에 자세한 예시가 있음
git add modified-file.py
git commit
{commit message template 수정, vim- :wq, nano- 저장후나가기 등}
git push origin branch-name
git status, git log, git diff branch-name 을 사용하면 뭔가 info를 많이 볼 수 있음4. 개발이 끝나면 PR을 날린다 (빠른 확인을 위해 카톡으로도 한 번 말해주기)
- PR 커밋메시지 작성:
뭔가 했다 (issue #num)Implemented wardrobe page (issue #1)
5. 다른 팀원이 코드리뷰를 한다
리뷰에서는 ..
- minor style issue -> 수정
- implementation comment
6. 코드리뷰 결과 확인하고 필요하면 수정한 다음(3-5 반복) 리뷰어가 만족하면 개발한 본인이 머지한다.
7. 이슈를 close한다!
- pull request에서
closed by #1을 하면 자동으로 닫힘
8. 진행하던 브랜치에서 나온다.
git checkout master (또는 기본 브랜치)
get pull origin master (풀리퀘를 하고 merge했던 내용을 로컬로 받아온다)
그밖에도
- git fetch
- resolve conflicts (미리미리 상위 branch를 pull 받아오면 좋다하더라)
- git stash (임시저장, 잠시 ctrl-x 눌러서 없애놓은 꼴)
- git reset (add, commit 돌리기)
- git rm
- .gitignore
등이 있으니 적절히 공부하면서 사용하기!
git commit message template 설정
npm
brew
사용
참고 gitmoji-cli
템플릿 설정git config commit.template ./.gitmessage.txt템플릿을 사용해서 commit
git commit예시에 있는 fead, fix, refactor, style, docs, test, chore 등 타입을 준수한다
-사용하면 리스트가 들어간다.#을 사용하면 깃헙 이슈 넘버가 자동 링크된다 (#5)예시 화면
결과 화면