[GIT] 커밋 히스토리 관리 및 원격 저장소(GitHub) 협업

코드를 수정하고 커밋(Commit)하는 과정을 반복하다 보면, 프로젝트에는 수많은 버전의 스냅샷이 쌓이게 됩니다. 이렇게 누적된 기록을 효과적으로 열람하고 분석하는 것은 과거의 변경 사항을 추적하거나 특정 시점으로 되돌아가기 위해 매우 중요합니다. 또한, 빌드 결과물이나 개인적인 설정 파일 등 버전 관리에 포함되어서는 안 되는 파일들을 사전에 차단하는 설정도 필수적입니다.

이번 포스팅에서는 git log를 활용한 히스토리 분석 기법과 .gitignore 파일을 통한 파일 추적 제외 방법에 대해 자세히 알아보겠습니다.

1. Git 히스토리 조회: git log

지금까지 프로젝트에서 남긴 모든 커밋 내역을 확인하려면 git log 명령어를 사용합니다. 이 명령어를 인자 없이 실행하면 가장 최근의 커밋부터 시간의 역순으로 상세한 정보가 출력됩니다.

$ git log
commit ca82a6dff817ec66f44342007202690a93763949 (HEAD -> master)
Author: Hong Gil Dong <hong@example.com>
Date:   Mon Oct 2 14:23:01 2023 +0900

    feat: 로그인 기능 추가

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Hong Gil Dong <hong@example.com>
Date:   Mon Oct 2 10:11:35 2023 +0900

    docs: 프로젝트 README 파일 추가

출력된 내용을 보면 각 커밋의 고유한 해시값(SHA-1 체크섬), 작성자의 이름과 이메일, 커밋 일시, 그리고 커밋 메시지가 명확하게 나타납니다. (HEAD -> master)는 현재 우리가 바라보고 있는 작업 위치가 master 브랜치의 최신 커밋임을 알려줍니다.

다양한 옵션으로 로그 포맷팅하기

프로젝트 규모가 커져 커밋이 수백 개 이상 쌓이면, 기본 git log 출력 방식으로는 내용을 파악하기 어렵습니다. Git은 로그를 원하는 형태로 가공할 수 있는 강력한 옵션들을 제공합니다.

1. --oneline: 각 커밋을 딱 한 줄로 요약하여 출력합니다. 해시값의 앞 7자리와 커밋 메시지만 표시되어 전체적인 흐름을 빠르게 훑어볼 때 유용합니다.
2. -p (또는 --patch): 각 커밋에서 실제로 어떤 파일의 어느 코드가 추가되고 삭제되었는지 상세한 차이점(diff)을 함께 보여줍니다. 코드 리뷰 시 매우 자주 사용됩니다.
3. --stat: 각 커밋마다 몇 개의 파일이 변경되었고, 각 파일에서 몇 줄이 추가/삭제되었는지 요약된 통계를 제공합니다.
4. --graph: 브랜치가 분기되고 병합되는 과정을 ASCII 문자를 활용해 시각적인 그래프 형태로 보여줍니다.

# 여러 옵션을 조합하여 시각적이고 요약된 히스토리 출력
$ git log --oneline --graph --all
* ca82a6d (HEAD -> master) feat: 로그인 기능 추가
* 085bb3b docs: 프로젝트 README 파일 추가

2. 불필요한 파일 추적 제외: .gitignore

개발을 진행하다 보면 IDE(통합 개발 환경)가 자동으로 생성하는 설정 파일, 언어별 패키지 매니저가 다운로드한 방대한 라이브러리 폴더(예: node_modules), 컴파일된 빌드 결과물, 데이터베이스 비밀번호가 담긴 환경변수 파일 등 버전 관리 시스템에 포함되어서는 안 되는 파일들이 생겨납니다. 이러한 파일들을 실수로 커밋하는 것을 방지하기 위해 .gitignore 파일을 활용합니다.

프로젝트 최상위 디렉토리에 .gitignore라는 이름의 숨김 파일을 생성하고, 무시할 파일이나 폴더의 패턴을 작성해두면 Git은 해당 파일들을 추적(Tracking) 대상에서 영구적으로 제외합니다. 즉, git status를 입력해도 Untracked files 목록에 나타나지 않으며, git add .를 실행해도 스테이징 영역에 올라가지 않습니다.

.gitignore 작성 문법 (Glob 패턴)

.gitignore 파일 내부는 일종의 정규 표현식과 유사한 Glob 패턴을 사용하여 작성합니다.

• 아무것도 없는 빈 줄이나 #으로 시작하는 줄은 주석으로 처리됩니다.
• / 기호를 끝에 붙이면 디렉토리(폴더)를 의미합니다. (예: build/는 build 폴더 안의 모든 것을 무시합니다.)
• * 기호는 문자가 하나도 없거나 하나 이상인 경우를 모두 매칭합니다. (예: *.log는 확장자가 log인 모든 파일을 무시합니다.)
• ! 기호는 무시 대상에서 예외로 처리할 때 사용합니다. (예: *.log로 모든 로그를 무시하되, !important.log를 추가하면 important.log 파일만은 추적합니다.)

# .gitignore 파일 예시

# 운영체제 생성 파일 무시
.DS_Store
Thumbs.db

# 특정 확장자 파일 전체 무시
*.class
*.log

# 특정 폴더 내부 전체 무시 (예: Node.js 패키지 폴더)
node_modules/

# 보안이 중요한 환경변수 파일 무시
.env
secret.json

