[GIT] GIT을 통해 버젼관리를 하는 방법

서론

오늘은 GIT을 통해 버젼관리를 하는 방법에 관해, 혼자 작업하는 상황을 가정하고 설명하겠습니다.

버젼관리 (변경사항 등록 및 삭제)

Local Repository는 working directory, staging area, repository 이렇게 3개의 트리로 구성됩니다.

• working directory : 로컬 레포지토리 등록이 되면 자동으로 변경사항이 추적되며, 그 내용은 이곳에 기록되는 곳을 말합니다.
• staging area : 버전관리를 하고 싶은 파일/폴더들을 보관하는 곳입니다.
• repository : 버젼관리 등록이 된 파일/폴더들을 보관하는 곳입니다.

기본 사용 방법

• git init
  • 작업 중인 폴더에서 git을 사용할 수 있도록 해줍니다.
• git add [파일명]
  • 폴더 내의 모든 파일을 git staging area에 추가해줍니다.
  • git add . 입력하면, 디렉토리 내 모든 파일을 staging area로 이동시킵니다.
• git commit
  • -m "commit message"
    • 커밋과 동시에 커밋 메세지 작성합니다.
  • -am
    • 한번 트랙된 파일들을 add와 commit을 동시해 처리합니다.
• git remote add origin [repostory주소]
  • repository 주소를 origin 이름으로 등록합니다
• git push -u origin master
  • origin이란 원격 저장소에 master branch에 푸시합니다.

버젼 읽기

• git status
  • working directory의 변경사항들을 목록화해줍니다.
• git log
  • commit 히스토리 확인합니다.
  • -p
    • commit 간에 파일의 바뀐 내용을 보여줍니다.
  • -stat
    • 파일들의 변경 여부를 알려준다.

버젼 수정하기

• git checkout [commit-id]
  • 해당 버젼으로 변경된다.
• git checkout master
  • 최신 버젼의 정보로 되돌아간다.

버젼 삭제하기

• git reset
  • HEAD^
    • 바로 이전 커밋 삭제하기
  • --soft
    • index 보존(add O, staged O), 워킹 디렉토리의 파일 보존.
  • --hard
    • index 취소(add X, unstaged), 파일 삭제.
  • --mixed
    • index 취소(add X, unstaged), 파일 보존.
  • --[paths]
    • 현 디렉토리 영역의 커밋 삭제하기

특정 버젼으로 돌아가기

• git revert [commit-id]
  • 기존 커밋 내역에 영향을 주지 않으면서, 이전 커밋을 취소하기 위한 커밋을 생성한다.
  • 그러나 이전 커밋들이 존재하는 상태에서의 커밋을 취소할 순 없다. 역순으로 전부 다 취소해야 가능하다. 대신 revert를 쓰면, 버젼 정보도 보관하면서 이전 버젼으로 돌아갈 수 있다.
• git checkout [commit-id]
  • checkout을 통해서 역시, 이전 버젼으로 돌아갈 수 있다.
• git reset
  • HEAD가 가리키는 커밋을 삭제함으로써, 기존에 Repository의 히스토리를 변경합니다.

파일 상태를 Unstage로 변경하는 방법

실수로 git add . 명령을 사용하여 모든 파일을 Staging Area에 넣은 경우,
Staging Area(git add 명령 수행한 후의 상태)에 넣은 파일을 빼고 싶을 때가 있다.
이때, git reset HEAD [file] 명령어를 통해 git add를 취소할 수 있다.

작업 내용을 임시 저장하는 방법

• git stash : 모든 파일 임시저장
  • pop
    • 임시 저장 내용 복원
  • list
    • 모든 변겅점 목록을 보여줌
  • drop
    • 가장 최근에 저장한 임시 저장 내용 제거

프로젝트 다운로드 방법

# public repo 
git clone [repository경로]  

# private repo 
git clone https://닉네임@github.com/dalicious-manager/[repository경로]

Git Rebase vs Merge

Git에서 브랜치를 합치는 두 가지 주요 방법이 있습니다: merge와 rebase입니다.

1. Merge와 Rebase의 차이점

구분	git merge	git rebase
이력 관리	병합(commit 이력 병합), 히스토리 분기점 유지	선형화(재배치), 히스토리 깔끔하게 정리
커밋 이력	Merge commit 생성	기존 커밋을 새롭게 복사해서 붙임 (커밋 해시 변경)
충돌 처리	병합 지점에서 한 번에 처리	각 커밋마다 순차적으로 처리
사용 목적	협업 시 안전한 병합	개인 작업 히스토리 정리

2. 언제 어떤 것을 사용해야 할까?

git merge 사용 시점:

• 팀원과 공동으로 작업하는 브랜치를 병합할 때 (예: feature → dev)
• 이력 보존이 중요하거나 충돌 가능성이 많은 경우

예시:

git checkout dev
git merge feature/login

git rebase 사용 시점:

• 개인 브랜치에서 main 브랜치 기준으로 작업할 때
• PR 전에 커밋 히스토리를 깔끔하게 정리하고 싶을 때

예시:

git checkout feature/login
git fetch origin
git rebase origin/main

⚠️ 주의사항: rebase 후에는 강제 push(--force)가 필요하므로, 다른 사람이 사용 중인 브랜치에는 사용하지 않아야 합니다.

Git Fetch vs Pull

원격 저장소의 변경사항을 가져오는 두 가지 방법이 있습니다.

1. Fetch와 Pull의 차이점

구분	git fetch	git pull
동작 방식	원격 변경사항만 가져옴 (로컬 브랜치는 변경 없음)	원격 변경사항을 가져오고 자동으로 로컬 브랜치에 병합
충돌 가능성	없음 (단순 조회)	있음 (자동 merge 시)
안전성	안전함 (확인 후 병합 가능)	주의 필요 (무분별한 pull 시 충돌 발생)

2. 언제 어떤 것을 사용해야 할까?

git fetch 사용 시점:

• 원격 저장소의 변경사항을 먼저 확인하고 싶을 때
• 로컬에서 merge/rebase를 직접 제어하고 싶을 때

git fetch origin
git log HEAD..origin/main  # 변경사항 확인
git merge origin/main      # 확인 후 병합

git pull 사용 시점:

• 단순히 최신 상태로 동기화하고 싶을 때 (혼자 작업 중)
• 이력 충돌 걱정이 없거나, fast-forward merge만 필요한 경우

git pull origin main

실전 팁

1. 협업 시:

   • merge + fetch 조합 사용
   • rebase는 개인 브랜치에서만 사용

2. 개인 작업 시:

   • rebase로 커밋 히스토리 정리
   • PR 전 리팩토링에 활용

3. 안전한 작업 흐름:

   • fetch로 변경사항 확인
   • diff로 차이점 검토
   • merge로 안전하게 병합

참고사이트

Git
[Git] git add 취소하기, git commit 취소하기, git push 취소하기 - Heee's Development Blog
[GitHub] remote에 이미 push한 파일 지우기