Git 버전 관리

카테고리 없음

Git 버전 관리

김딸기* 2024. 8. 3. 21:43

Git의 버전 관리

: 소스 코드의 변경 사항을 체계적으로 기록하고 관리하는 방법

이를 통해 소프트웨어 개발자들은 코드의 히스토리를 추적하고, 필요한 경우 특정 시점의 코드로 되돌아가거나, 여러 개발자가 동시에 작업할 수 있게 됩니다.

Git의 버전 관리 개념

커밋 (Commit):
- 각 커밋은 프로젝트의 스냅샷을 저장합니다.
- 커밋은 고유한 해시(SHA-1)를 가지며, 이전 커밋과의 연결고리를 형성합니다.
- 커밋 메시지를 통해 변경 사항에 대한 설명을 남길 수 있습니다.
- # 파일 변경 사항을 스테이징
  
  git add <파일 이름> # 특정 파일 추가
  
  git add . # 현재 디렉토리의 모든 변경 파일 추가
  
  git restore --staged 파일이름 #스테이지에 있던 파일을 working 디렉토리로 보냄
  
  # 커밋 생성
  
  git commit -m "변경 사항에 대한 설명"
브랜치 (Branch):
- 브랜치는 독립적인 작업 공간을 제공합니다.
- 메인 브랜치(일반적으로 main 또는 master) 외에 기능 개발, 버그 수정 등을 위한 별도의 브랜치를 생성할 수 있습니다.
- 브랜치를 사용하면 병렬로 여러 작업을 진행할 수 있으며, 필요한 시점에 브랜치 간 병합이 가능합니다.
- # 새 브랜치 생성
  
  git branch <브랜치 이름>
  
  # 브랜치 목록 보기
  
  git branch
  
  # 브랜치 전환
  
  git checkout <브랜치 이름>
  
  # 브랜치 생성과 동시에 전환
  
  git checkout -b <브랜치 이름>
병합 (Merge):
- 병합은 한 브랜치의 변경 사항을 다른 브랜치에 통합하는 작업입니다.
- 병합 충돌이 발생할 수 있으며, 이를 해결해야 원활한 병합이 가능합니다.
- # 병합할 브랜치로 전환
  
  git checkout <기준 브랜치>
  
  # 병합 수행
  
  git merge <병합할 브랜치>
리베이스 (Rebase):
- 리베이스는 브랜치의 기반을 다른 브랜치로 변경하는 작업입니다.
- 이를 통해 깔끔한 커밋 히스토리를 유지할 수 있지만, 주의해서 사용해야 합니다.
- # 리베이스할 브랜치로 전환
  
  git checkout <리베이스할 브랜치>
  
  # 리베이스 수행
  
  git rebase <기준 브랜치>
태그 (Tag):
- 태그는 특정 커밋에 이름을 붙여 중요한 시점을 표시합니다.
- 릴리즈 버전과 같이 중요한 시점에 태그를 사용하여 쉽게 참조할 수 있습니다.
- # 태그 생성
  
  git tag <태그 이름>
  
  # 태그 목록 보기
  
  git tag
  
  # 특정 커밋에 태그 추가
  
  git tag <태그 이름> <커밋 해시>
  
  # 태그 푸시
  
  git push origin <태그 이름>
원격 저장소 (Remote Repository)
- 원격 저장소는 협업을 위해 로컬 저장소와 연결된 원격 서버를 관리하는 것입니다.
- # 원격 저장소 추가
  
  git remote add origin <원격 저장소 URL>
  
  # 원격 저장소 목록 보기
  
  git remote -v
  
  # 변경 사항 푸시
  
  git push origin <브랜치 이름>
  
  # 원격 저장소에서 변경 사항 가져오기
  
  git pull origin <브랜치 이름>
  
  # 원격 저장소의 모든 브랜치와 태그 가져오기
  
  git fetch
상태 확인 및 로그 보기
- 현재 저장소의 상태와 커밋 로그를 확인하는 명령어입니다.
- # 현재 저장소의 상태 확인
  
  git status
  
  # 커밋 로그 보기
  
  git log
  
  # 간단한 로그 보기
  
  git log --oneline
클론 (Clone)
- 원격 저장소를 로컬로 복제하는 작업입니다.
- # 원격 저장소를 로컬로 복제
  
  git clone <원격 저장소 URL>

버전 관리의 주요 기능과 목적

