[Git] 용어 / CLI 명령어

Git 용어 및 CLI 명령어

• Git이란?
  
  • 파일 변경 사항을 시간에 따라 기록하고 필요 시 특정 버전을 다시 호출할 수 있는 버전 관리 시스템이다.
• 버전 : 파일을 수정하고 저장할 때마다 생기는 개념이다.

 

//해당 디렉토리에 git 저장소 생성
git init

• 해당 디렉토리에 git 저장소 생성

 

• Working Directory (작업 트리) : 파일 수정, 저장 등의 작업을 하는 디렉토리이다.
• Staging Area (스테이지) : 버전으로 만들 파일이 대기하는 곳이다.
  • 스테이지의 내용은 .git/index 파일에 저장된다.
• Repository (저장소) : 스테이지에서 대기하고 있던 파일들을 버전으로 만들어 저장하는 곳이다.
  • 저장소의 내용은 .git/HEAD 파일에 저장된다.

//파일 스테이징
git add 파일명

//작업 트리에서 수정한 파일들을 한번에 스테이징
git add .

• 작업 트리에서 작업한 파일을 스테이지에 추가 (스테이징)
  • 뒤에 .을 붙이면 수정한 파일들을 한 번에 스테이징할 수 있다.

 

• commit (커밋) : 스테이지에 대기하던 파일이 모두 저장소에 저장되며 새로운 버전을 생성하는 명령어이다.

//커밋
git commit -m '커밋 메시지'

//스테이징과 커밋 한번에 처리하기
git commit -am '커밋 메시지'

//가장 최근의 커밋 메시지를 수정하기
git commit --amend

• 스테이지의 파일을 저장소로 저장하며 새로운 버전을 생성 (커밋)
• 커밋 메시지 수정 시 기본 편집기 VIM이 실행된다.
  • i로 메시지 수정, :wq로 저장
• -am 옵션은 한 번이라도 커밋한 적이 있는 tracked 파일에만 사용 가능하다.

 

 

//git 상태 확인
git status

• git 상태 확인

 

//버전 확인
git log

//커밋 확인 + 커밋 관련 파일도 확인
git log --stat

//한 줄에 한 커밋씩 확인
git log --oneline

//각 브랜치의 커밋 확인
git log --branches

//브랜치와 커밋의 관계를 그래프 형태로 표시
git log --graph

//브랜치 사이의 차이점 확인
git log 브랜치명1..브랜치명2

• 커밋 기록(버전) 확인 (커밋 해시, 커밋 만든 사람, 만든 시간, 커밋 메시지...)
  • (HEAD -> master)은 가장 최신 버전임을 의미한다.
  • --stat을 붙이면 커밋 관련 파일도 확인 가능하다.
  • --oneline은 한 줄에 한 커밋씩 확인할 수 있다.
  • --branches는 모든 브랜치의 커밋을 확인할 수 있다.
  • --graph는 브랜치와 커밋의 관계를 그래프 형태로 표현한다.

 

//변경 사항 확인
git diff

• 최신 버전과 수정한 파일을 비교

 

• git은 한 번이라도 커밋을 한 파일의 수정 여부를 계속 추적한다.
  • 버전 관리를 하지 않으려면 .gitignore 파일로 버전 관리에서 제외시킬 수 있다.
    => 주로 프로그램 사용 중 자동 생성된 파일, 개인적으로 메모해놓은 파일 등...

 

• 작업 트리의 파일 상태
  • tracked : 한 번이라도 커밋을 해 추적 중인 파일이며 unmodified / modified / staged 상태로 한 번 더 나뉜다.
    
    • unmodified : 파일이 수정되지 않은 상태
    • modified : 파일이 스테이지에 올라가지 않고 수정만 된 상태
    • staged : 파일이 커밋 직전의 단계인 상태
  • untracked : 한 번도 커밋하지 않아서 추적하고 있지 않은 파일

 

//수정한 파일 되돌리기
git checkout -- 파일명

• 작업 트리에서 수정한 파일 되돌리기
  • checkout으로 되돌린 내용은 다시 복구할 수 없다.

 

//스테이징 되돌리기
git reset HEAD 파일명

//최신 커밋 되돌리기
git reset HEAD^

//특정 커밋으로 되돌리기
git reset --hard 커밋 해시

