이 글에서는 Git의 기본 작업 흐름을 익힌 뒤 만나게 되는 세 가지 주제를 살펴봅니다. 저장소를 만드는 방법(git init 또는 IDE 사용), rebase와 merge의 차이, 그리고 실수로 이력에 들어간 비밀 정보를 제대로 제거하는 방법입니다. 세 가지 모두 Claude Code와 함께 일할 때도 유용합니다. Claude Code가 이런 작업을 명령으로 수행하므로, 그 뒤에서 무슨 일이 일어나는지 이해하는 편이 좋습니다.
예시와 화면 캡처는 JetBrains IDE 기준입니다. 사용 중인 버전에 따라 작업 이름과 위치가 다를 수 있습니다. 연습할 때는 별도의 학습용 저장소를 사용하세요. 실제 프로젝트에서는 브랜치, 커밋, 변경 사항 전송에 관한 프로젝트 규칙을 따르세요.
저장소 만들기 - git init과 IDE
프로젝트가 이미 GitHub에 있다면 clone할 수 있습니다. 로컬 폴더에 코드가 있는 경우도 있죠. git init은 그 폴더에 Git 관리 데이터를 만들지만 첫 커밋까지 만들지는 않습니다. 아래 예시에서는 README.md와 .gitignore를 이미 만들고 확인했다고 가정합니다. 나머지 필요한 파일은 따로 추가합니다.
git init
git status
# README와 무시 규칙을 확인한 뒤
git add README.md .gitignore
git diff --cached
git commit -m "Initial commit"로컬 저장소를 만들려면 IDE에서 Git 저장소를 만들거나 버전 관리를 켜세요. Share Project on GitHub은 별도의 흐름입니다. 원격 저장소도 만들고 변경 사항을 push하도록 제안합니다. push하기 전에 선택된 파일과 이력, 공개 범위를 확인하세요.
Public 또는 private
저장소를 만들 때 공개 범위를 선택합니다.
- public - 인터넷의 모든 사람이 저장소와 코드를 볼 수 있습니다. 포트폴리오와 오픈 소스 프로젝트에 적합합니다.
- private - 본인과 초대한 사람만 접근할 수 있습니다. 공개할 수 없는 업무용 또는 학습용 코드라면 기본적으로 이 설정을 선택하세요.
공개 범위는 나중에 GitHub의 저장소 설정에서 바꿀 수 있습니다.
Claude Code가 대신 git init을 실행하고 첫 커밋을 준비할 수 있습니다. GitHub에 저장소가 아직 없다면 GitHub CLI(gh repo create)로 만들 수도 있습니다. 이때 저장소를 public으로 할지 private으로 할지는 직접 선택하세요.
rebase와 merge의 차이
merge와 rebase는 모두 한 브랜치의 작업을 다른 브랜치에 반영합니다. 방식은 서로 다르며, 그 차이가 프로젝트 이력의 모양을 결정합니다.
merge는 이력을 합칩니다. 두 브랜치가 서로 다른 방향으로 진행됐다면 보통 부모가 둘인 merge commit이 생깁니다. 현재 브랜치가 다른 브랜치의 조상이라면 Git은 새 커밋 없이 fast-forward할 수도 있습니다. 아래 다이어그램은 브랜치가 갈라진 경우를 보여 줍니다.
merge는 두 흐름을 모두 남기고 merge commit을 추가합니다. 이력에서 feature 브랜치가 따로 있었다는 점이 그대로 드러납니다.
rebase는 대상 브랜치의 최신 커밋에서 작업을 시작한 것처럼 여러분의 커밋을 옮깁니다. 이력은 하나의 직선처럼 이어집니다. 대신 대가가 있습니다. rebase는 커밋을 다시 씁니다. 기존 커밋 대신 해시가 다른 새 커밋이 생깁니다.
rebase 후에는 C와 D가 E 위에서 만들어진 것처럼 보입니다. 이력은 선형이지만, 해시가 다른 새 커밋(C2, D2)입니다.
어떤 방식을 고를까요?
- merge - 실제 작업 이력을 보존해야 하거나 여러 사람이 함께 쓰는 브랜치라면 선택하세요. 기본적으로 안전한 선택입니다.
- rebase - pull request를 만들기 전에 개인 브랜치를 정리할 때 사용하세요. 선형 이력은 읽기 쉽습니다.
rebase를 익히는 동안에는 아직 공유하지 않은 개인 브랜치에서 사용하세요. 다른 사람이 이미 쓰는 브랜치의 이력을 다시 쓰려면 합의된 절차를 따라야 합니다. 그렇지 않으면 동료에게 이전 이력이 남습니다. 결과가 확실하지 않다면 멈추고 프로젝트 규칙을 확인하세요.
병합 방식은 작업 내용과 프로젝트 규칙에 따라 정하세요. 에이전트의 기본 선택을 짐작해서 맡기지 말고, 실행 전에 대상 브랜치와 작업, 이력에 미칠 영향을 알려 달라고 하세요.
저장소 이력에서 비밀 정보 제거하기
새 커밋에서 파일을 삭제해도 이전 커밋에 들어간 비밀 정보까지 사라지지는 않습니다. 비밀번호나 토큰이 다른 사람에게 노출됐다면 먼저 발급한 서비스에서 폐기하거나 교체하세요. 이력을 정리해도 이미 만들어진 복사본까지 없앨 수는 없습니다.
공유 이력을 정리하는 일을 일반적인 파일 수정처럼 진행하지 마세요. 커밋 ID가 바뀌므로 조율이 필요합니다. 이전 브랜치의 push를 멈추고, 영향을 받는 모든 경로를 찾고, 별도 복사본에서 결과를 확인한 뒤 동료의 복사본을 갱신하는 방법까지 합의하세요.
이력을 정리하는 절차로 GitHub는 git-filter-repo를 안내합니다. 구체적인 명령은 파일 전체를 지울지, 비밀 문자열을 교체할지, 문자열이 어디에 있었고 이력이 어디까지 전파됐는지에 따라 달라집니다. 새 복사본 만들기, 결과 확인, 원격 참조 갱신, 동료가 해야 할 일까지 포함해 민감한 데이터 제거 공식 가이드를 따르세요.
로컬 복사본만 정리해서는 서버가 바뀌지 않습니다. 이력을 다시 쓴 뒤 강제로 push하는 일은 별도로 합의해야 합니다. 여기서 모든 브랜치에 적용할 만능 명령을 실행할 필요는 없습니다. 다른 사람의 clone이나 fork에 있는 복사본은 여러분이 통제할 수 없습니다. GitHub에서 접근 가능한 링크와 캐시는 같은 가이드의 Support 문의 조건을 따르세요.
같은 일이 다시 일어날 가능성을 줄이려면 다음을 확인하세요.
- 비밀 값은 코드 밖에 보관하세요. 예를 들어 환경 변수를 사용할 수 있습니다.
.env같은 로컬 파일은 Git이 추적하기 전에.gitignore에 추가하세요.- 커밋 전에 선택한 파일과
git diff --cached결과를 확인하세요. - 저장소에서 secret scanning과 push protection을 사용할 수 있다면 추가 검사 수단으로 켜 두세요. 다만 이 기능이 모든 비밀 정보를 찾아내지는 못합니다.
에이전트는 영향을 받은 경로를 찾고 정리 계획을 준비하는 일을 도울 수 있습니다. 검색을 위해 유효한 비밀 정보를 채팅에 붙여 넣지 마세요. 먼저 접근 권한을 폐기하고, 그다음 이력 정리 작업을 조율하세요.
Claude Code와 함께 사용할 때
Claude Code가 저장소에서 작업할 때도 이 세 가지가 모두 등장합니다. 다음을 확인하세요.
- 저장소를 초기화(
git init)하고 첫 커밋을 준비할 수 있습니다. GitHub에서 만들 때 public과 private 중 하나는 직접 고르세요. - 프로젝트 규칙에 맞는 병합 방식을 제안합니다. 실행 전에 merge와 rebase의 결과를 확인하세요.
- 커밋에 포함될 파일을 확인할 수 있지만, 비밀 정보가 들어가지 않도록 마지막으로 점검할 책임은 여러분에게 있습니다.
커밋 전에 파일 목록과 diff에 표시된 내용을 모두 확인하세요. 비밀 정보는 .env뿐 아니라 일반 소스 파일에도 있을 수 있습니다. 이미 이력에 들어갔다면 먼저 해당 비밀 정보를 교체한 뒤 이력을 정리할지 판단하세요.
GO TO FULL VERSION