티스토리 뷰
1. repository
로컬 저장소는 아래 3가지로 이루어짐
- working directory : 실제소스코드
- Index : stage 역할을함
- head : commit 을 한 소스코드
2. clone
git clone : 로컬 / 원격 repository 를 복사한다.
3. commit
git add <파일이름>
git commit : 변경 내용이 head 에 반영됨
로컬 저장소에는 변경이 반영되었지만 원격 저장소에는 아직 반영되지 않음
4. checkout
브랜치를 변경
git checkout -b feature_x
git checkout master //master 로 돌아옴
푸쉬하고 난 다음에 문제가 발견되었을 시 이전버전으로 돌아갈 수도 있다.
git checkout -- <파일이름>//이전버전으로
git checkout <hash> //git log OR git hist 를 사용하여 이전버전의 hash 를 알아내어 roll back
5. Branch
master 와 격리된 상태에서 무언가를 개발할때 사용
개발을 완료한 후 master 에 merge 를 함
6.Blame
코드의 한줄한줄 누가 마지막으로 commit 한 지 정보가 필요할때
7. Diff
git diff <original branch> <diff branch>
merge 하기 전 어떤 내용이 변경되었는지 알아볼 수 있다.
8. Log
소스코드 버전의 id 를 알수있다
git log
9. Merge
git merge <branch name>
브랜치의 변경사항을 master 에 반영. 혹은 다른 두 가지를 merge
10.Pull
fetch + merge
원격저장소의 변경 내용이 로컬 저장소에 반영됨
11. Push
로컬저장소의 Head 에 머물고있는 변경내용을 원격으로 올림
git push <branch 이름>
12. Fetch
master 나 다른 branch 에서 작업한 내용이 내 로컬 repository 와 버전이 맞지 않을때 최신버전으로 업데이트
13. Rebase
Rebase 는 두 브랜치가 나뉘기 전인 공통 커밋으로 이동하고 나서 그 커밋부터 지금 Checkout한 브랜치가 가리키는 커밋까지 diff를 차례로 만들어 어딘가에 임시로 저장해 놓는다. 그 후 master 에 저장해 놓았던 변경사항을 차례대로 적용한다
Merge이든 Rebase든 둘 다 합치는 관점에서는 서로 다를 게 없다. 하지만, Rebase가 좀 더 깨끗한 히스토리를 만든다.
Rebase의 경우는 브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치고 Merge의 경우는 두 브랜치의 최종결과만을 가지고 합친다.