주의: 이미 추적 중인 파일은 .gitignore에 추가해도 무시되지 않습니다.
실수로 한 번이라도 커밋이 되어 Git이 이미 추적(Tracking)하고 있는 파일은 나중에 .gitignore에 추가하더라도 계속 추적됩니다. 이 경우 캐시된 인덱스에서 파일을 먼저 삭제해야 합니다.
명령어: git rm -r --cached <파일명 또는 폴더명>

1. 원격 저장소란 무엇인가?

원격 저장소는 인터넷이나 네트워크 어딘가에 호스팅되어 있는 Git 저장소입니다. 여러 명의 개발자가 하나의 프로젝트를 함께 진행하기 위해서는 서로의 변경 사항을 공유할 중앙 허브가 필요한데, 원격 저장소가 바로 이 역할을 수행합니다.

대표적인 원격 저장소 호스팅 서비스로는 GitHub, GitLab, Bitbucket 등이 있습니다. 이 서비스들은 단순히 코드를 저장하는 것을 넘어, 코드 리뷰, 이슈 트래킹, CI/CD 파이프라인 등 협업에 필요한 방대한 도구들을 함께 제공합니다. 실무에서는 이러한 호스팅 서비스를 기반으로 팀 단위 개발이 이루어집니다.

2. 원격 저장소 연결하기: git remote

GitHub와 같은 서비스에서 새로운 원격 저장소(Repository)를 생성하면 보통 https://github.com/username/project.git 형태의 URL이 부여됩니다. 내 컴퓨터의 로컬 저장소에 이 URL을 알려주고 서로 연결하는 작업이 필요합니다.

기존 로컬 저장소에 원격 저장소 추가

git remote add 명령어를 사용하여 로컬 저장소에 원격 저장소를 등록합니다. 이때 원격 저장소의 URL을 매번 입력하기 번거로우므로, 보통 origin이라는 단축 이름을 부여하여 사용합니다. origin은 Git에서 기본적으로 사용하는 관례적인 원격 저장소 이름입니다.

# 원격 저장소 추가 (이름: origin, 주소: URL)
$ git remote add origin https://github.com/my-id/my-project.git

# 연결된 원격 저장소 목록 확인
$ git remote -v
origin  https://github.com/my-id/my-project.git (fetch)
origin  https://github.com/my-id/my-project.git (push)

-v(verbose) 옵션을 사용하면 설정된 원격 저장소의 이름과 단축 URL을 자세히 확인할 수 있습니다. 읽기용(fetch)과 쓰기용(push) URL이 각각 표시됩니다.

원격 저장소를 통째로 가져오기: git clone

만약 로컬에 아직 저장소를 만들지 않았고, GitHub에 이미 존재하는 프로젝트에 새롭게 참여하는 상황이라면 git clone 명령어를 사용합니다. 이 명령어는 원격 저장소의 모든 데이터(히스토리, 브랜치 등)를 로컬로 복제해 오며, git init과 git remote add origin 작업을 내부적으로 알아서 처리해 줍니다.

# 원격 저장소 전체 복제
$ git clone https://github.com/my-id/my-project.git
Cloning into 'my-project'...

3. 로컬 코드를 원격으로 올리기: git push

로컬에서 파일 수정 후 커밋을 완료했다면, 이 변경된 버전을 원격 저장소에 업로드하여 다른 팀원들과 공유해야 합니다. 이때 사용하는 명령어가 git push입니다.

# 원격 저장소(origin)의 master 브랜치로 로컬 커밋 내역 전송
$ git push origin master
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 302 bytes | 302.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/my-id/my-project.git
   ca82a6d..7e81b9c  master -> master

이 명령어를 처음 실행할 때는 -u (또는 --set-upstream) 옵션을 함께 사용하는 것이 좋습니다(예: git push -u origin master). 이렇게 하면 로컬 브랜치와 원격 브랜치가 서로 매핑되어, 다음부터는 단순히 git push만 입력해도 지정된 원격 브랜치로 자동 업로드됩니다.

4. 원격 코드를 로컬로 가져오기: git pull과 git fetch

다른 팀원이 원격 저장소에 코드를 Push했다면, 내 로컬 저장소는 최신 상태가 아니게 됩니다. 작업을 이어가기 전에 반드시 원격 저장소의 최신 코드를 내 컴퓨터로 내려받아야 합니다.

git fetch

git fetch는 원격 저장소의 최신 이력을 로컬로 가져오기만 하고, 내 워킹 디렉토리의 파일들과 자동으로 병합(Merge)하지는 않습니다. 즉, "원격에 어떤 변화가 생겼는지 데이터만 다운로드" 하는 안전한 명령어입니다. 다운로드한 변경 사항을 확인한 후 수동으로 병합할지 결정할 때 사용합니다.

git pull

실무에서 가장 많이 사용하는 git pull 명령어는 git fetch와 git merge를 연달아 수행하는 것과 같습니다. 원격 저장소의 최신 내용을 다운로드함과 동시에, 현재 작업 중인 내 로컬 코드에 그 변경 사항들을 자동으로 병합해 줍니다.

# 원격 저장소(origin)의 master 브랜치 내용을 가져와 자동 병합
$ git pull origin master
Updating ca82a6d..7e81b9c
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+)

협업 시나리오의 핵심: Pull 먼저, Push는 나중에
내가 수정한 코드를 git push 하려는데, 그 사이에 다른 팀원이 먼저 코드를 push 했다면 Git은 업로드를 거부(Reject)합니다. 원격 저장소의 상태가 내 로컬 상태보다 더 진척되어 있기 때문입니다. 이런 경우에는 반드시 git pull을 먼저 수행하여 팀원의 코드를 내 로컬로 가져와 합친(병합) 후, 다시 git push를 진행해야 합니다.