변경 사항 추적:
- 소스 코드의 변경 내역을 모두 기록하여 언제든지 과거 버전으로 되돌아갈 수 있습니다.
- 누가, 언제, 무엇을 변경했는지 명확히 알 수 있습니다.
협업 지원:
- 여러 개발자가 동시에 작업하더라도 각자의 변경 사항을 효과적으로 관리하고 통합할 수 있습니다.
- 코드 리뷰와 병합 요청(PR: Pull Request)을 통해 협업 품질을 높일 수 있습니다.
버전 관리:
- 다양한 버전의 소프트웨어를 관리하고, 각 버전의 변경 사항을 명확히 기록할 수 있습니다.
- 안정된 버전을 유지하면서도 새로운 기능 개발을 동시에 진행할 수 있습니다.
백업 및 복구:
- 로컬 저장소와 원격 저장소의 복제 기능을 통해 데이터를 안전하게 백업하고, 필요시 복구할 수 있습니다.

Git을 사용하는 이유

안전성: 모든 커밋은 고유의 해시로 관리되어 데이터의 무결성이 보장됩니다.
유연성: 다양한 브랜치 전략과 워크플로우를 지원하여, 팀의 필요에 맞게 유연하게 사용할 수 있습니다.
효율성: 대부분의 작업이 로컬에서 수행되기 때문에 속도가 빠르고, 네트워크 의존성이 낮습니다.
광범위한 지원: 많은 개발 도구와 서비스가 Git을 지원하여, 개발 환경을 쉽게 통합할 수 있습니다.

Git의 버전 관리는 소프트웨어 개발에서 필수적인 요소로, 코드를 체계적으로 관리하고 개발자 간의 협업을 원활하게 하는 데 큰 역할을 합니다.

리셋(Reset)

커밋 기록을 변경하거나 작업 디렉토리의 상태를 되돌리는 데 사용됩니다.

1) 소프트 리셋 (Soft Reset)

소프트 리셋은 HEAD를 지정한 커밋으로 이동시키지만, 인덱스(stage area)와 작업 디렉토리(working directory)는 변경하지 않습니다.

git reset --soft <커밋 해시>

특징:

HEAD 이동: 소프트 리셋은 단순히 HEAD 포인터를 지정한 커밋으로 이동시킵니다.
인덱스 유지: 인덱스에 스테이징된 변경 사항은 그대로 유지됩니다.
작업 디렉토리 유지: 작업 디렉토리의 파일도 그대로 유지됩니다.
사용 목적: 최근 커밋을 수정하거나, 커밋을 다시 작성할 필요가 있을 때 유용합니다. 예를 들어, 커밋 메시지를 변경하고 싶을 때 사용됩니다.

2) 하드 리셋 (Hard Reset)

하드 리셋은 HEAD를 지정한 커밋으로 이동시키고, 인덱스와 작업 디렉토리 모두를 지정한 커밋의 상태로 되돌립니다.

git reset --hard <커밋 해시>

특징:

HEAD 이동: 하드 리셋도 HEAD 포인터를 지정한 커밋으로 이동시킵니다.
인덱스 변경: 인덱스가 지정한 커밋의 상태로 업데이트됩니다.
작업 디렉토리 변경: 작업 디렉토리의 파일들도 지정한 커밋의 상태로 되돌아갑니다. 이는 작업 중이던 변경 사항이 모두 사라진다는 의미입니다.
사용 목적: 작업 디렉토리와 인덱스를 완전히 특정 커밋의 상태로 되돌리고 싶을 때 사용됩니다. 예를 들어, 실수로 많은 파일을 변경한 후 이를 완전히 되돌리고 싶을 때 유용합니다.

주요 차이점 요약

소프트 리셋:
- HEAD 포인터만 이동
- 인덱스와 작업 디렉토리는 변경되지 않음
- 변경 사항은 여전히 스테이징 상태로 유지
- 안전하게 커밋 기록을 변경 가능
하드 리셋:
- HEAD 포인터 이동
- 인덱스와 작업 디렉토리도 지정한 커밋의 상태로 변경
- 변경 사항이 완전히 사라짐
- 강력한 되돌리기 기능

예시 상황

소프트 리셋 사용 상황:
- 마지막 커밋의 메시지를 수정하고 싶을 때.
- 최근 몇 개의 커밋을 하나의 커밋으로 합치고 싶을 때.
하드 리셋 사용 상황:
- 현재 작업 상태를 완전히 포기하고 이전 커밋 상태로 되돌리고 싶을 때.
- 실수로 잘못된 파일들을 대량으로 수정한 경우 이를 되돌리고 싶을 때.

소프트 리셋과 하드 리셋은 모두 Git에서 중요한 역할을 하며, 상황에 맞게 적절히 사용하면 강력한 버전 관리가 가능합니다.