Git commit에 대해서

2024.08.30 - [분류 전체보기] - git 기초 사용법

git 기초 사용법

git의 기초에 대해 정리를 해본 적이 있다. 이번에는 git의 commit에 대해서 조금 더 자세하게 알아보기로 했다.
되돌아가 commit에 대한 간단한 내용들을 확인해보자.

 

ㅇcommit과 관련된 키워드

• 스냅샷(snapshot)
  스냅샷은 특정 시점의 프로젝트 소스 코드의 특정 버전을 의미한다. 프로젝트의 변경 사항을 저장(commit) 하면 변경사항을 포함하여 해당 시점에 프로젝트 코드의 스냅샷이 생성된다. 스냅샷은 프로젝트의 버전 기록을 형성하며 프로그래머가 시간의 경과에 따른 코드의 변경 사항을 추적하고 관리할 수 있도록 한다. 이전 버전으로 되돌릴 수 있도록 하기에 버전 관리 프로세스의 중요한 부분이다.
• 커밋(commit)
  커밋은 명사이자 동사인 두 가지 의미를 가진다. 명사로서의 커밋은 스냅샷을 의미한다. 동사로서의 커밋은 저장을 의미한다. 프로그래머는 커밋(스냅샷)을 커밋(저장)한다. 리포지토리의 변경 내용을 커밋(저장)하면, 커밋(스냅샷)이 리포지토리의 버전 기록에 추가되고 변경 내용이 영구적으로 적용된다. reset을 이용하여 커밋 자체를 지울 수 있으나 협업 시 꼬일 수 있어서 권장되지 않는다.
• 롤백(roll-back)
  프로젝트 소스 코드에 대한 변경 사항의 실행 취소를 의미한다. 버그가 발생했을 때, 코드에 손상(break)이 발생했을 때 등의 이유로 이전 버전의 코드로 되돌리려는 경우(revert)에 유용하다. 롤백은 revert, reset을 이용하여 할 수 있으나 일반적으로 revert를 사용한다. revert란 커밋으로 되돌릴 때 원래 커밋에서 변경한 내용을 취소하는 새 커밋을 만드는 것이다. 커밋의 기록 자체를 지우지 않는다.
• 리포지토리(repository)
  리포지토리란 중앙 저장소에 저장되고 버전 관리 시스템(vcs)인 git에 의해 관리되는 파일과 폴더의 모음이다. 버전 관리 시스템은 저장소(repostiroy)라고 불리는 폴더에서 프로젝트 소스 코드를 관리한다. 리포지토리는 프로젝트의 코드 베이스로 간주되며 리포지토리에서는 파일을 추가, 편집, 삭제할 수 있으며 코드의 기본 베이스에 영향을 주지 않고 새로운 기능이나 버그 수정을 실험할 수 있는 복사본인 branch(분기)를 만들 수 있다. 

---

ㅇ커밋의 구조

1. 커밋 메세지(commit message)
   커밋에서 변경된 내용에 대한 간략한 설명이다. 커밋 메세지는 명확하고 이해하기 쉬운 방식으로 작성된 짧고 간결한 변경사항에 대한 요약이여야한다. 다른 개발자들과 변경한 내용과 변경한 이유를 이해하는데 도움이 되기 때문이다.
2. 변경 내용(changes)
   커밋에는 프로젝트 소스 코드에 대한 변경 내용이 포함된다. 이러한 변경에는 기존 파일의 수정, 새 파일 추가, 파일 삭제가 포함될 수 있다. 변경 사항은 조회 시 줄 단위로 바뀐 부분만 볼 수 있다.
3. 작성자(author)
   커밋에는 변경한 사람의 이름과 이메일이 포함된다. 이를 통해 다른 프로그래머는 누가 변경했는지 확인하고 필요한 경우 연락 할 수 있다.
4. 작성일(date)
   커밋에는 변경한 날짜와 시간이 포함된다. 언제 변경되었는지 확인하고 프로젝트의 버전 기록을 이해할 수 있다.

 

* 여러 개의 커밋을 한번에 푸쉬할 때와 하나의 커밋을 푸시할 때

