이번 글은 코드잇 강의를 수강하면서 배운 내용을 주로 하여 정리되어 있습니다. (코드잇 스프린트 데이터 애널리스트 트랙 1기 훈련생)
Git 자유자재로 활용하기
git reset을 하고 나서 돌아오기
git reset --hard 커맨드를 통해 예전 커밋으로 이동하는 경우에 이후에 있는 커밋들은 모두 사라지는 걸까요? 답은 아닙니다.
reset를 하더라도 그 이후의 커밋들은 삭제되지는 않고 단지 HEAD가 커밋을 가리키고 있기 때문에 이후의 커밋들은 사라지는 것처럼 보이게 됩니다.
하지만 이후의 커밋들을 다시 보기위해 돌아가고싶다면 최근 커밋의 아이디를 알아야 하는데 이를 모른다면 git reflog(reference log = 참고 기록) 커맨드를 활용하여 HEAD가 이때까지 가리켜왔던 모든 커밋들을 기록한 정보들을 확인할 수 있습니다.
각각의 경우에서 git reflog명령어를 사용하여 이전 상태로 돌아가는 것이 가능합니다. git reflog는 Git의 모든 참조 변경 내역을 기록하므로, 이전 커밋을 찾고 git reset --hard <커밋 아이디> 명령어를 사용하여 돌아갈 수 있습니다.
예를 들어, git reflog를 실행하여 특정 커밋 해시를 찾은 후,
git reset --hard <커밋 아이디>
이 명령어를 통해 원하는 커밋 상태로 돌아갈 수 있습니다.
커밋 히스토리를 보는 다양한 방법
Git에서는 git log --pretty=oneline 명령어를 사용하여 현재 브랜치의 커밋 히스토리를 한 줄로 출력할 수 있습니다. 하지만 현재 체크아웃된 브랜치뿐만 아니라 모든 브랜치의 커밋 히스토리를 확인하고 싶다면 --all 옵션을 사용할 수 있습니다.
git log --pretty=oneline --all 명령어를 입력하면 모든 브랜치의 커밋 히스토리를 확인할 수 있습니다. 그러나 --all 옵션은 모든 브랜치의 커밋을 단순히 나열하기 때문에, 어떤 커밋이 어떤 브랜치에 속해 있는지 확인하기 어렵습니다.
이런 불편함을 해소하기 위해 --graph 옵션을 추가할 수 있습니다. --graph 옵션은 커밋 히스토리를 그래프 형식으로 출력하여 각 브랜치 간의 관계를 시각적으로 보여줍니다.
따라서, git log --pretty=oneline --all --graph 명령어를 사용하면 커밋과 브랜치의 관계를 명확하게 파악할 수 있어, 커밋 히스토리를 보다 입체적으로 확인할 수 있습니다.
Git을 GUI 환경에서 사용할 수 있는 프로그램 : Sourcetree
Sourcetree는 Atlassian이라는 회사에서 만든 프로그램으로 깔끔하고 직관적인 UI로 실무에서도 많이 쓰이는 프로그램입니다.
Sourcetree 설치 방법
- 다운로드
- Sourcetree 공식 사이트에서 설치 파일을 다운로드합니다.
- 설치
- 다운로드한 파일을 실행하여 설치를 완료하고 Atlassian 계정으로 로그인합니다. 계정이 없다면 새로 생성합니다.
- Git 설치 확인
- 설치 과정 중 Git이 필요하다는 안내가 나오면 Sourcetree에서 자동으로 설치하거나, 이미 설치된 Git 경로를 확인합니다.
- 초기 설정
- 설치 완료 후 Sourcetree를 실행하여 Git 및 Mercurial 설정을 진행합니다.
- 저장소 연결
- Sourcetree 메인 화면에서 "새로운 저장소"를 추가하여 로컬 또는 원격 저장소를 연결합니다.
주요 기능
- 분기 관리: 브랜치 생성, 병합, 삭제 등 브랜치 관리를 쉽게 할 수 있습니다.
- 커밋 기록: 커밋 히스토리를 그래픽으로 확인할 수 있으며, 특정 커밋으로 이동하거나 비교할 수 있습니다.
- 풀/푸시: 원격 저장소와의 동기화를 쉽게 수행할 수 있습니다.
- 스태싱: 변경사항을 임시로 저장하고 나중에 다시 적용할 수 있습니다.
- 서브모듈: 프로젝트 내 서브모듈을 쉽게 관리할 수 있습니다.
이런 GUI 프로그램을 사용하면 터미널에 Git 커맨드를 치지 않아도 Git을 사용할 수 있습니다. CLI 환경에서 필요했던 커맨드를 몰라도 Git을 사용할 수 있다는 뜻입니다.
깔끔한 커밋 히스토리를 원할 때는 git rebase
git rebase는 Git에서 브랜치를 재배치하는 데 사용하는 명령어입니다.
간단히 말해, 커밋 히스토리를 변경하여 깔끔하게 유지하거나, 브랜치를 최신 상태로 유지할 때 사용됩니다.
- 브랜치 재배치: git rebase는 브랜치의 시작점을 다른 커밋으로 이동시켜서 브랜치의 히스토리를 재구성합니다. 이는 주로 다른 브랜치와 병합할 때 발생할 수 있는 복잡한 머지 커밋을 줄이는 데 유용합니다.
- 히스토리 정리: rebase는 커밋 히스토리를 더 깔끔하고 직관적으로 만들 수 있습니다. 예를 들어, 피처 브랜치를 메인 브랜치의 최신 상태로 업데이트하여 더 일관된 히스토리를 유지할 수 있습니다.
git rebase 사용법
git checkout feature-branch # 예) git checkout premium
git rebase main
위 명령어는 feature-branch를 main 브랜치의 최신 상태로 재배치합니다.
즉, feature-branch에서의 커밋을 main 브랜치의 최신 커밋 뒤에 붙입니다.
리베이스 도중 충돌이 발생한 경우에는, Git은 충돌을 해결할 때까지 리베이스를 중단합니다. 충돌을 해결한(직접 파일에 들어가 충돌 해결)후, 다음 명령어로 리베이스를 계속할 수 있습니다. 이 과정은 커밋 히스토리를 단순화하고, 협업 시 이해하기 쉽게 만듭니다.
git add <resolved-file>
git rebase --continue
git merge와 git rebase
rebase는 주로 브랜치 병합 시 사용되며, 병합 커밋 없이 히스토리를 유지하는 데 도움을 줍니다. 그러나 복잡한 히스토리가 필요한 경우 merge 명령어를 사용할 수도 있습니다.
- git merge: git merge [branch] 커맨드로 두 브랜치를 합치며, 모든 커밋을 유지해 복잡한 히스토리를 만듭니다. (두 브랜치를 합쳤다는 정보가 꼭 남아야하는 경우)
- git rebase: git rebase [branch] 커맨드로 한 브랜치의 커밋을 다른 브랜치 위에 재적용해, 직선적이고 깔끔한 히스토리를 만듭니다. (새로운 커밋을 만들지 않는 경우나 커밋 히스토리를 깔끔하게 유지하는게 더 중요한 경우)
결과적으로 rebase와 merge의 결과물은 동일합니다.
git rebase는 강력한 도구이지만, 그 사용법을 잘 이해하고 있는 것이 중요합니다. 올바르게 사용하면 프로젝트의 히스토리를 더 깔끔하고 관리하기 쉽게 유지할 수 있습니다.
작업 내용 임시 저장하기 : git stash
git stash 는 working directory에서 작업하던 내용을 깃이 따로 보관(stack)하게 하는 커맨드입니다.(stack : 어떤 데이터를 저장하는 구조)
git stash를 사용하면 최근 커밋 이후로 했던 내용은 모두 스택에 옮겨지고, working directory 내부는 다시 최근 커밋의 상태로 초기화됩니다.
정리하면, git stash는 Git에서 매우 유용한 기능으로, 작업 중이던 내용을 임시로 저장하고, 작업 디렉터리를 깨끗한 상태로 돌릴 수 있도록 도와줍니다.
이를 통해 다른 브랜치로 전환하거나 긴급한 수정 작업을 수행할 수 있습니다.
git stash의 동작 방식
- 작업 내용 저장: git stash 명령을 실행하면 현재의 작업 상태(추적된 파일의 변경 사항과 새로운 파일)를 스택(stack)에 저장합니다.
- 초기화: 저장 후에는 작업 디렉터리가 마지막 커밋 상태로 초기화되어, 변경 사항이 없는 깨끗한 상태가 됩니다.
- 작업 내용 조회: git stash list 명령어를 통해 저장된 stash 목록을 확인할 수 있습니다. 각 stash 항목은 식별을 위한 고유한 ID와 함께 저장됩니다.
기본 명령어
- git stash save "메시지" : stash를 저장할 때 메시지를 추가할 수 있습니다. 이는 나중에 무엇을 저장했는지 기억하는 데 도움이 됩니다.
- git stash list : 현재 저장된 stash 목록을 표시합니다.
- git stash apply [<stash>] : 스택에 있는 내용을 다시 작업 디렉터리에 가져와 적용합니다. <stash>를 생략하면 가장 최근의 stash가 적용됩니다.(작업 내용 적용)
- git stash pop [<stash>] : 지정된 stash를 적용하고 스택에서 제거합니다. <stash>를 생략하면 가장 최근의 stash가 적용되고 제거됩니다.(특정 작업 내용을 적용함과 동시에 그것을 스택에서 제거합니다.)
- git stash drop [<stash>] : 지정된 stash를 스택에서 제거합니다. <stash>를 생략하면 가장 최근의 stash가 제거됩니다.(작업 내용 제거)
- git stash clear : 모든 stash를 제거합니다.
잘못된 브랜치에서 작업하고 있었다면
잘못된 브랜치에서 작업을 한 경우에도 git stash를 활용할 수 있습니다.
작업을 할 때 잘못된 브랜치에서 작업하는 실수를 한 경우 먼저 git stash로 stack에 내용을 저장하고, 올바른 브랜치에 가서 다시 git stash apply를 합니다.
git stash를 계속 하다보면, stack에 내용이 쌓이게 되는데 작업 내용이 너무 많이 쌓인 경우에는 내용을 보기 힘들기 때문에 이미 적용한 내용은 지워주는 것이 좋습니다.
그래서 내용을 지워줄 때는 git stash list를 해서 내용과 스태쉬 아이디를 확인하고 git stash drop [stash 아이디]를 통해 내용을 지울 수 있습니다.
필요한 커밋만 가져오는 git cherry-pick
git cherry-pick은 자신이 원하는 작업이 들어있는 커밋들만 가져와서 현재 브랜치에 추가하는 커맨드입니다.
이는 보통 다른 브랜치에 있는 특정 커밋을 현재 작업 중인 브랜치에 통합하고자 할 때 사용됩니다. 예를 들어, 어떤 브랜치에 중요한 버그 수정 커밋이 있다면, 그 커밋만을 가져와서 현재 브랜치에 적용할 수 있습니다.
git cherry-pick <커밋아이디> # 히스토리에서 커밋 아이디를 찾고 git cherry-pick <커밋해시> 명령어를 실행하여 해당 커밋을 현재 브랜치에 적용
체리픽 과정에서 또한 충돌이 발생할 수 있습니다.
이 경우 Git은 충돌을 알려주며, 사용자는 수동으로 충돌을 해결해야 합니다. 충돌을 해결한 후에는 다음 명령어를 사용하여 체리픽을 완료합니다.
git add <충돌해결파일>
git cherry-pick --continue
장점
- 특정 커밋만 선택적으로 적용 가능
- 브랜치 간에 필요한 변경 사항을 쉽게 가져올 수 있음
여러 커밋을 하나의 커밋으로 만들기
여러 커밋을 하나의 커밋으로 합치는 방법에는 여러 가지가 있는데, 여기서는 git reset --soft, 그리고 git reset --mixed를 사용하는 방법을 설명하겠습니다.
git reset --soft는 특정 커밋으로 이동한 후, 해당 커밋 이후의 변경 사항을 모두 스테이징합니다. 이를 통해 여러 커밋을 하나로 합치는 과정은 다음과 같습니다.
soft reset 실행
git reset --soft HEAD~N
# N: 합칠 커밋의 수
새 커밋 작성
git commit -m "새로운 커밋 메시지"
git reset --mixed는 특정 커밋으로 이동한 후, 해당 커밋 이후의 변경 사항을 워킹 디렉토리로 이동합니다. 이를 통해 여러 커밋을 하나로 합치는 과정은 다음과 같습니다.
mixed reset 실행
git reset --mixed HEAD~N
# N: 합칠 커밋의 수
변경 사항 스테이징 및 새 커밋 작성
git add .
git commit -m "새로운 커밋 메시지"
- git reset --soft HEAD~N: 마지막 N개의 커밋을 스테이징 상태로 되돌리고, 새로운 커밋을 작성하여 합칩니다.
- git reset --mixed HEAD~N: 마지막 N개의 커밋을 워킹 디렉토리로 되돌리고, 변경 사항을 스테이징한 후 새로운 커밋을 작성하여 합칩니다.
Git을 자유자재로 활용하는 주요 커맨드 리스트
git reflog | HEAD가 그동안 가리켜왔던 커밋들의 기록을 출력합니다. |
git log --all | 모든 브랜치의 커밋 히스토리를 출력합니다. |
git log --all --graph | 모든 브랜치의 커밋 히스토리를, 커밋 간의 관계가 잘 드러나도록 그래프 형식으로 출력합니다. |
git rebase [브랜치 이름] | A, B 브랜치가 있는 상태에서 지금 HEAD가 A 브랜치를 가리킬 때, git rebase B를 실행하면 A, B 브랜치가 분기하는 시작점이 된 공통 커밋 이후로부터 존재하는 A 브랜치 상의 커밋들이 그대로 B 브랜치의 최신 커밋 이후로 이어붙여집니다. |
git stash | 현재 작업 내용을 스택 영역에 저장합니다. |
git stash apply [커밋 아이디] | 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용합니다. |
git stash drop [커밋 아이디] | 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 스택에서 삭제합니다. |
git stash pop [커밋 아이디] | 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용하면서 스택에서 삭제합니다. |
git cherry-pick [커밋 아이디] | 특정 커밋의 내용을 현재 커밋에 반영합니다. |
주의 사항
(1) git commit이라고만 쓰고 실행하면 커밋 메시지를 입력할 수 있는 텍스트 에디터 창이 뜹니다. 거기서 커밋 메시지를 입력하고 저장하고 나면 커밋이 이루어집니다.
(2) git push와 git pull은 그 작업 단위가 브랜치입니다.
이번 글에서는 Git을 자유자재로 활용하는 방법을 설명했습니다.
이번 글을 마지막으로 Git에 대한 기초 개념을 마무리하려 했지만 다음 글에서 Git에서 사용할 수 있는 모든 주요 커맨드를 정리한 글을 소개할 예정입니다.
Git과 Github은 개발자라면 사용할 일이 있고 필수적으로 사용할 수 있는 프로그램이니 이번 글을 통해 내용을 숙지하거나 이번 기회를 통해 알아가면 좋을 것 같습니다.
글 읽어주셔서 감사합니다.
출처 및 참고자료 : 코드잇 사이트 강의 'Git' https://www.codeit.kr/topics/git
'프로그래밍 > Git' 카테고리의 다른 글
Git 협업하기 개념 정리 1️⃣ (Git을 통한 협업) (0) | 2024.08.06 |
---|---|
[Git 개념 정리] Git 개념 정리 5️⃣ (Git에서 사용하는 주요 커맨드 리스트) (0) | 2024.07.26 |
[Git 개념 정리] Git 개념 정리 3️⃣ (브랜치 사용하기, Git을 통한 협업) (6) | 2024.07.25 |
[Git 개념 정리] Git 개념 정리 2️⃣ (Github 다루기, 커밋 다루기) (2) | 2024.07.21 |
[Git 개념 정리] Git 개념 정리 1️⃣ (Git, Github, Git 다루기) (0) | 2024.07.20 |
데이터 분석을 공부하고 카페를 열심히 돌아다니는 이야기
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!