[깃] 기본 개념 및 명령어 정리

설정

이름 설정

git config --global user.name 이름

이메일 설정

git config --global user.email 이메일

.gitignore 파일 생성 (윈도우)

1. gitignore.txt 파일 생성
2. ren gitignore.txt .gitignore 명령어 실행

트리

Git의 트리

1. HEAD: 마지막 커밋 스냅샷, 다음 커밋의 부모 커밋
2. 인덱스 (Index): 다음에 커밋할 스냅샷
3. 워킹(작업) 디렉토리(Wokring Directory): 샌드박스 (Sandbox)

HEAD

• 현재 브랜치를 가리키는 포인터
• 브랜치에 담긴 커밋 중 가장 마지막 커밋을 가리킴
• 지금의 HEAD가 가리키는 커밋은 바로 다음 커밋의 부모가 됨
  • 즉, HEAD는 현재 브랜치의 마지막 커밋의 스냅샷

인덱스 (Index)

• 바로 다음에 커밋할 대상
• 스테이징 영역(Staging Area; git commit 명령을 실행했을 때 Git이 처리할 대상 파일들이 있는 곳)에 있는 파일
• 인덱스는 워킹 디렉토리에서 마지막으로 체크아웃(Checkout) 한 브랜치의 파일 목록과 파일 내용으로 채워짐
• 이후 파일 변경 작업을 하고 변경한 내용으로 인덱스를 업데이트할 수 있으며 이렇게 인덱스를 업데이트하고 git commit 명령을 실행하면 인덱스는 새 커밋으로 변환됨

워킹(작업) 디렉토리

• 위의 두 트리는 파일과 그 내용을 효율적인 형태로 .git 디렉토리에 저장하지만, 사람이 알아보기 어려움
• 워킹 디렉토리는 실제 파일로 존재하며 바로 눈에 보이기 때문에 사용자가 편집하기 수월함
• 커밋하기 전에는 인덱스(스테이징 영역)에 올려놓고 얼마든지 변경할 수 있음

트리와 용어 정리

커밋

최초로 파일 추적

git add 파일명

• 파일의 상태 변화: Untracked -> Tracked, Staged, Unmodified

추적 중인 파일을 변경한 후 스테이징 영역에 파일 추가

git add 파일명

• 파일 변경 시 파일의 상태 변화: Tracked, Staged, Unmodified -> Tracked, Unstaged, Modified
• 명령어 실행 후 파일의 상태 변화: Tracked, Unstaged, Modified -> Tracked, Staged, Modified
• git add 명령으로 최초로 파일을 추적한 후 파일을 수정했다면 커밋을 위해 다시 git add 명령으로 Staged 상태로 만들어야 함
  • 파일을 수정하고 git add 명령으로 Staged 상태로 만든 후 다시 파일을 수정하면 첫 번째 수정 파일의 상태는 Staged, Modified이고 두 번째 수정 파일의 상태 Unstaged, Modified임
  • 따라서 두 번째 수정 사항으로 파일을 커밋하기 위해서는 먼저 git add 명령어로 Unstaged 상태를 Staged 상태로 변경시켜야 함

스테이징 영역에 추가된 파일 커밋

git commit 파일명

• 파일의 상태 변화: Tracked, Staged, Modified -> Tracked, Unstaged, Unmodified

변경된 모든 파일을 스테이징 영역에 추가 및 커밋

git commit -a

커밋 메시지를 작성(인라인 작성)하고 파일 커밋

git commit -m "메시지"

파일 상태 변경

워킹 디렉토리에서 파일 제거 (추적 중인 파일은 유지, 스테이징 영역에서는 파일 유지)

git rm 파일명

워킹 디렉토리에서 파일 제거 및 추적 중인 파일 제거 (스테이징 영역에서 파일 제거)

git rm -f 파일명

추적 중인 파일만 제거 (스테이징 영역에서만 파일 제거)

git rm --cached 파일명

파일명 변경

git rm 변경전파일명 변경후파일명

되돌리기

가장 최근의 커밋을 취소하고 변경 후 새로 커밋

git commit --amend