여러 개의 커밋을 한 번에 푸시하든, 하나의 커밋을 푸시하든 git의 내부 동작은 기본적으로 동일하다. git은 푸시할 때 각각의 커밋에 담긴 변경 사항만을 전송하며, 델타 압축(delta compression)을 사용해 불 필요한 데이터 전송을 줄입니다. 이 때 커밋의 수에 상관없이 git은 차이점(변경 사항)을 전송하고, 원격 저장소는 이를 받아 업데이트하는 방식입니다. 실제 차이점은 푸시한느 커밋의 수량과 데이터의 양이다. git의 압축 기법과 내부 처리 방식 덕분에 성능차이는 크지 않으며 실제 푸시 과정은 대부분의 경우 비슷하게 동작한다.

 

#델타압축: 파일의 전체를 새로 저장하는게 아니라 변경된 부분만 저장하는 방식

 

* reset의 옵션에 따른 내부 동작

	Working Directory	Staging Area	Repository
--soft	현 상태 유지	현 상태 유지	커밋 이동
--mixed	현 상태 유지	스테이징 초기화	커밋 이동
--hard	이동한 커밋의 상태로 변경	스에티징 초기화	커밋 이동

 

reset의 옵션에 따른 초기화 상태를 실습을 통해서 확인한 내용을 간단히 설명한다.

 

• --soft
  과거의 커밋으로 이동하면 commit 명령어만 사용하지 않은 상태로 돌아간다.
  내가 수정한 파일이 git add 명령어를 통해 스테이징에 임시로 보관되어 있는 상태다 git status 명령어를 사용해 확인해보면 수정된 파일이 존재하는 걸 확인할 수 있다.
• --mixed 
  과거의 커밋으로 이동하면 파일을 수정까지만 마친 상태로 돌아간다.
  이 후 다시 커밋을 하기 위해서는 git add -> git commit의 명령어를 사용해야한다. 워킹 디렉토리의 파일만 수정되어 있는 상태인 것이다.
• --hard
  과거의 커밋으로 이동하면 과거의 커밋 상태 그대로로 돌아간다.
  파일의 수정, git add, git commit 과 같은 작업을 모두 처음부터 다시해야한다.

 

* reset과 revert의 차이

git reset과 git revert는 커밋을 되돌리기 위한 명령어지만, 동작 방식과 사용 목적이 크게 다르다.

 

• git reset
  현재 브랜치의 HEAD 포인터를 과거의 특정 커밋으로 이동시켜 그 이후의 커밋들을 로컬에서 제거하는명령어 
• git revert
  특정 커밋을 취소하는 새로운 커밋을 생성하는 명령어, 되돌리고자 하는 커밋의 변경 사항을 현재 커밋에 적용시켜 변경사항을 무효화하는 새로운 커밋을 추가한다. 히스토리를 보존하면서 작업을 되돌릴 수 있는 안전한 방법이다.

	git reset	git revert
기록 보존 여부	커밋을 삭제하여 되돌아간 커밋이 최신 기록이다.	새로운 커밋을 생성하여 기록을 남김.
적용 범위	로컬에서만 적용된다.	리모트에 적용 가능하며 협업 환경에서 안전하다.
되돌리는 방식	커밋 자체를 제거하거나 커밋 포인터를이동	커밋을 무효화 하는 새로운 커밋을 생성
사용 목적	커밋을 제거하고 히스토리를 남기고 싶지 않을 때	커밋을 취소하되 히스토리를 남기고 싶을 때
데이터 손실 위험	--hard 옵션 사용 시 데이터 손실 가능	기록이 남기 때문에 기록 손실 위험이 없음

 

언제 사용하면 좋을까?

• git reset
  로컬 작업 중 커밋을 정리하거나 불필요한 커밋을 삭제할 때 사용한다.
• git revert
  협업 중인 브랜치에서 안전하게 커밋을 되돌리고자 할 때 사용된다. 기록을 보존하기 때문에 히스토리의 일관성을 유지하면서 변경 사항을 취소할 수 도 있다.