Git 자주 쓰이는 명령어 모음

1) Git Repository 생성 및 초기 설정 명령어

# git init

→ 해당 경로에 .git 디렉토리를 만들며 새로운 git 저장소를 생성할 때 사용하는 명령어이다.

# git config --global core.autocrlf true

→ 협업 시, 윈도우와 맥에서 엔터 방식 차이로 인한 오류를 방지하기 위함이다.

# git config --global user.name "(본인 이름)"
# git config --global user.email "(본인 이메일)"
# git config --global init.defaultBranch main

→ 기존 Branch는 Master|Slave 명칭으로 사용되었으나 해당 용어는 인종차별로  이어질 수 있어 요즘에는 Main으로 바꾸어 사용한다.

2) Git 상태 확인 명령어

# git status

→ git 저장소의 변경사항을 확인 (untracked, tracked, staging)

# git log

→ 현재 브랜치의 커밋 내역을 출력

# git log --all --decorate --oneline --graph

→ 여러 브랜치 내역 한꺼번에 보기

3) 커밋 관련 명령어

# git add 파일명

→ 해당 파일을 working directory에서 staging area로 이동

# git add .

→ 현재 경로의 모든 파일을 working directory에서 staging area로 이동

# git restore --staged 파일명

→ Staging Area의 특정 파일을 Working Directory로 이동 (git add 취소)

→ 파일명 대신 "."을 적어서 모든 파일을 Staing Area에서 Working Directory로 이동시킬 수도 있다.

# git restore 파일명

→ Working Directory의 특정 파일을 (변경 되기 전으로) 복구한다.

→ 파일명 대신에 "."을 적으면 Working Directory의 모든 파일을 (변경 되기 전으로) 복구한다.

→ git reset --hard 명령어와 동일하다!

# git commit

→ 현재 변경내역 커밋 (Staging Area에 있는 변경내역을 Repository에 반영)

# git commit -m "comment"

→ comment + 현재 변경내역 커밋 (Staging Area에 있는 변경내역을 Repository에 반영)

# git commit -am "comment"

→ git add . + git commit -m "comment" 합친 명령어

→ 단, 새로 추가된 Untracked 파일이 없을 때 한정

4) 이전 커밋으로 rollback하는 명령어

[가정]
(1) a.txt 추가
(2) b.txt 추가
(3) a.txt 수정
(4) c.txt 추가

# git reset --soft 커밋해시

→ Repository에서 Staing Area로 이동

→ 즉, 해당 커밋해시로 이동하되 이전의 변경내역은 Staing Area에 남아있음

→ (2)번 커밋내역으로 이동한다고 가정하면 (4)번의 커밋내역은 완전히 삭제되고 (3)번의 커밋내역은 지워지지 않고 Staing Area에 남아있음

# git reset --mixed 커밋해시 (default)

→ Repository에서 Working Directory로 이동

→ 즉, 해당 커밋해시로 이동하되 이전의 변경내역은 Working Directory에 남아있음

→ (2)번 커밋내역으로 이동한다고 가정하면 (4)번의 커밋내역은 완전히 삭제되고 (3)번의 커밋내역은 지워지지 않고 Working Directory에 남아있음

# git reset --hard 커밋해시

→ 수정사항을 완전히 삭제함

→ (2)번 커밋내역으로 이동한다고 가정하면 (3), (4)번의 커밋내역은 완전히 삭제된다.

→ 커밋해시를 적어주지 않으면 마지막 커밋을 가리키게 됨

# git revert 커밋해시

→ reset과 달리 커밋내역을 지우지 않고 되돌리기 원하는 시점의 커밋의 변경내역을 거꾸로 실행한 뒤, 커밋을 하게 된다.

→ 즉, (2)번의 커밋내역을 revert하면 "(5) b.txt 삭제" 커밋이 발생한다.

→ 만약에, 중간에 충돌이 발생하면 충돌나는 파일 수정 후, git revert --continue를 해주어야 한다.

→ 예를 들어, (1)번의 커밋내역을 revert하게 되면 (3)번 커밋에서 해당 파일을 수정하였으므로 충돌이 발생하기 때문에 해당 파일을 직접 삭제한 다음 git revert --continue를 해주어야 한다.

# git revert 커밋해시 --no-commit

