지금까지 많은 프로젝트 및 공부를 하며 Git/Github를 많이 사용해봤는데, 그때그때 필요한거 찾아서 적용하다보니 많은 실수를 경험했다. env파일을 올려 커밋기록 삭제하다가 갑자기 완전 옛날 커밋으로 돌아가서 복구 못하기.. fork한 파일에서 브랜치 생성해서 만들었는데 fork 레포 삭제해서 한거 다날리기.. 등등 이런 경험을 많이 하다보니 사용하기 무서웠는데, 기본적인 개념부터 다양한 개념들을 공부하며 이제는 수월히 사용하기를 빈다.
먼저, Git은 버전 관리 시스템이다. 위의 경험들을 하다보니 나는 그냥 코드를 저장하는 기능으로만 생각하게 되었다. 이러한 git은 cli로 혹은 vscode의 gui로 관리를 한다.
CLI(Command Line Interface, 명령줄 인터페이스)란?
: 디렉토리 생성 및 이동, 복사, 이름 변경, 삭제 등을 미리 약속된 명령어를 사용하여 실행하는 환경 (ex: cd, rm, cat …)
버전 관리(version control)란?
: 버전 관리란, 어떤 내용을 어느 시점에 누가 변경 했는 지를 시간에 따라 기록하고, 필요할 때 특정 버전을 다시 호출할 수 있는 시스템이다.
버전 관리의 주요 목적은 프로젝트의 변경 사항을 추적하고, 이전 버전으로의 복원이나 협업을 용이하게 하며, 소프트웨어 개발 생명 주기를 관리하는데 도움을 준다.
Git의 버전관리
: 파일과 프로젝트의 변경 사항을 모두 저장하고, 이를 추적하여 이전 버전의 상태로 쉽게 돌아갈 수 있다. 이러한 기능을 통해 실수를 복구하거나, 변경 이력을 관리하기 용이하다.
또한, 여러명이 동시에 작업할 때 각자의 작업을 병합하고, 충돌을 방지할 수 있다. 그리고, Git과 Github가 존재하는데, Git은 소프트웨어로, 로컬 저장소이고, Github는 서비스로 리포지토리를 포스팅하는 기능을 한다.
Git의 상태와 영역
- Working Directory(WD, 작업 디렉토리) : 실제로 파일들이 존재하고 작업이 이뤄지는 공간
- Staging Area(SA, 인덱스) : 변경된 파일 중 Git이 추적하길 원하는 파일들을 일시적으로 저장하는 공간
- Repository(저장소) : 프로젝트의 모든 버전 기록이 담기는 곳, Git이 관리하는 데이터가 저장되는 곳
Git의 작업 흐름
- 파일을 수정, Working Directory에서 변경을 진행
- 변경 파일 중, Git이 추적하고자 하는 파일을 Staging Area에 추가
- Staging Area에 추가된 파일을 Commit하여 Repository(저장소)에 저장
: 깃 명령어가 포함된 작업 흐름
Git 사용하기(CLI)
모르는 것 위주로 정리 (익숙한 명령어는 작성하지 않았습니다.)
작업 내용 취소
# Working Directory에 변경 내용을 취소할 경우
git store <file>
# Staging Area에 변경 내용을 Working Directory로 되돌릴 경우
git store --staged <file>커밋 수정
# 마지막 커밋 메시지 수정
# 커밋 해쉬값도 변경된다.
git commit --amend
# 특정 커밋 수정
# pick -> reword로 수정한 후 커밋 메시지 수정
reword <hash> "수정할 커밋 메시지"커밋 로그 확인
git log
# Log를 한줄, 그래프 형태로 보기
git log --oneline
git log --oneline --graph
# Log가 많을 경우 모두 출력하고자 할 때
git config --global core.pager cat
# 나갈때는 Q누르기과거 커밋 이력 이동
# 이전 2개의 커밋으로 이동
git checkout HEAD~2
# 특정 커밋으로 이동
git checkout <hash>
# 마지막 커밋으로 복귀
git checkout main이전 상태로 복원 (이력 제거)
--mixed: 커밋 기록만 삭제, Working Directory에 변경 사항은 남김--soft: 커밋 기록은 삭제되지만 Working Directory와 Staging Area에 변경 사항은 남김--hard: 해당 커밋으로 복원되며 이후에 변경된 커밋 기록은 모두 삭제 (커밋 기록 다 삭제되므로 조심!😖) →아무래도 예전에 이걸 한 것 같다.. 🤐
# 아무것도 쓰지 않으면 --mixed가 포함되었다고 생각
git reset HEAD~2
git reset --soft HEAD~2
git reset --hard HEAD~2
# EX
# 커밋기록이 1, 2, 3, 4, 5 (5가 HEAD)라고 하자,
git reset 3
git reset 5
# 하면 다시 원상복구 된다.브랜치 생성 및 이동
: git switch 는 Git 2.23.0 버전부터 등장, 둘 다 사용가능
# 브랜치를 생성 및 이동
git switch -c <브랜치명>
git checkout -b <브랜치명>
# 브랜치 변경
git checkout <브랜치명>
git switch <브랜치명>
# 브랜치를 main 브랜치로 병합
git merge <브랜치명>
# 브랜치 삭제
git branch -d <브랜치명>
# 브랜치 이름 변경
git branch -m <브랜치명> <다른 브랜치명>Remote
# 리모트 브랜치 조회
git remote -v
# 리모트 브랜치 추가 (Github Repository 연결)
git remote add origin <https://github.com/ID/REPOSITORY>
# 리모트 브랜치 삭제
git remote remove origin
git remote rm originPush
# 연결된 origin으로 main 브랜치가 올라감
git push --set-upstream origin main.gitignore 자동으로 만들기
#
npx add-gitignore
npx add-gitignore node, windows, macos, visualstudiocode
#
npx mrm@latest gitignorefetch
: pull = fetch + merge
→
git fetch
# 로컬 / 리모트 장소의 최신 커밋 비교
git diff main origin/mainStash
: 변경된 파일을 임시로 보관하고, 나중에 다시 적용
# 보관
git stash
# 보관 목록 조회
git stash list
# 변경 사항 내용 조회
git stash show
# 다시 가져오기 : 작업 트리에 적용
git stash apply
git stash apply stash@{n}
# stash 이력 삭제
git stash drop
git stash drop stash@{n}
# 가져오기 및 삭제
# 위의 가져오기만 하면 이력은 남는다.
git stash pop
git stash pop stash@{n}Tag
: 특정 시점에 특정 커밋에 대해 마크를 지정
# 태그 지정 (릴리즈 버전 이름)
git tag v1.0.0
# 태그 조회
git tag
# 태그 삭제
git tag -d v1.0.0
# 태그로 체크아웃
git checkout v1.0.0
# remote 저장소 전송
# 특정 태그만 리모트 저장소로 전송
git push origin 태그이름
# 모든 태그를 리모트 저장소로 전송
git push origin --tags
# 리모트 저장소의 특정 태그를 삭제
git push --delete origin 태그이름
# 리모트 저장소의 모든 태그를 삭제
git push origin --delete $(git tag -l)이러한 기능들을 겁내지않고 사용하기를 빈다..