1. 첫 번째 파일 커밋: git commit 파일명1
2. 두 번째 파일 추가: git add 파일명2
3. 첫 번째 파일 커밋을 취소하고 두 번째 파일을 포함하여 새로 커밋: git commit --amend
   • 같은 브랜치 상에 있는 최종 커밋을 취소하고 새로운 내용을 추가하거나 설명을 추가하여 커밋 가능

파일의 상태를 Unstaged로 변경

git reset HEAD 파일명

• 파일의 상태 변화: Staged -> Unstaged

이전 커밋 삭제 및 삭제 이력을 남김

git revert 커밋체크섬

• 이전에 작성한 커밋을 삭제하여 변경 사항 되돌림
• 해당 커밋의 변경 사항을 되돌리는 내용의 새로운 커밋을 만들어 삭제 내역을 모든 사람이 알 수 있게 함

이전 커밋 삭제 및 삭제 이력을 남기지 않음

git reset 커밋체크섬

• 해당 커밋 이후의 변경 사항을 모두 되돌림
• git revert와 달리 삭제한 커밋 내역을 남기지 않음

reset 되돌리기

이전 커밋 시점으로 파일 되돌리기

git reset 커밋체크섬

• git revert: 되돌리기 전의 커밋(변경 사항을 반영하는 커밋) + 되돌린 후의 커밋(변경 사항을 취소하는) 모두 이력으로 남게됨
• git reset: 변경 사항을 반영하는 커밋은 삭제되고 변경 사항을 적용하기 전의 커밋만 남게됨
• git reset 명령은 현재 커밋인 HEAD의 위치, 인덱스, 워킹 디렉터리도 함께 되돌릴지를 선택하기 위한 모드를 지정할 수 있음

reset 되돌리기의 모드

1. soft 모드

    git reset --soft 커밋체크섬
   

   • HEAD의 위치만 되돌림
   • 인덱스와 워킹 디렉토리는 변경하지 않음
     • 즉, 마지막 커밋 시점 이후 변경 사항은 그대로 유지하고 해당 파일(변경된 파일)은 인덱스(스테이징 영역)에 올라가 있음

2. mixed 모드 (기본값)

    git reset 커밋체크섬
   

   • HEAD의 위치와 함께 인덱스의 상태를 되돌림
   • 워킹 디렉토리는 변경하지 않음
     • 즉, 마지막 커밋 시점 이후 변경 사항은 그대로 유지하되 해당 파일(변경된 파일)은 인덱스(스테이징 영역)에 올라가 있지 않음
   • 해당 커밋 시점의 파일 내용과 현재 파일 내용에 차이가 존재하면 커밋을 위해 먼저 git add 명령으로 인덱스(스테이징 영역)에 올려야 함

3. hard 모드

    git reset --hard 커밋체크섬
   

   • HEAD의 위치, 인덱스, 워킹 디렉토리를 모두 되돌림
     • 즉, 마지막 커밋 시점 이후 변경 사항을 모두 폐기하고 해당 파일(변경된 파일)은 인덱스(스테이징 영역)에 올라가 있지 않음

reset 되돌리기 취소

soft reset 되돌리기 취소

git reset --soft ORIG_HEAD

hard reset 되돌리기 취소

git reset --hard ORIG_HEAD

• ORIG_HEAD: git reset 명령을 실행했을 때 삭제한 커밋 내역을 보관함
• 해당 명령을 통해 git reset 명령으로 삭제한 커밋을 되돌릴 수 있음

checkout 되돌리기

파일의 상태를 변경 직전의 최종 커밋 시점으로 되돌림

git checkout -- 파일명

• 아직 커밋하지 않은 변경 내역을 취소
• 파일의 내용이 최종 커밋 시점으로 되돌아감
• 파일의 상태 변화: Modified → Unmodified
• HEAD의 위치, 인덱스, 워킹 디렉토리를 모두 되돌림
  • reset의 hard 모드와 동일

스테이징 영역에 추가된 모든 파일을 취소 (파일의 상태를 Unstaged로 변경)

git checkout .

브랜치

현재 브랜치 보기

git branch

모든 브랜치 보기

git branch -a

브랜치 생성

git branch 브랜치명

브랜치 생성 및 체크아웃

git checkout -b 브랜치명

