브랜치와 .gitignore
Git의 핵심 기능인 브랜치를 사용하여 안전하게 기능을 개발하고, .gitignore로 불필요한 파일을 제외하는 방법을 실습합니다.
교무실 업무로 비유하면 브랜치는 원본 서류철을 바로 고치지 않고 별도 작업대에서 초안을 만드는 방식입니다. .gitignore는 공용 캐비닛에 넣지 않을 개인 메모, 임시 파일, 비밀 자료 목록입니다.
이 글에서 할 것
- 브랜치 만들고 전환하기
- 브랜치 병합하기
- .gitignore 설정하기
- 실전 팁 익히기
준비물
실습 1: 브랜치 이해
브랜치란?
브랜치는 코드의 독립적인 작업 흐름입니다. 원본 main을 바로 고치지 않고, 새 기능이나 수정 작업을 별도 공간에서 진행할 때 유용합니다.
사무 업무로 치면 main은 이미 공유 중인 공식 서류철이고, 새 브랜치는 그 서류철을 복사해 만든 임시 작업대입니다. 초안이 괜찮아지면 나중에 공식 서류철로 합칩니다.
예시:
main: 안정적인 공식 서류철feature-login: 로그인 기능을 따로 작업하는 초안 파일철bugfix-error: 오류 수정을 따로 진행하는 임시 작업대
실습 2: 브랜치 실습
현재 브랜치 확인
* 표시가 현재 내가 서 있는 브랜치입니다. 지금은 공식 서류철인 main에서 작업 중이라는 뜻입니다.
새 브랜치 만들기
feature-login이라는 새 작업대를 만듭니다. 아직 이동한 것은 아니고, 작업대 이름만 만들어 둔 상태입니다.
브랜치 전환
이제 실제로 feature-login 작업대로 이동합니다. 이후 커밋은 main이 아니라 이 브랜치에 쌓입니다.
참고: 예전 문법은 git checkout feature-login입니다.
브랜치에서 작업
파일 확인
주의: login.txt가 없습니다. 파일이 사라진 것이 아니라, main 브랜치에는 아직 그 커밋이 들어오지 않았기 때문입니다. 다시 feature-login으로 이동하면 보입니다.
병합 (Merge)
merge는 별도 작업대에서 완성한 초안을 공식 서류철인 main에 합치는 일입니다. 아래 예시는 main에서 새로운 수정이 없었기 때문에 빠르게 앞으로 이동하는 Fast-forward 병합입니다.
브랜치 삭제
작업 내용이 main에 합쳐졌다면 임시 작업대 이름은 지워도 됩니다. 커밋 자체가 사라지는 것이 아니라, 이미 main에 들어간 작업대 이름만 정리하는 것입니다.
실습 3: .gitignore 설정
.gitignore 파일 만들기
.gitignore는 Git에게 “이 파일들은 공용 기록에 넣지 말라”고 알려 주는 목록입니다. 예를 들어 개인 설정 파일, 비밀번호가 담긴 .env, 자동으로 생기는 로그 파일은 보통 공유하지 않습니다.
중요한 점은 .gitignore가 앞으로 새로 추적될 파일에 적용된다는 것입니다. 이미 커밋된 파일은 .gitignore에 추가해도 자동으로 빠지지 않으므로, 필요한 경우 git rm --cached 파일명으로 추적을 끊어야 합니다.
주의: test.log가 표시되지 않습니다. .gitignore에 *.log를 적어 두었기 때문에 Git이 로그 파일을 일부러 무시한 것입니다.
.gitignore 커밋
.gitignore 파일 자체는 팀원도 같이 알아야 하는 규칙입니다. 그래서 .gitignore는 커밋하고, .gitignore에 적힌 파일들은 커밋하지 않는다고 구분하면 됩니다.
실습 4: 실전 팁 10가지
1. 상태 자주 확인하기
git status
2. 의미 있는 커밋 메시지
git commit -m "로그인 버튼 스타일 수정"
3. 작은 단위로 자주 커밋
- 한 기능 또는 한 수정 = 한 커밋
- “출석부 양식 수정”, “오타 수정”처럼 나중에 읽히는 단위로 나누기
4. diff로 변경사항 확인
git diff
5. push 전에 pull 먼저
git pull
git push
공용 캐비닛에 누군가 최신본을 올렸을 수 있으니, 내가 올리기 전에 먼저 최신본을 가져오는 습관입니다. 충돌이 생기면 파일을 열어 어느 내용을 남길지 정리해야 합니다.
6. 충돌 해결
git pull
# 충돌 파일 수정
git add 충돌_파일명
git commit -m "충돌 해결"
7. 임시 저장 (Stash)
git stash # 임시 저장
git stash pop # 복원
8. 커밋 취소
git reset --soft HEAD~1 # 마지막 커밋 취소 (변경은 유지)
아직 GitHub에 올리지 않은 마지막 커밋을 고칠 때만 사용하세요. 이미 공유한 커밋은 기록을 지우기보다 git revert처럼 되돌리는 새 커밋을 만드는 편이 안전합니다.
9. 간략 로그
git log --oneline --graph
10. 도움말
git help 명령어
git 명령어 --help
AI 도구에 이렇게 요청해도 됩니다
브랜치, merge, .gitignore는 기록을 바꾸는 작업과 연결됩니다. AI에게 맡길 때는 현재 상태 확인과 실행 전 허락을 꼭 넣으세요.
feature-login 브랜치를 만들거나 main에 합치기 전에 현재 상태를 확인해줘.
git status와 브랜치 차이를 설명하고, branch 생성/switch/merge는 내가 승인한 뒤 실행해줘.
이 프로젝트의 .gitignore를 점검해줘.
이미 추적 중인 파일은 .gitignore만으로 빠지지 않는다고 설명하고, git rm --cached 실행 전에는 파일 경로와 의미를 확인받아줘.
민감한 파일을 커밋한 것 같아.
기록 삭제, rebase, filter-branch, 강제 push는 실행하거나 제안하지 말고, 먼저 토큰/비밀번호 폐기와 안전한 대응 순서를 알려줘.
merge 충돌이 생기면 AI가 자동으로 “내 것/상대 것”을 고르게 하지 말고, 어떤 내용을 남길지 사람이 판단하게 하세요.
실수 대처
왜 생기나요?
내 컴퓨터 저장소와 GitHub 저장소가 서로 다른 시작 기록을 가지고 있을 때 생깁니다. 예를 들어 GitHub에서 README를 만든 뒤, 내 컴퓨터에서도 따로 git init을 한 경우입니다.
해결:
git pull --allow-unrelated-histories
처음 연결할 때만 필요한 경우가 많습니다. 왜 생겼는지 모르겠다면 명령어를 바로 실행하기보다 저장소 생성 과정을 먼저 확인하세요.
"error: failed to push"
왜 생기나요?
GitHub 쪽에 내 컴퓨터에 없는 최신 커밋이 있을 때 자주 생깁니다.
해결:
git pull origin main
git push origin main
pull 중 충돌이 생기면 파일을 먼저 정리하고, 정리한 파일만 git add 충돌_파일명으로 올린 뒤 커밋하고 다시 push합니다.
실수로 중요한 파일을 커밋했어요
비밀번호나 개인정보가 들어 있는 파일이라면 단순히 .gitignore에 추가하는 것만으로 과거 기록에서 사라지지는 않습니다. 이미 GitHub에 올렸다면 토큰이나 비밀번호를 즉시 폐기하고 새로 발급하는 것이 먼저입니다.
해결:
# .gitignore에 추가
echo "파일명" >> .gitignore
# 캐시에서 제거
git rm --cached 파일명
git commit -m "민감한 파일 제거"
이 명령은 앞으로 추적하지 않게 만드는 조치입니다. 이미 공유된 기록 자체를 완전히 지우는 작업은 별도 절차가 필요하므로, 민감한 파일은 처음부터 커밋하지 않는 것이 가장 안전합니다.
Git 시리즈 완료!
Git 시리즈를 모두 완료했습니다! 이제 코드 버전 관리의 기초를 익혔습니다.
처음에는 명령어가 낯설지만, 흐름은 단순합니다. 내 책상에서 작업하고, 의미 있는 시점마다 커밋하고, 필요하면 별도 브랜치에서 실험하고, GitHub 공용 자료함과 push/pull로 맞추면 됩니다.
지금까지 배운 내용:
- Git이 필요한 이유
- 설치와 기본 설정
- 저장소 만들고 커밋하기
- GitHub 연동
- 브랜치와 .gitignore
다음 학습 추천:
- GitHub 협업: Pull Request, Code Review
- Git 고급: Rebase, Cherry-pick
- CI/CD: GitHub Actions
Git 시리즈 목록
실습 완료 체크리스트
💬 댓글
이 글에 대한 의견을 남겨주세요