Git - 내가 필요한 모든 깃 명령어를 모아보자
💌 Git
요즘은 개인적으로 Git을 잘쓰는 방법이 뭐가 있을까 고민하고 있다. 🤔 항상 쓰는 명령어 위주로 사용하기 때문에 (예를들어 pull, push, commit etc…) 다른 복잡한 상황에서는 한계를 느꼈기 때문이다.
특별한 상황이 올 때마다 찾아보고 명령어를 입력하곤 했는데, 이제는 상황별 명령어를 정리해두고, 이런 command들을 체화할 필요가 있다고 느꼈다! 이 포스팅에서는 생각 날 때마다, 혹은 새로운 command가 필요한 시점마다 정리해두려고 한다.
🎉개념 정리
깃을 작성하다 보면 HEAD, staging, working directory 같은 용어를 자주 만나게 된다.
이 개념이 정확히 잡혀있지 않으면 깃 내용이 더욱 아리송해지는 만큼큼, 내용 시작에 앞서 개념 정리부터 시작해보자.
📢깃의 커밋 과정
- Working Directory: 파일을 수정하는 곳
- Staging Area: 커밋할 파일을 모아두는 공간
- Repository: 커밋이 실제 저장되는 장소
✒️Git 사용 시나리오
아래는 내가 작업 중 만났던 상황별, 특정 깃 명령어를 정리한 것이다. 각 상황별로 어떤 명령어를 썼는지 복기해보면서, 각 상황에 자연스럽게 사용할 수 있도록 체화해보자.
1️⃣ 시나리오#1 로컬 브랜치 이름을 바꿔야 할 때
실수로 로컬 브랜치 이름을 잘못바꿨을 땐 어떻게 해야할까?
✅ 현재 브랜치 이름 바꿀 때
1
git branch -m 새로운브랜치-이름
✅ 다른 브랜치 이름 바꿀 때
1
git branch -m 기존브랜치-이름 새로운브랜치-이름
2️⃣시나리오#2 작업 완료 전에 다른 브랜치로 변경해야 할 때
깃허브 브랜치를 적극 활용한 이후로 시나리오 2번이 필요한 경우가 잦았다. A 브랜치에서 새로운 기능을 개발하고 있는데 갑자기 B 브랜치의 수정이 필요한 경우다.
이 때 git switch 명령어를 입력하는 경우 커밋을 해야 한다는 안내가 나오는데, 이 때 완전히 commit을 하지 않고, 임시 저장하고 branch를 옮길 수 있다.
✅ 변경사항 임시 저장
1
git stash
✅ 다시 임시 저장해둔 브랜치로 돌아올 떄
1
git stash pop
3️⃣시나리오#3 커밋 메세지를 잘못 입력했을 때
신나게 작업을 완료해 커밋메세지를 작성해 enter 까지 눌러 완료했다고 생각해보자. 그런데 문득, 커밋 메세지에 오타가 있다는 것을 발견하면 어떻게 해야할까?
✅ 방금 커밋한 메세지를 수정해야 하는 경우
1
git commit --amend
✅ 그 전에 커밋한 메세지를 수정해야 하는 경우
1
git rebase -i HEAD~n # n = 수정할 커밋 개수
4️⃣시나리오#4 작업한 내용을 지우고 싶을 때
(물론 이런 일이 없어야 겠지만) feature A, feature B를 개발하고 커밋한 다음, feature C를 개발하던 와중, B와 C의 작업 내역이 완전히 꼬여서, 다시 feature A 작업 완료 후 진행한 커밋으로 돌아가고 싶다고 가정해보자.
✅ feature B, C의 커밋과 작업 내역을 전부 다 삭제해야 하는 경우
1
git reset --hard 커밋해시
✅ feature B, C 작업 내역은 남겨두고 커밋만 삭제해야 하는 경우
1
git reset --soft 커밋해시
5️⃣시나리오 #5 특정 작업 내역으로 돌아가고 싶을 때
이번에는 feature A, B 각각 개발을 완료하고 각각 커밋하여 C를 작업한다고 가정해보자. 완료되어 커밋한 이후, C를 작업하던 와중 B를 마쳤던 커밋 시점을 확인하고 싶으나 시나리오 #4 처럼 커밋을 삭제하는 것이 아니라 남겨 두고, 잠시 시점만 돌아가는 경우이다.
✅ 잠시 특정 시점을 확인해야 할 떄떄
1
git checkout 커밋해시
✅ 특정 시점에서부터 작업할 수 있는 새로운 브랜치를 만들고 싶을 떄떄
1
git checkout -b 브랜치 커밋해시
6️⃣시나리오 #6 file 1개만 이전 커밋으로 돌아가고 싶을 때
만약 file1, file2, file3을 중점적으로 변경한 branch 가 있다고 가정해보자. 그런데 file2 작업 내역이 꼬여 file2만 이전 커밋으로 돌아가고 싶을 땐 어떻게 해야 할까?
1
git checkout 커밋해시 -- file2
7️⃣시나리오 #7 file 1개만 커밋하고 싶을 때
이번엔 새롭게 작업한 file 1, file 2 중 file 1만 커밋하고 싶을 땐 어떻게 하면 좋을지 생각해보자.
1
2
git add file1
git commit -m "feat: file1만 커밋"
8️⃣시나리오 #8 깃허브에서 만든 브랜치 로컬에 가져오고 싶을 때
작업 중 local에서 브랜치를 만들고 깃허브에 push 하는 방법도 있지만, 반대의 방법도 가능하다!
1
2
git fetch origin
git checkout -b 로컬브랜치이름 origin/원격브랜치이름
9️⃣시나리오 #9 깃허브 브랜치와 로컬 브랜치 연결하고 싶을 때
만약 깃허브에서 A 브랜치를 만들었는데, 해당 브랜치를 먼저 pull해와서 시작하는 것이 아니라, local환경에서 A’ 브랜치를 만들어 작업하고 원격 A 브랜치와 로컬 A’ 브랜치를 연결하려면 어떻게 해야할까?
1
git branch --set-upstream-to=origin/원격브랜치 로컬브랜치
추가 정리
아직 내가 사용해본 적은 없지만, 깃을 찾아보면서 알게 된 명령어를 정리해보았다.
revert
revert는 Git에서 이미 커밋된 내용을 되돌리는 명령어로, 단순히 그동안의 커밋을 취소해서 되돌리는 것이 아니라, 되돌리는 내용을 새 커밋으로 만들게 된다.
예를 들어 살펴보자! 내 최종 목표는 다시 A 시점으로 돌아가는 것이다.
1
A -- B -- C (HEAD)
git revert C 먼저 를 실행하면, C의 변경사항을 취소하는 새 커밋이 만들어진다.
1
A -- B -- C -- C' (C' = 'C를 되돌린 커밋')
그리고 다시 git revert B를 하면
1
A -- B -- C -- C' -- B'
마지막으로 git revert A를 하면
1
A -- B -- C -- C' -- B' -- A'
이렇게 순서대로 되돌리는 커밋이 쌓여서, 다시 A 상태와 비슷 해지게되며, Git 히스토리가 계속 이어지고 있으므로, 모든 변경 기록은 남아있게 된다.
이렇게 git revert는 커밋 히스토리를 되돌린다. 라는 의미에서 git reset과도 자주 비교된다.
가장 특징적인 차이점으로는, git reset은 커밋자체를 제거하여, 브랜치를 완전히 정리할 때 사용하므로 협업 사용시 굉장히 주의를 요하지만,
git revert의 경우 새 커밋을 생성하며 되돌리기 때문에 reset에 비해서는 협업시에 안정성을 높일 수 있고, 그 이전 기록이 남아있다는 장점도 있다는 것이다.