다른 버전관리시스템과 비교했을때 git의 장점
스냅샷
다른 시스템은 처음에 파일을 저장하고 이후에는 변경된것만저장함
깃은 변경될떄마다 그때의파일로저장
->해당 버전 불러올때빠름
분산저장시스템
로컬,원격 각각버전있어서 네트워크없어도 저장가능
git에는 3가지 공간이 있다.
1. working directory
2. staging area
3. repository
1 - (add전)
tracked파일과 untracked파일(새로 생성된파일, ignore된파일)이있다
git add 명령어로 staging area로 이동시킴
2 - (add후 commit전)
커밋을위한준비단계
git commit 명령어로 repository로 이동시킴
3 - (commit된 상태)
git rm = 파일삭제+git add
git mv = 파일이름변경+git add
git restore --staged (파일명) = 파일을 staging area에서 working directory로
--staged를 빼면 변경사항아예없앰
(working directory에 있는 파일의 변경사항만 없앰, staging area는 유지)
git reset의 3가지 옵션
--soft: repository에서 staging area로 이동
--mixed (default): repository에서 working directory로 이동
--hard: 수정사항 완전히 삭제
HEAD
현재 속한 브랜치의 가장 최신 커밋
git checkout HEAD^ ^ or ~개수만큼 현재브랜치의 이전단계로 이동
HEAD~~ = HEAD~2
git checkout (커밋해시) 커밋해시도 가능
git checkout - (이동을) 한 단계 되돌리기
checkout을 통해 이동한건 현재 브랜치가 이동한게 아니라 새로운 브랜치를 만들어서 그 브랜치가 이동한것
- 기존 브랜치로 돌아오기: git switch (브랜치명)
⭐ HEAD 사용하여 reset하기
git reset HEAD(원하는 단계) (옵션)
fetch vs pull
fetch: 원격 저장소의 최신 커밋을 로컬로 가져오기만 함
pull: 원격 저장소의 최신 커밋을 로컬로 가져와 merge 또는 rebase
pull = fetch + (merge or rebase)
fetch의 존재 이유
pull을 하면 바로 commit이 진행된다. fetch를 통해 원격저장소의 변경사항을 (커밋하지 않고) 한번 테스트해볼수있다.
원격 저장소의 브랜치로 이동 git checkout origin/main
이때 git fetch후 이동해줘야 원격저장소의 변경사항 반영됨
원격저장소 브랜치의 생성도
fetch해야 반영됨
git branch -a 로컬 & 원격저장소 모든 브랜치 확인
git switch -t origin/(브랜치명) 해당 원격저장소의 브랜치에 대응하는 로컬저장소의 브랜치 생성후 바로 이동
커밋 관리
- 하나의 커밋에는 한 단위의 작업을 넣도록 합니다.
- 한 작업을 여러 버전에 걸쳐 커밋하지 않습니다.
- 여러 작업을 한 버전에 커밋하지 않습니다.
- 커밋 메시지는 어떤 작업이 이뤄졌는지 알아볼 수 있도록 작성합니다.
컨벤션
널리 사용되는 커밋 메시지 작성방식
type: subject
body (optional)
...
...
...
footer (optional)예시
feat: 압축파일 미리보기 기능 추가
사용자의 편의를 위해 압축을 풀기 전에
다음과 같이 압축파일 미리보기를 할 수 있도록 함
- 마우스 오른쪽 클릭
- 윈도우 탐색기 또는 맥 파인더의 미리보기 창
Closes #125| Type | 설명 |
|---|---|
| feat | 새로운 기능 추가 |
| fix | 버그 수정 |
| docs | 문서 수정 |
| style | 공백, 세미콜론 등 스타일 수정 |
| refactor | 코드 리팩토링 |
| perf | 성능 개선 |
| test | 테스트 추가 |
| chore | 빌드 과정 또는 보조 기능(문서 생성기능 등) 수정 |
Subject
커밋의 작업 내용 간략히 설명
Body
길게 설명할 필요가 있을 시 작성
Footer
- Breaking Point 가 있을 때
- 특정 이슈에 대한 해결 작업일 때
세심하게 커밋하기
이전까지는 파일별로 커밋을 했지만,
이제는 하나의 파일 안에서도 원하는 부분만 커밋이 가능하다.
git add -p hunk별 스테이징 진행
y는 add, n은 add x, q는 종료
변경된 사항이 붙어있지 않다면, 각각을 hunk라고 함
git commit -v 커밋을 작성하면서 변경사항 확인가능
커밋하기 애매한 변화 치워두기
코드를 작성하다가 다른 오류수정을 해야할때 기존 코드를 다른곳에 저장하고 싶을때 사용하는 명령어 git stash
git stash pop 치워놨던 변화들 다시 적용
위 두 명령어만 알아도 잘씀
git stash branch (브랜치명) 새 브랜치를 생성하여 pop
커밋 메시지 변경
git commit --amend 바로 이전 커밋 메시지 변경
현재 변경사항 이전커밋에 반영하고 싶을때
git add & git commit --amend
과거의 커밋들을 수정, 삭제, 병합, 분할하기
git rebase -i (대상 바로 이전 커밋)
과거 커밋 내역을 다양한 방법으로 수정 가능
p, pick 커밋 그대로 두기
r, reword 커밋 메시지 변경
d, drop 커밋 삭제
s, squash 이전 커밋에 합치기
e, edit 수정을 위해 정지edit중일때 마지막에
git rebase --continue해줘야함
이 명령어는
rebase이기 때문에 원하는 작업을 하고 남은 커밋들을 계속 rebase 해줘야한다.
만약 남은 커밋들 중에 충돌된 커밋들이 있다면 그 충돌을 다시 제어해줘야 한다.
그리고 원격저장소가 따로 있는 상태에서git rebase -i를 진행한다면 원격저장소와 다른 독립된 커밋이 등록된다.그냥 처음부터 커밋을 잘 작성해놓자...
git이 관리하지 않는 파일들 삭제하기
git clean
-n 삭제될 파일들 보여주기
-i 인터렉티브 모드 시작
-d 폴더 포함
-f 강제로 바로 지워버리기
-x ⚠️ .gitignore에 등록된 파일들도 삭제 (주의)
커밋하지 않은 변경사항 되돌리기
git restore 특정 파일을 지정된 상태로 복구
git restore (파일명) 특정 파일 이전 상태로 복구
git restore . 모든 파일 복구
git reset --hard와 비슷
하지만reset은 staging area의 파일들까지 모두 치워버림
git restore --staged (파일명) 파일을 staging area에서 working directory로 복구
git restore --source=(헤드 또는 커밋 해시) (파일명)
파일을 특정 커밋의 상태로 되돌림
git reflog git의 모든 변경사항 보여줌
이 해시코드를 통해 reset하기 이전 시점으로 복구 가능
태그
- 특정 시점을 키워드로 저장하고 싶을 때
- 커밋에 버전 정보를 붙이고자 할 때
lightweight 특정 커밋을 가리키는 용도
annotated 작성자 정보와 날짜, 메시지, GPG 서명 포함 가능
git tag v2.0.0 마지막 커밋에 태그달기
git tag 현존하는 태그들 확인
git tag -a v2.0.0 마지막 커밋에 태그달기(annotated)
git tag v2.0.0 -m '자진모리 버전'
-m 태그가 -a 태그 암시
git tag (태그명) (커밋 해시) -m (메시지)
원하는 커밋에 태그 달기
git push (원격명) (태그명) 특정 태그 원격에 올리기
Branch 깊이 알기
merge의 두가지 방식
Fastforward vs 3-way merge
3-way merge는 기존의 merge 방식
두 브랜치가 모두 변경사항이 있을때, 합치면서 새로운 커밋을 등록하는 것
fastforward는 한브랜치가 다른브랜치의 부분집합일때의 merge 방식
한쪽 브랜치의 변경사항이 없기때문에 굳이 새로운 커밋을 생성하지 않고 최신 브랜치로 업데이트 해준다.
단점은, merge할때 어떤 브랜치를 어떻게 병합했는지 기록이 남지않는다.
git merge --no-ff (브랜치명)을 통해 커밋 새로생성가능
git cherry-pick (체리의 해시) 다른 브랜치의 원하는 커밋만 가져온다.
다른브랜치의 커밋과 새로운 커밋은 다른 커밋
git rebase --onto (도착 브랜치) (출발 브랜치) (이동할 브랜치)
다른 브랜치에서 파생된 브랜치 옮겨붙이기
git merge --squash (대상 브랜치)
다른 커밋들을 하나로 묶어 가져오기
변경사항들 스테이징 되어있음
git commit을 통해 메시지입력&커밋
일반 merge : A와 B 두 브랜치를 한 곳으로 이어붙임
merge --squash : B 브랜치의 마디들을 복사해다가 한 마디로 모아 A 브랜치에 붙임 (staged 상태로)
Gitflow
협업을 위한 브랜칭 전략
https://nvie.com/posts/a-successful-git-branching-model/
main 제품 출시/배포
develop 다음 출시/배포를 위한 개발 진행
release 출시/배포 전 테스트 진행(QA)
feature 기능 개발
hotfix 긴급한 버그 수정
git log --grep (검색어) 커밋 메시지로 로그 검색
git diff 워킹 디렉토리의 변경사항 확인
git diff (커밋1) (커밋2) 커밋간의 차이 확인
git diff (브랜치1) (브랜치2) 브랜치간의 차이 확인
git blame 각 라인의 작성자 확인
GitLens 확장프로그램쓰자 바로바로확인가능
git bisect 이진탐색으로 문제 발생시점 확인
git bisect start, git bisect good/bad, git checkout (해당 커밋 해시) 로 하나씩 체크하면서 진행