• 해당 파일 스테이징 되돌리기
  • reset은 커밋을 되돌리며 삭제한다.
  • 파일 내용은 동일하며 해당 파일이 스테이지에서 내려가고 상태가 staged -> untracked / modified... 등 이전 상태로 돌아간다.
  • git reset HEAD로 파일명을 생략하면 모든 파일을 되돌린다.
  • 커밋 해시를 통해서 특정 커밋으로 되돌릴 수 있다.
    • 되돌아갈 커밋을 지정해야 한다.
• git reset HEAD^ : (HEAD -> master)를 가리키는 가장 최신 버전 커밋으로 되돌림으로 커밋을 취소하고 스테이지에서 파일들을 내린다.
• git reset 명령어 옵션
  • --soft HEAD^ : 최근 커밋을 하기 전 상태로 작업 트리를 되돌린다.
  • --mixed HEAD^ : 최근 커밋과 스테이징을 하기 전 상태로 작업 트리를 되돌린다. (default)
  • --hard HEAD^ : 최근 커밋과 스테이징, 파일 수정을 하기 전 상태로 작업 트리를 되돌린다.
    • 되돌린 내용은 복구할 수 없다.

• staged 상태의 파일들 중 원하는 파일만 Commit & Push 하는 방법

//1번 모든 파일을 unstaged 상태로 만든다.
git reset HEAD .

//원하는 파일만 별도로 add 한다.
git add 원하는 파일

 

 

//커밋을 삭제하지 않고 되돌리기
git revert 커밋 해시

• 커밋을 삭제하지 않고 되돌리기
  
  • reset은 커밋을 삭제하고 되돌리지만 revert는 삭제하지 않고 되돌린다.
  • revert 시에는 취소할 커밋 해시를 지정해야 한다.
    • revert 시에는 커밋 메시지를 입력할 수 있다.

 

• Branch (브랜치) : Git에서 코드를 분기해서 관리하는 개념이다.
  • Git으로 버전관리를 시작하면 master(main) 브랜치가 생성된다.
  • 사용자가 커밋할 때마다 master(main) 브랜치는 최신 커밋을 가리킨다.
  • 브랜치는 커밋을 가리키는 포인터와 비슷하다.

//브랜치 확인
git branch

//브랜치 생성
git branch 브랜치명

//다른 브랜치 이동
git checkout 브랜치명

//브랜치 삭제
git branch -d 브랜치명

//브랜치 생성 후 이동
git checkout -b 브랜치명

• 베이스 브랜치가 체크아웃된 상태에서 분기했던 브랜치를 -d 옵션을 통해 제거한다.
  • 브랜치를 삭제하더라도 같은 브랜치 명으로 다시 생성하면 예전에 작업했던 내용이 그대로 나타난다.
    • 브랜치 삭제는 완전히 저장소에서 없애는 것이 아닌 감추는 것

 

• merge (병합) : 분기했던 브랜치를 기존 브랜치와 합치는 것을 의미한다.
  • 같은 파일의 다른 위치를 수정했을 경우의 병합 => 자연스럽게 자동으로 합쳐준다.
  • 같은 파일의 같은 위치를 수정했을 경우의 병합 => 브랜치 충돌(conflict)이 발생한다.
    • 충돌이 발생한 파일 외에 다른 파일들은 자동으로 병합된다.
    • 충돌이 발생한 부분은 사용자가 직접 충돌 부분을 해결한 후 커밋해야한다.
  • main, develop 브랜치에는 merge를 통해서 커밋 히스토리를 남기는 것이 좋다. (rollback 시 유용)

//브랜치 병합
git merge 브랜치명

• 브랜치 병합 시 현재 checkout된 브랜치에서 merge할 브랜치를 적어준다.
  • 일반적으로 master(main) 브랜치에 checkout하고 분기했던 다른 브랜치와 병합시켜준다.
  • 브랜치가 병합하면서 merge 커밋이 생겨난다.
• Squash Merge : Squash는 여러 개의 커밋을 하나의 커밋으로 합치는 것으로 Squash Merge는 병합할 브랜치의 모든 커밋을 하나의 커밋으로 Squash한 새로운 커밋을 Base 브랜치에 추가하는 방식으로 병합하는 것을 의미한다.

• 빨리 감기 병합 (fast-forward merge) : 베이스 브랜치에서 브랜치가 분기한 후 베이스 브랜치에 추가된 커밋이 없을 때 수행되는 것으로 merge 커밋을 별도로 생성하지 않는다.