현재 체크아웃한 브랜치에 병합하지 않은 브랜치 목록 확인

git branch --no-merged

특정 브랜치에 대한 병합 확인

git branch --no-meged 브랜치명

현재 체크아웃한 브랜치에 이미 병합된 브랜치 목록 확인

git branch --merged

특정 브랜치에 대한 병합 확인

git branch --merged 브랜치명

브랜치 삭제

git branch -d

브랜치 삭제 (강제)

git branch -D

원격 저장소 브랜치 삭제

git push origin --delete 브랜치명

현재 브랜치와 대상 브랜치의 차이점 출력

get diff 브랜치명

병합과 리베이스

• 병합과 리베이스 모두 한 브랜치의 변경 사항을 다른 브랜치에 적용하는 방법임
• 병합
  • 변경 사항이 적용된 브랜치의 변경 사항을 현재 브랜치(체크아웃한 브랜치)에 반영
  • 병합 이후에도 원본 브랜치의 이력을 삭제하지 않고 그대로 유지
  • 두 브랜치의 마지막 커밋 결과를 서로 비교하여 결과물을 합치는 과정
  • 변경 사항을 적용할 브랜치로 먼저 체크아웃한 후 변경 사항이 적용되어 있는 브랜치를 병합
  • 병합은 두 브랜치를 연결하는 병합 커밋을 새로 생성함
  • 특정 조건에서 병합 커밋을 생성하지 않을 수도 있음
• 리베이스
  • 병합과 마찬가지로 변경 사항이 적용된 브랜치의 변경 사항을 현재 브랜치(체크아웃한 브랜치)에 반영
  • 병합 커밋을 생성하는 대신 원본 브랜치에 각 커밋에 대해 새로운 커밋을 생성함으로써 변경 사항에 대한 기록을 다시 작성함

브랜치 병합

1. 브랜치 체크아웃

    git checkout 브랜치명
   

2. 브랜치 병합

    git merge 변경사항적용된브랜치명
   

브랜치 병합 (한 줄)

git merge 변경사항적용된브랜치 변경사항적용할브랜치

리베이스

1. 브랜치 체크아웃

    git checkout 브랜치명
   

2. 브랜치 리베이스

    git rebase 변경사항적용된브랜치명
   

명령형 리베이스

git rebase –i 변경사항적용된브랜치명

이력

상태 보기

git status

추적 무시된 파일 보기

git status --ignored

로그 보기

git log

• git log -p: 각 커밋에 적용된 실제 변경 내용을 보여줌
• git log --word-diff diff: 명령의 실행 결과를 단어 단위로 보여줌
• git log --stat: 각 커밋에서 수정된 파일의 통계 정보를 보여줌
• git log --name-only: 커밋 정보 중에서 수정된 파일의 목록만 보여줌
• git log --relative-date: 정확한 시간을 보여주는 것이 아니라 1일 전, 1주 전처럼 상대적인 시간을 비교하는 형식으로 보여줌
• git log --graph: 브랜치 분기와 병합 내역을 아스키 그래프로 보여줌

원격 저장소

로컬 저장소를 원격 저장소와 연결

git remote add 저장소별칭 [https://github.com/사용자이름/원격저장소이름.git](https://github.com/%EC%82%AC%EC%9A%A9%EC%9E%90%EC%9D%B4%EB%A6%84/%EC%9B%90%EA%B2%A9%EC%A0%80%EC%9E%A5%EC%86%8C%EC%9D%B4%EB%A6%84.git)

로컬 저장소가 원격 저장소와 연결되었는지 확인

git remote –v

원격 저장소에 푸시할 로컬 저장소의 브랜치를 지정하여 푸시

git push 원격저장소별칭 로컬브랜치이름

원격 저장소의 master 브랜치에 푸시

git push origin master

로컬 저장소의 모든 브랜치를 푸쉬

git push origin --all

원격 저장소의 커밋 정보를 로컬 저장소에 가져옴 (병합을 하지는 않음)

git fetch

로컬 저장소의 master 브랜치에 원격 저장소의 origin/master 브랜치를 병합

git merge origin/master

깃 삭제

리눅스

rm -rf .git

윈도우

rmdir .git

rmdir /s .git