Git : Global Information Tracker
-- 버전관리시 사용하는 소프트웨어 자체
Github
-- git으로 관리하는 프로젝트의 복사본을 저장하는 서버 제공해주고 협업을 위한 편의기능 제공해주는 서비스
git의 3가지 작업영역
1. working directory 2. staging area 3. repository
레포지토리(: 저장소)
-- 버전별 변경사항을 저장하고, 변화모습이 모두 담겨있음
커밋 아이디 = 커밋 해시
커밋 히스토리 깔끔하게 보기 : --pretty=oneline **oneline = 커밋당 한줄씩 출력해라
git show 커밋아이디 : 어떤 파일이 어떻게 변했는지 알려줌
git commit --amend : 최신 커밋 수정
alias : 별명 → 길이가 긴 커맨드에 별명을 붙임 : aliasing → → git config alias.log--pretty=oneline
HEAD 가 가리키는 커밋에 따라 working directory 구성
HEAD~x : 현재 HEAD가 가리키는 커밋보다 x단계 이전에 있는 커밋
Detached HEAD : 브래치를 통해서 커밋을 가리키는 게 아니라 본인이 직접 커밋을 가리키고 있는 상태의 HEAD
(: 과거의 특정 커밋에서 새로운 브랜치 만들고 싶을 때)
git fetch
브랜치가 가리키고 있는 커밋 이전에 이루어진 모든 커밋들을 가져옴 가져오기만함 ( → merge와 다름)
리모트 레포지토리에 있는 브랜치의 내용을 일단 가져와서 살펴본 후에 따라하고 싶을 때 사용 (pull하면 무조건 merge되어 버리므로)
브랜치
git checkout [브랜치이름] : 해당 브랜치로 이동
git checkout-b [브랜치이름] : 브랜치 만들고 나서 바로 그 브랜치로 이동
merge
다른 브랜치에서 했던 커밋 가져오고 싶을 때, HEAD가 가리키던 커밋에 다른 브랜치가 가리키던 커밋을 합쳐서 새로운 커밋을 만드는 것
→ merge 취소 : merge--abort
머지의 종류
1. fast-forward merge : 선형적으로 존재; 새로운 커밋이 생기는 게 아니라 단지 브랜치가 이동하게 되는 merge
2. 3-way merge : 분리된 2개의 선상에 존재; base의 내용과 비교했을 때 달라진 부분이 있는 것이 우선시 됨, 두 브랜치 모두 변화 있으면 conflict 발생
git rebase [새로운 베이스] : 원래 브랜치의 베이스를 새로운 브랜치로 재지정
git rebase --continue : conflict가 발생했을 경우 이를 해결하고 나서, 제대로 진행되지 못한 리베이스 계속 진행해라 ~
merge VS rebase
1. rebase는 새로운 커밋을 만들지 않음
2. rebase로 만들어진 커밋 히스토리를 merge로 만들어진 커밋 히스토리보다 깔끔함
git reset
--soft / --mixed : HEAD 위치만 과거의 커밋으로 바꾸고 working directory는 그대로 둔다
--hard : HEAD가 과거의 커밋을 가리킴 + commit 이후 working directory에서 했던 내용들도 되돌리고 싶음
이때 soft/mixed 코드는, 더 효율적인 코드를 코밋을 다시 했다면, reset --soft/mixed 를 통해서 그전으로 돌아가서 커밋
→ 쓸데없는 커밋이 사라짐
git revert [커밋아이디] : 이전 커밋내용으로 되돌아간 새로운 커밋 생성( : reset과의 차이)
git reflog : HEAD가 가르켰던 커밋들을 보여줌 → 얘를 통해서 커밋 아이디를 찾아서 되돌릴 수 있음
tag(태그)
: 증요한 커밋에 추가적으로 다는 것 (ex. 주요 버전의 시작점이 되는 커밋)
태그생성 : git tag [태그이름] [태그아이디]
각 태그와 연결된 커밋 보기 : git show [태그이름]
git push -u origin master : 현재 로컬 레포지토리에 있는 master 브랜치 내용을 origin이라는 리모트 레포지토리로 보낸다.
-u = --set -upstream : 로컬 레포지토리에 있는 master 브랜치가 origin에 있는 master 브랜치를 tracking 하는 것으로 설정
tracking : 연결되어 계속 그것을 바라보는 상태
git blame
: 한 가지 파일이 있기까지 어떤 커밋들이 있었는지 알 수 있음 = 어떤 파일의 특정 코드를 누가 작성했는 지 찾아낼 수 있음
git stash : stack에 working directory에서 작업하던 내용을 따로 보관
→ 최근 커밋 이후로 작업했던 내용들은 모두 스택에 옮겨지고 working directory 내부는 다시 최근 커밋의 상태로 초기화
git stash list : 작업 내용 조회
git stash apply : 스택에 있는 내용을 다시 working directory로 가져와서 적용
→ 응용) 잘못된 브랜치에서 작업하고 있었을 경우에 올바른 브랜치로 가서 apply 해주면 됨
git stash drop [작업아이디] : 스택에 쌓인 내용 삭제
git stash pop [작업아이디] : apply + drop (=작업내용 적용하고 스택에서 제거)
헷갈릴 수 있는 부분
➡️ 커밋을 해도 staging area에는 아무 변화가 없다
➡️ git reset 시에 reset 이후의 커밋들이 아예 삭제되는 것이 아님
➡️ git pull : 리모트 브랜치에서 내용을 가져와서 로컬 브랜치 내용과 merge 하는 것까지를 의미함
Linting
소스 코드에서 스타일, 문법, 오류 등이 특정 규칙에 어긋난 것 이 없는지 자동으로 체크해 주는 툴
-- 팀 전체가 동일한 코드 스타일 유지 가능
ex) Javascript - ESlint
Github Flow
-- 깃허브에서 제안한 브랜치 관리 전략
main 브랜치로부터 작업 브랜치를 생성하고 Pull Request를 통해 코드 리뷰 후 머지하는 방식 (**feature 브랜치)
CI / CD
CI
- Continuous Integration : 코드 변경 사항을 중앙의 코드 저장소에 빈번하게 통합하는 과정
코드 변경 사항을 빠르게 검증하고, 문제 발생 시 즉시 해결하여 개발의 효율성과 코드 품질을 높일 수 있음
CD
- Continuous Delivery
CI 과정을 통해 검증된 코드가 프로덕션 환경에 배포될 준비가 되어있음
- Continuous Deployment
CI 과정을 통해 검증된 코드가 자동으로 프로덕션 환경으로 배포되는 것
ex) flake8, black, mypy
CI/CD와 브랜치 관리전략 등에 대해서 추가 공부 필요