• rebase (리베이스) : 두 개의 공통 베이스를 가진 브랜치에서 한 브랜치의 베이스를 다른 브랜치의 최신 커밋으로 옮기는 작업이다.
  • rebase는 merge와 마찬가지로 한 브랜치에서 다른 브랜치를 합치는 방법이다.
  • rebase는 커밋 이력을 남기지 않기에 commit history가 깔끔하다.
  • git rebase는 최신 커밋을 기준으로 브랜치를 정리
    rebase -i 옵션을 붙이면 커밋을 직접 편집할 수 있는 인터페이스가 제공된다.
    • rebase -i는 Git에서 커밋을 수정, 삭제, 합치기, 순서 변경 등을 할 수 있는 강력한 도구이다.

//브랜치를 rebase로 합치기
git rebase 브랜치명

//최근 N개의 커밋을 수정
git rebase -i HEAD~N

• merge vs rebase
  • merge : 쉽고 안전하지만 커밋 히스토리가 지저분할 수 있다.
    • 3-way merge를 수행한다.
    • 3-way merge : 마지막 커밋 2개와 공통 조상 총 3개의 커밋을 이용해 새로운 커밋을 만들어내는 방식
  • rebase : 잘 모르고 사용하는 경우 위험해 까다로울 수 있지만 커밋 히스토리를 깔끔하게 관리할 수 있다.
    • 공통 조상이 되는 base를 다른 브랜치의 커밋 지점으로 바꾸고 fast-foward merge를 하는 방법

• rebase -i 사용법
  
  • 커밋 수정 ex) 3번째 커밋을 수정
    1. rebase -i HEAD~3
    2. 입력한 수만큼의 커밋들이 pick jkl1122 Initial commit 이런 형태로 나온다.
    3. 수정할 커밋을 pick 대신 edit으로 바꿔주기
    4. git add . 로 변경된 파일을 Git에 추가
    5. git commit --amend --no-edit로 커밋 덮어쓰기
    6. git rebase --continue로 리베이스 진행
    7. git reflog expire --expire=now --all
       git gc --prune=now 로 Git의 캐시된 기록을 정리
    8. 만약 리베이스를 중단하려면 git rebase --abort
    9. 이후 git push origin feat/login_hb --force로 원격 저장소에 강제 푸쉬 

//수정 중인 파일 감추기
git stash

//감춘 파일 목록 확인
git stash list

//stash한 변경사항 다시 적용하기
git stash pop

//감춘 파일 가져오기
git stash apply [stash 이름]

• 수정 중인 파일을 커밋하지 않고 감춰뒀다가 꺼내올 수 있다.
  • git stash 명령어를 사용하려면 파일이 tracked 상태(한 번은 커밋된 상태)여야 한다.
  • stash는 스택 형태로 쌓이기에 LIFO 구조이다.
• stash가 필요한 상황
  • 변경사항을 커밋하기엔 아직 이른 경우
  • 다른 브랜치로 체크아웃할 때 변경사항을 유지하고 싶은 경우
  • 변경사항을 일시적으로 저장하고 싶은 경우
    • ex) 작업 도중 원격 저장소에서 pull을 받아야하는 경우 작업중이던 변경 사항을 먼저 stash하고 pull한 후 stash pop해줘야 충돌이 발생하지 않는다.
• git stash apply는 modified 상태로 가져오지 않기에 별도의 -index 옵션을 추가해주거나 add를 해줘야 한다.
  
  • apply만 사용하면 가장 최근 파일을 가져온다.

 

• local repository (로컬 저장소) : 자신의 컴퓨터에 만든 저장소를 의미한다.
  • 로컬 저장소는 git init 명령어를 통해서 만든다.
• remote repository (원격 저장소) : 로컬 저장소가 아닌 컴퓨터나 서버에 만든 저장소를 의미한다.
  • 원격 저장소에서는 Git을 사용하고 로컬 저장소를 백업하고 협업 프로젝트에 도움을 준다.
  • 원격 저장소를 제공하는 서비스 중 주로 사용하는 서비스가 깃허브

//원격 저장소와 연결
git remote add origin 저장소 주소

//원격 저장소와 연결 확인
git remote -v

//Upstream 저장소 추가
git remote add upstream Upstream 주소

• 원격 저장소를 origin 이라는 단어로 저장하겠다는 의미이다.
  • 깃에서 기본 브랜치를 master(main)이라 하는 것처럼 기본 원격 저장소는 origin이라는 이름을 사용한다.

