목차
1. git init 저장소 생성
현재 디렉토리를 Git 저장소로 초기화한다. 이 명령어를 실행하면 Git은 해당 디렉토리에 '.git'이라는 숨겨진 폴더를 생성한다.
git init
디렉토리를 Git 저장소에서 일반 디렉토리로 변경하려면 '.git' 디렉토리를 삭제한다.
rm -rf .git
'.git'에는 다음과 같은 폴더와 파일이 들어있다.
- HEAD: 현재 체크아웃한 브랜치 정보
- config: 원격 저장소, 사용자 이름 설정
- refs/: 브랜치, 태그 정보
- objects/: 커밋, 파일 기록(진짜 중요한 데이터!)
- logs/: 작업 내역 로그
'.git'을 삭제하려고 하면 중요한 데이터들을 모두 잃게 되는 거라서(복구는 거의 불가능하다!) 정말 지울 건지 여러 번 물어본다. 물어보지 않도록 하려면 속성에 -r 대신 -rf(force 강제)를 사용한다. 삭제할 때는 항상 신중하게!
2. git commit 파일의 변경 사항에 대한 이력 생성
Git에서 변경된 파일들을 저장소에 기록한다. 변경 내용을 커밋 메시지와 함께 저장소에 영구적으로 저장한다. 커밋 메시지는 변경 사항에 대한 설명을 쉽게 찾고 이해할 수 있게 써야 한다. 그래야 나중에 버전을 되돌리려고 할 때 필요한 시점이 언제인지 명확하게 알 수 있다.
git commit -m "커밋 메시지"
3. git status 현재 상태 확인
Git의 현재 상태를 확인한다. (가끔 GUI는 틀릴 수 있으니 콘솔에서 직접 확인하는 습관을 들여라!)
git status
Git의 3가지 영역
1. Working Directory 작업창
실제 파일이 존재하고 작업을 하는 디렉토리다. 파일을 만들면 작업창에 있다.
git status로 상태를 확인하면 파일 이름을 빨간색으로 출력한다.
GUI로 보면, Source Control 창에 Changes에 있다. 파일 뒤에 U(untracked)라고 쓰여있다.
2. Staging Area 인덱스
변경된 파일들 중 Git이 추적하기 원하는 파일들을 임시로 저장하는 영역이다. 유의미한 파일의 단위를 한 번에 올려서 독립된 하나의 버전으로 확정하기 위해 스테이지에 올린다.
git status로 상태를 확인하면 파일 이름을 초록색으로 출력한다.
GUI로 보면, Source Control 창에 Staged Changes에 있다. 파일 뒤에 A(added)라고 쓰여있다.
만약 스테이지에 올린 상태로 수정하게 되면, 스테이지에 올렸던 내용은 스테이지에 있고, 새로 수정하는 내용은 작업창에 새로 생긴다.
git status로 상태를 확인하면 빨간색과 초록색의 똑같은 두 개의 파일이 보인다.
GUI에서는 Changes와 Staged Changes에 파일이 각각 있다. 파일 뒤에는 M(modified)라고 쓰여있다.
3. Repository 저장소
모든 버전 기록이 저장되는 Git의 데이터베이스다. 최종 확정한 파일의 버전이 저장된다.
git status로 상태를 확인하면 nothing to commit, working tree clean이라고 출력한다.
GUI로 보면, Changes가 비어있고 Graph에 커밋 메시지가 보인다.
4. git add 파일의 변경 사항을 Staging Area에 추가
파일을 commit하기 위해 유의미한 파일들을 스테이지에 추가한다.
GUI에서는 파일 옆에 '+' 아이콘을 클릭한다.
# 특정 파일을 추가
git add <file>
# 변경 내용이 있는 모든 파일을 추가
git add *
git add .
5. 작업 내용 취소, 되돌리기
커밋하기 전, 파일의 작업 내용 스테이지에 추가했다가 되돌리려면 git rm 명령어를 사용한다. Git 추적을 해제하고 파일은 그대로 남긴다. 파일을 스테이지에 추가했기 때문에 Git이 관리(track 추적)하는 중이다. 이제 이 파일은 관리하지 말라고 하면 스테이지에서 내려온다. 아직 커밋을 하지 않았기 때문에 Git이 추적하지 않도록 하는 것이다.
GUI에서는 파일 옆에 '-' 아이콘을 클릭한다.
git rm --cached <file>
이미 커밋을 한 파일을 스테이지에서 내리려면 git rm 명령어만으로는 안 된다. 이미 기록이 됐기 때문이다. 이럴 땐 파일의 버전을 되돌려야 한다. 수정된 파일을 마지막 커밋 상태로 복원해야 한다.
# Working Directory에서 변경 내용을 취소할 때
git restore <file>
# Staging Area에서 변경 내용을 Working Directory로 되돌릴 때
git restore --staged <file>
GUI로 보면, 작업창에서 취소하려면 discard changes(휘어있는 화살표) 아이콘을 클릭하고, 스테이지에서 내릴 때는 '-' 아이콘을 클릭한다.
커밋하지 않은 내용을 되돌리면 복구할 수 없다! restore는 신중하게 사용해야 한다.
6. git log 커밋 이력 확인
커밋한 내용을 출력한다. HEAD는 나의 현재 위치를 알려준다.
# Log를 한 줄로 출력하는 옵션
git log --oneline
# Log를 그래프 형태롤 출력하는 옵션
git log --graph
# 모든 브랜치까지 출력하는 옵션
git log --all
# 다 합쳐서 써도 된다.
git log --oneline --graph --all
7. git checkout HEAD~# 과거 커밋 이력 확인
과거의 특정 커밋으로 이동한다. 타임머신을 타고 과거를 보는 것과 같다. 원하는 커밋으로 이동해서 브랜치를 만들어서 수정할 수도 있다. 단, 파일을 이전 상태로 되돌리면 변경 내용이 사라질 수 있다!
# 현재 기점보다 3단계 이전 기점으로 이동
git checkout HEAD~3
# hash 코드를 입력하면 특정 커밋으로 이동
git checkout <hash>
# 마지막 커밋으로 복귀
git checkout main
8. git branch 브랜치 생성 및 이동
가장 중심이 되는 브랜치인 main에서 가지가 뻗듯이 여러 브랜치를 만들 수 있다.
# 브랜치 생성
git branch <branch>
# 브랜치를 생성하고 바로 이동
git branch -c <branch>
# 브랜치로 이동
git switch <branch>
# 브랜치 삭제
git branch -d <branch>
# 브랜치 이름 변경
git branch -m <branch> <branch>
# 브랜치를 main 브랜치로 병합
git merge <branch>
# 브랜치 병합 그만두기
git merge --abort
GUI에서의 브랜치 이동은 창 왼쪽 아래에 있는 브랜치 이름을 클릭하고, 목록에서 이동할 브랜치를 선택하면 된다. 터미널창에는 변경된 브랜치가 바로 반영이 안 되기 때문에 엔터를 한 번 입력해 준다. 또는 clear 명령어를 입력해도 된다.
브랜치를 병합할 때 변경된 파일이 겹치지 않는다면 fast-forward merge(빨리감기(기본) 병합)로 병합된다. main 브랜치 위에 다른 버전이 없을 때 적용된다.
main 브랜치 위에 다른 버전이 있어서 둘을 합칠 때는 충돌(conflict)이 발생한다. 이때는 3-way merge로 둘 다 살릴 수 있다. 원하는 버전만 남기거나 둘 다 남길 수도 있다.
9. git remote 리모트 브랜치(Github) 연결
로컬에 리모트 브랜치를 조회, 추가, 삭제할 수 있다. Github 레포를 연결한다.
# 리모트 브랜치 조회
git remote -v
# 리모트 브랜치 추가
git remote add origin <https://github.com/ID/REPOSITORY>
#리모트 브랜치 삭제
git remote rm origin
10. git push 로컬에서 변경한 내용을 리모트로 전송하기
로컬의 main 브랜치에서 변경한 이력을 리모트 main(origin) 브랜치로 보낸다. 리모트 브랜치를 연결한 후 처음에는 set-upstream을 해서 어디에서 어디로 보내는지 명시해야 한다.
# 리모트 브랜치 연결 후 최초의 push
git push --set-upstream origin main
git push -u origin main
# 이후로는 push만 입력해도 된다.
git push
11. git pull 리모트 브랜치에서 로컬로 내용을 가져오기
리모트 브랜치에서 로컬로 내용을 가져온다. FF merge를 진행한다.
git pull
오늘 하루를 돌아보며
어제 git을 살짝 맛봤는데 잘 따라갈 수 있을지 조금 걱정됐었다. 역시 개념이 많이 어려웠다. 하지만 계속 강사님을 따라 실습을 하니 생각보다 빨리 익숙해지는 것 같다. 아직 낯설어서 어렵다고 생각이 드는 거고, 많이 연습하고 복습해서 손에 익히면 쉬워질 것 같다.
수업이 끝난 후 실습 예제들을 처음부터 다시 따라가면서 이해될 때까지 CLI와 GUI를 번갈아가며 연습했다. 임시 회고조 음성 채널에 들어가서 서로 어려웠던 문제들도 같이 해결했다. 다들 git에 대해 잘 이해하지 못했지만 서로 도우면서 설명해 보면서 더 이해되는 것 같다.
'부트캠프' 카테고리의 다른 글
| 멋쟁이사자처럼 프론트엔드 부트캠프 14기 - Day 5 (제목 요소의 중요성과 이미지 삽입) (0) | 2025.05.01 |
|---|---|
| 멋쟁이사자처럼 프론트엔드 부트캠프 14기 - Day 4 (Node 환경 이해 및 관련 패키지 설치와 활용) (0) | 2025.04.29 |
| 멋쟁이사자처럼 프론트엔드 부트캠프 14기 - Day 2 (CLI & Git(버전 관리)) (0) | 2025.04.27 |
| 멋쟁이사자처럼 프론트엔드 부트캠프 14기 - Day 1 (OT & 수업 준비) (0) | 2025.04.26 |
| (TMI) 멋쟁이사자처럼 프론트엔드 부트캠프 14기 - Day 0 (개발자가 되기로 마음먹기까지...) (0) | 2025.04.25 |