→ 되돌리는 원하는 시점의 커밋의 변경내역을 거꾸로 실행한 뒤, Commit을 하지 않기에 추가적으로 다른 작업을 진행한 다음 커밋할 수 있게 해준다.

→ 만약, 해당 revert 과정 자체를 취소하고 싶다면 git reset --hard를 해준다.

# git restore --source=커밋해시 파일명

→특정 파일을 원하는 커밋 시점의 상태로 되돌린다.

[참고] reset vs revert

• reset, revert는 각각 과거의 커밋내역으로 돌아갈 수 있지만 reset은 이전의 커밋내역을 삭제하고 revert는 기존의 커밋 내역을 유지한다는 차이점이 있다.

 

• 커밋 내역을 원격 저장소에 push하여 다른 개발자와 커밋내역이 공유가 된 경우에, reset을 쓰면 다른 개발자의 코드와 심각한 충돌을 일으킬 여지가 있으므로 한 번 공유가 된 커밋들은 revert를 이용해서 되돌리도록 한다.

 

[참고] reset 복구

• reset은 위에서 말했다시피 커밋 내역을 삭제한다고 하였는데 만약에 실수로 reset 명령어로 삭제하지 말아야 할 커밋 내역을 삭제했을 경우에는 git reflog 명령어를 사용하면 삭제한 커밋 내역을 복구할 수 있다.

 

• reflog 명령어는 Git에서 수행한 작업 내역을 출력하므로 과거에 수행한 작업 내역을 살펴보고 해당 시점으로 되돌릴 수 있기 때문에 실수로 reset 했어도 복구할 수 있는 것이다.

 

git reset --hard HEAD~4
git reflog
5379d71 (HEAD -> main) HEAD@{0}: reset: moving to HEAD~4
df279d4 HEAD@{1}: rebase (finish): returning to refs/heads/main
                ...
                ...
                ...
git reset --hard 5379d71 

5) 브랜치 관련 명령어

# git branch

→ 브랜치 리스트를 출력하며, "*" 표시 있는 곳이 현재 작업중인 브랜치를 가리킴

# git branch 브랜치명

→ 브랜치를 생성

# git switch 브랜치명

→ 해당 브랜치로 이동

# git switch -c 브랜치명

→ 브랜치 생성하면서 해당 브랜치로 이동

→ "git checkout -b 브랜치명" 명령어와 동일하지만 Git 2.23 버전 이후부터 Checkout 명령어의 일부 기능이 switch, restore로 분리됨에 따라 switch 명령어를 적극 사용하도록 하자

# git branch -d 브랜치명

→ 브랜치를 삭제

# git branch -D 브랜치명

→ 삭제할 브랜치의 커밋 내용이 다른 브랜치로 병합되지 않은 경우, 그동안 작업한 내용이 있어 삭제가 안될 때는 -D 옵션을 주어 강제 삭제해야 한다.

# git branch -m "기존 브랜치명" "새 브랜치명"

→ 브랜치 이름 변경

6) 브랜치 병합 (merge, rebase)

[기존]                     
ㅣ
ㅣ                   
ㅣ                 
ㅣ ㅣ               
ㅣ ㅣ            
ㅣ /             
ㅣ/                
ㅣ     sHu 브랜치               
main 브랜치 

[merge]
ㅣ
ㅣ\                   
ㅣ \                 
ㅣ ㅣ               
ㅣ ㅣ            
ㅣ /             
ㅣ/                
ㅣ     sHu 브랜치               
main 브랜치 

[rebase]
ㅣ sHu 브랜치 (HEAD)
ㅣ
ㅣ
ㅣ 
ㅣ main 브랜치 (HEAD)
ㅣ                
ㅣ               
ㅣ            
ㅣ             
ㅣ              
ㅣ     sHu 브랜치               
main 브랜치 

# git merge "병합할 브랜치명"

→ 두 브랜치를 한 커밋에 이어붙이며, 브랜치의 사용내역을 남길 필요가 있을 떄, 사용한다.

→ 브랜치를 merge 할 때는 병합할 브랜치가 아니라 병합되는 브랜치에서 해당 커맨드를 진행해야 하는데 예를 들어, 위의 sHu 브랜치가 main 브랜치로 merge 하고자 한다면 main 브랜치에서 merge 커맨드를 실행해야 한다.