• upstream : origin의 origin과 같은 개념이다.
  • 다른 사람의 원격 저장소를 Fork 한 경우 다른 사람의 원격 저장소가 upstream,
    Fork 해온 내 원격 저장소가 origin이다.
  • upstream도 origin과 사용법은 같다. (fetch, pull 등 origin 대신 upstream 사용하면 된다.)

 

 

• push (푸시) : 로컬 저장소의 커밋을 원격 저장소로 보내는 것을 의미한다.

//처음 origin 원격 저장소로 push
git push -u origin master

//원격 저장소로 push
git push

//원격 저장소로 브랜치까지 push
git push origin 브랜치명

• -u 옵션은 로컬 저장소의 브랜치를 원격 저장소의 master(main) 브랜치에 연결하기 위한 것으로 처음 한 번만 사용하면 된다.
  • 첫 push 이후에는 git push만 입력해도 된다.

 

• pull (풀) : 원격 저장소에서 로컬 저장소로 소스를 내려 받는 것을 의미한다.
  • 협업을 하는 경우 다른 사용자에 의해 로컬 저장소와 원격 저장소에 차이가 발생할 수 있다.
    • 서로의 상태를 같게 만들기 위해서 pull을 통해 원격 저장소의 소스를 로컬 저장소로 가져온다.
  • 협업을 하는 경우 작업을 하기 전 pull을 통해 항상 원격 저장소와 같은 상태를 유지해줘야 한다.

//origin 원격 저장소의 내용을 master(main) 브랜치로 가져오기
git pull origin master

• 기본 값이 origin과 master이기에 생략하고 git pull만 적어도 된다.

 

//원격 저장소 복제
git clone 주소 저장할 디렉토리

• 기존에 연결된 로컬 저장소 외에 다른 로컬 저장소에서 사용하려면 복제해서 사용해야 한다.
  • clone으로 복제하면 자동으로 로컬 저장소와 원격 저장소가 연결된다.
• Clone vs Fork
  
  • Clone : 원격 저장소를 로컬 환경으로 복제해오는 방법으로 모든 코드, 히스토리, 브랜치 등을 가져온다.
    • Clone한 원본 저장소를 remote 저장소 origin으로 가지고 있지만 권한이 없는 경우 push를 하지 못한다.
    • 원본 저장소와 연결되지 못한다.
    • 협업하는 경우 다른 팀원이 작업 중인 내용을 보기 위해서 팀원의 저장소를 remote에 추가해야 한다는 번거로움이 존재한다.
  • Fork : 다른 사람의 원격 저장소를 복제해서 내 저장소를 따로 만드는 방법
    • Fork한 저장소와 원본 저장소와 연결이 되어있기에 원본 저장소에 변화가 생기더라도 Fork한 저장소에 반영할 수 있다. (fetch나 rebase)
    • Fork한 저장소의 내용을 원본 저장소에 적용 시키려면 Pull Request를 보내고 승인 받아야한다.

 

//원격 브랜치 정보 가져오기
git fetch origin

• 원격 저장소의 정보를 가져온다.
  • FETCH_HEAD 브랜치로 최신 커밋 정보를 가져온다.
  • 로컬 저장소에 바로 반영되지 않는다.
  • 수동으로 직접 merge를 해줘야한다.
• pull과 fetch의 차이점
  • pull 은 원격 레포지토리로부터 최신 커밋들을 내려받아서, 현재 로컬 브랜치와 자동으로 병합을 진행합니다.
    • pull은 fetch 기능 + merge의 기능을 합쳐놓은 것과 유사하다.
  • fetch 는 원격 레포지토리에서 최신 commit 코드를 이름없는 임시 브랜치로 내려받고, 병합(merge)을 진행하지 않습니다.

 

• Pull Request (풀 리퀘스트) : 원격 저장소로 푸시한 브랜치를 병합해 원격 저장소에 반영할 수 있도록 하는 기능이다.
  • 로컬 저장소에서 push한 브랜치를 origin의 master 브랜치로 병합해서 반영하기 위함이다.

 

• cherry-pick (체리픽) : 다른 브랜치에 있는 커밋을 선택적으로 내 브랜치에 적용시킬 때 사용하는 기능이다.

//다른 브랜치의 커밋을 내 브랜치에 적용
git cherry-pick 커밋 해시1 커밋 해시2