SVN → Git 이전 이유
Human Error 대비해 체계적인 형상 관리 가능
분산된 버전 제어 시스템이기 때문에 복수의 저장소에서 버전 히스토리 업데이트 가능
CI/CD 접목해 서버 코드와 항시 동기화 가능
Pull Requests 기능을 활용해 불확실한 commit 막고 코드 오너에 의해 발전된 코드로 진행 가능
구성원들 간 컨벤션을 통해 통일성 있는 형상 관리 가능
이외에도 현재 세계적으로 수요가 가장 많은 시스템이기 때문에 많은 레퍼런스 존재
Git Convention
Git-Flow
- feature : 단순 기능 개발 위한 브랜치. stage에서 checkout
- develop에서 push 테스트 후 이상 없으면 stage에 pus
- feature/티켓 번호 or feature/기능 중 결정
- remote에 push했으면 작성자가 직접 삭제하는 게 기본 원칙
- develop : 개발용 브랜치. 기획팀과 테스트 용도
- stage : 검증용 브랜치.
- master 브랜치에 직접 push되는 브랜치. 태그 생성 후 master에 push
- master : 운영 서버에 직접 배포되는 브랜치
- hotfix_{DATE}__{기능} : 에러 처리용 브랜치
- 운영 서버에 문제가 생겼을 때, master에서 분기해 즉각 오류 수정 후 master에 push
Commit Message
형상관리할 때 커밋 메시지 규칙을 정하면 보다 직관적이고 통일성 있게 작업 가능
기본 양식 : [message type] commit message
- feat : 새로운 기능 추가
- fix : 에러 수정
- docs : 문서 수정
- refactor : 프로덕션 코드 리펙토링
- test : 테스트 코드 추가/수정
- !hotfix : 급하게 치명적인 버그 수정
- chore : 빌드 테스크 업데이트, 패키지 매니저 수정
Gitblit에서 Ticket 활용한 pull-request 기능 구현
불확실한 commit을 방지하고 코드 리뷰 등을 통해 구성원 간 일관된 코드 구축
git push origin HEAD:refs/for/[대상 브랜치]%t=[티켓 이름] : 명령어로 티켓 생성하기
※ git push origin <branch 1>:<branch 2> → 로컬 HEAD의 수정 사항을 원격 대상 브랜치에 push하겠다는 의미!
※ new 명령어를 사용하면 기본 브랜치인 'master'를 대상으로 티켓이 생성되기 때문에 대상 브랜치 기입이 원칙
※ 티켓 이름은 작성자, 구현할 기능, 티켓 번호 중 협의를 통해 정할 것. 나머지 옵션은 기본값으로 정의됨.
gitblit repository → 티켓 카테고리 입장해 티켓 생성된 거 확인 후 클릭하면 티켓 상세 내용 확인 가능
상태 : 해당 티켓 자체를 관리할 수 있는 기능
승인, 거부, 포기 등으로 해당 커밋의 상태 표현 가능
담당자 : PR 받아줄 담당자(코드 오너) 지정 가능
수정 : 해당 커밋의 대상 브랜치 변경 가능
커밋 카테고리로 가서 리뷰에 승인 버튼 누르기
코드 오너는 해당 커밋을 확인하고 리뷰 기능으로 커밋 상태 변경 가능
개선 필요 혹은 거부 리뷰를 받으면 해당 커밋은 머지될 수 없으며 생성자는 필히 코드 수정
리뷰 기능
-
+2 : 머지 버튼 활성화
-
+1 : 또 다른 승인자 필요함
-
-1 : 머지 권장하지 않음
-
-2 : 머지 불가
머지 버튼 활성화되면 머지 버튼 누르기
머지 버튼 클릭 후 코드 오너는 해당 커밋에 대한 코멘트 남기기
gitblit 요약 항목 클릭해 해당 브랜치에 merge 확인
이후 local에서 git pull origin master 실시 후 최종 확인까지 했으면
git push origin --delete [생성됐던 티켓용 브랜치] : 생성된 원격 티켓 브랜치를 로컬에서 삭제
※ git push 명령어를 사용했기 때문에 remote에 ticket/{ticket-id}로 브랜치가 생성되기 때문에 원격 브랜치를 삭제하는 것이 원칙
Tag Based Deployment
운영 배포 후 문제 발생 시 rollback 하기 위함
최종 배포할 commit이 stage 브랜치에 merge가 됐을 때 master에서 pull 후 해당 commit에 tag push
tag 버전 관리는 방식 참조
Lightweight, Annotated 두 종류 중 단순 버전 확인용 태그를 남길 수 있는 Lightweight 사용
Gitblit에 tag를 push하면 해당 tag와 같은 tag 사용해 docker 이미지를 build/push
git show [태그]를 칠 때, Annotated는 commit 정보 위에 tag 정보가 나온다. Lightweight는 태그 정보 x
Annotated 태그 작성 : git tag -a [태그 이름] -m "[태그 설명]" [커밋 해쉬 코드]
커밋 해쉬 코드는 필요시에만 작성!
Lightweight 태그 작성 : git tag [태그 이름]
태그 네이밍 컨벤션은 날짜-v버전 ex)230613-v1.1 을 원칙으로 한다.
Git stash 전략
feat 브랜치에서 작업하다가 master 혹은 stage 브랜치가 최신화될 때 해당 변경 사항을 가져올 때 필요
현재 브랜치에서 작업하며 생긴 변동 사항을 굳이 commit에 남기지 않고 remote 작업을 가져올 수 있음
git stash save - 변경된 파일을 git이 추적하지 않도록 stash 스택에 담아둠
git stash list - 스택에 담아둔 stash 리스트를 볼 수 있음
git stash pop - 스택에 담아둔 stash를 현재 브랜치에서 사용하도록 가져오면서 리스트에선 삭제함
비슷한 방식으로 git rebase --interactive도 활용 가능하지만 러닝커브가 존재할 것으로 보여 stash 권장