→ 또한, merge도 하나의 커밋이므로 reset으로 merge 전으로 되돌릴 수 있으며 merge 한 다음, 병합된 브랜치 (sHu)는 삭제하는 것이 일반적이다.

→ 마지막으로 merge 실행 시, 충돌이 발생하면 직접 충돌이 발생하는 부분을 수정한 다음 git add + git commit을 통해 충돌을 해결한다.

→ 만약 충돌이 발생하는 파일이 많으면 git merge --abort로 merge 과정을 중단시킬 수도 있다.

# git rebase "병합할 브랜치명"

→ 브랜치를 다른 브랜치에 이어붙이며 한 줄로 깔끔히 정리된 내역을 유지하기 원할 때 적합한 방식이다.

→ merge 방식은 브랜치의 사용 내역을 남기기 때문에 수천 개의 브랜치가 생성된다면 브랜치의 구조가 굉장히 복잡해지는데 이러한 경우 rebase를 사용하면 브랜치의 사용 내역을 남기지 않고 기존의 브랜치에 이어붙이게 되므로 구조가 단순해진다.

→ 또한, 팀원과 공유된 커밋에 대해서는 rebase를 쓰게 되면 충돌을 발생할 여지가 있으므로 사용하지 않도록 한다.

→ merge와는 다르게 병합되는 브랜치가 아니라 병합할 브랜치에서 해당 커맨드를 진행해야 하는데 예를 들어, 위의 sHu 브랜치가 main 브랜치로 rebase 하고자 한다면 main 브랜치가 아니라 sHu 브랜치에서 rebase 커맨드를 실행해야 한다.

→ 그리고 rebase는 단순히 브랜치를 다른 브랜치에 이어 붙인 것이기 때문에 main 브랜치로 이동하여 git merge sHu 브랜치 명령을 실행해주어야 해당 브랜치의 시점으로 HEAD가 이동하게 된다.

→ 또한, merge 때와 동일하게 병합한 브랜치 (sHu)는 삭제하는 것이 일반적이다.

→ 마지막으로 rebase 실행 시, 충돌이 발생하면 직접 충돌이 발생하는 부분을 수정한 다음 git add + git rebase --continue를 통해 충돌을 해결하는데 merge 방식에서는 이어붙이고자 하는 브랜치의 최종 커밋만 다루는데 rebase는 브랜치를 이어붙이는 거라서 이어붙인 브랜치의 커밋이 여러 개이고 커밋마다 충돌이 발생하면 충돌이 발생하는 커밋 수 만큼 git add + git rebase --continue를 반복해야 한다.

→ 충돌이 모두 해결되면 git merge 브랜치로 마무리하고, 충돌이 너무 많이 발생해서 바로 해결하지 못할 거 같으면 git rebase --abort로 rebase 과정을 중단시킬 수도 있다.

[정리] 브랜치 병합 과정 - merge, rebase

[가정]                     
ㅣ
ㅣ                   
ㅣ                 
ㅣ ㅣ               
ㅣ ㅣ            
ㅣ /             
ㅣ/                
ㅣ     sHu 브랜치               
main 브랜치 

• 위와 같이 main 브랜치, sHu 브랜치가 있고 sHu 브랜치를 main 브랜치에 병합하도록 merge, rebase 방식으로 진행한다.

 

• merge 방식

① main 브랜치에서 "git merge sHu" 명령을 실행

② merge 실행 시, 충돌이 발생하여 충돌이 발생하는 파일 수정

③ main 브랜치에서 git add + git commit 으로 merge 충돌 해결 → merge 완료

④ 만약, 충돌 파일이 많아 merge를 취소하고자 한다면 git merge --abort 실행

 

• rebase 방식

① sHu 브랜치에서 "git rebase main" 명령을 실행

② rebase 실행 시, 충돌이 발생하여 충돌이 발생하는 파일 수정

③ git add + git rebase --continue 으로 rebase 충돌 해결

④ 만약, sHu 브랜치 커밋 수만큼 충돌이 발생하면 (2) ~ (3) 과정을 커밋 수만큼 반복

⑤ main 브랜치로 이동 (git switch main)

⑥ main 브랜치에서, "git merge sHu" 명령을 실행 → rebase 완료

⑦ 만약, 충돌 파일이 많아 rebase를 취소하고자 한다면 git rebase --abort 실행