가짜연구소 Git & Docker 사용법 세션을 듣고 정리하는 내용
레포는 링크 참조
Git
- 분산형 버전 관리 시스템(Version Control System)의 한 종류
- 팀 뿐만 아니라 개인 프로젝트의 코드 관리를 위해서도 필요
기본 사용법
git status: working tree의 변경 상황과 현재 branch를 알려줌
git add .: working directory 상의 변경 내용을 staging area에 추가got commit -m "커밋 메세지": 코드 변화를 기록, commit이 끝나는 순간 staging이 초기화됨git push origin master: git local 저장소에 있는 commit을 remote 저장소로 업로드, 해당 명령어로 origin 원격 저장소의 master 브랜치를 로컬 저장소의 master 브랜치로 merge 할 수 있게 해주겠다는 의미
git checkout -b "브랜치 이름": 새 브랜치 생성
로컬에서 생성 후git push origin "브랜치 이름"으로 push
- 'git rebase': base를 바꿔 staging이 master branch를 따라가게 만들어줌
- 참고: https://seosh817.tistory.com/240#%EB%--%B-%--%EC%-E%--%EC%--%--%--branch%EC%-D%--%--%EA%B-%--%EA%B-%--%--commit%EB%A-%--%EB%-B%A-%--conflict%EB%A-%BC%--%ED%--%B-%EA%B-%B-%ED%--%B-%EC%--%BC%--%ED%--%-C%EB%-B%A--
Git 관리 시나리오
목표: Gaussian모델을 NaiveBayes로 변경(이런 하나의 작업을 ticket이라고 말함)
- 작업을 위한 브랜치는 master가 아니라 항상 staging 브랜치에서 딴다. 그 전에 staging을 rebase해두는 것은 필수
작업 브랜치도작업자/작업내용으로 맞추는게 좋음
- feature의 staging에 추가하기 전에
isort,black등을 사용해 코드 규정을 맞춰줌
git add .로 추가
git commit -m "커밋 메세지"로 커밋. 보통 커밋 메세지는 ticket과 동일하게 맞춰줌
git push origin "feature 브랜치"로 푸시
- git에 들어가면 메세지 확인 가능
- pr(pull request)를 보냄. 이때 reviewer와 assignee를 선택하는게 일반적
- 문제가 없으면 바로 merge
- staging 브랜치에서 코드가 변경된 것을 확인할 수 있음
- staging에 있는 코드는 바로 master로 가져오는 것이 아니라 release 브랜치를 새로 따서 가져옴. release 브랜치는
release/현재시각_해당표준시를 사용.
staging에서 master로 바로 안 보내는 이유는 release에서 fe, be, ai 등에서 작업한 코드를 합치는 작업(squash)을 하기 때문
- staging으로 checkout 후 origin에서 commit 기록을 pull, 이후 commit 기록을 가져옴. log의 가장 위는 merge 기록이기 때문에 코드 변화가 없어서 가져올 수 없음
- 다시 release로 checkout해
git cherry-pick "커밋 기록"으로 코드 변화를 가져옴.
git push origin "release 브랜치"로 origin에도 release 브랜치가 생긴것을 확인 가능
- release -> master로 pr을 통해 merge
- commit 기록에서 release -> master로 merge된걸 확인 가능
- master, staging의 pull과 rebase는 수시로 해주는 것이 중요
오류 및 해결
fatal: couldn't find remote ref master
원인: github의 기본 생성 branch 이름이 입력한 것과 달라 발생
해결: 우측 펜 아이콘을 눌러 이름을 master로 변경
이런 창이 뜨면 해결
즐겁게 개발하기