푸시 — git push의 개념, 작동 방식 및 필요한 경우

Git에서 푸시란

Git push는 로컬 저장소에서 원격 저장소로 커밋을 전송하는 명령어입니다. 변경 사항을 개발자의 로컬 머신에만 저장하는 commit과 달리, 푸시는 해당 변경 사항을 전체 팀에 공개합니다. Push는 Pull Request 생성 및 배포 전 필수 단계입니다.

Git의 아키텍처는 각 개발자가 자신의 로컬 저장소에서 작업한다고 가정합니다. 커밋은 로컬에서 생성되고 개발자가 푸시하기로 결정할 때까지 축적됩니다. 이는 자유를 제공합니다: 많은 로컬 커밋을 만들고, 실험하고, 동료에게 영향을 주지 않고 기록을 다시 쓸 수 있습니다.

# origin 원격, main 브랜치로 푸시
git push origin main

# 현재 브랜치를 upstream과 함께 원격으로 푸시
git push -u origin feature/new-dashboard

# 일치하는 이름의 모든 브랜치 푸시
git push --all origin

# 리스가 있는 강제 푸시(안전한 강제 푸시)
git push --force-with-lease

푸시 후 원격 저장소는 refs(브랜치 참조)를 업데이트하여 새 커밋을 가리키도록 합니다. 다른 개발자는 git pull 또는 git fetch를 통해 이러한 변경 사항을 가져올 수 있습니다. 이러한 커밋 교환은 협업 개발의 기초를 형성합니다.

git push의 작동 방식

git push 명령어는 로컬 및 원격 브랜치를 비교하고 누락된 커밋만 전송합니다. Git은 모든 파일을 다시 보내지 않고 델타만 전송하므로 대규모 저장소에서도 푸시가 빠릅니다. Git 프로토콜은 스마트 전송을 사용하여 전송되는 데이터 양을 최소화합니다.

원격 브랜치에 로컬에 없는 커밋이 포함된 경우 푸시가 거부됩니다. 이는 변경 사항 손실을 방지하는 보호 메커니즘입니다. 이러한 상황에서 개발자는 먼저 git pull을 실행하고, 변경 사항을 병합한 다음 다시 푸시해야 합니다. 대안은 원격 브랜치를 덮어쓰는 강제 푸시이지만 주의해서 사용해야 합니다.

원격 저장소를 이해하는 것이 올바른 푸시의 핵심입니다. 일반적으로 origin이 기본 원격 저장소 이름입니다. git remote -v 명령어는 원격 저장소와 해당 URL 목록을 표시합니다. 여러 개의 원격을 추가할 수 있습니다(예: 주 저장소용 origin과 포크용 upstream).

변경 사항을 푸시해야 하는 경우

기본 규칙: 논리적으로 완료된 각 작업 단계 후에 푸시합니다. 개발자가 작업 또는 그 일부를 완료했다면 푸시할 때입니다. 그러나 빌드를 손상시키는 미완료 작업을 푸시하는 것은 권장되지 않습니다. 빌드가 깨지지 않음은 모든 브랜치에 푸시하기 위한 최소 요구 사항입니다.

팀 개발에서는 다음과 같은 리듬이 채택됩니다: 아침 — 동료의 변경 사항을 가져오기 위해 git pull, 낮 동안 — 여러 번의 커밋과 한두 번의 푸시, 저녁 — 완료된 모든 작업의 최종 푸시. 개발자가 푸시를 자주 할수록 병합 충돌 위험이 줄어들고 작업 진행 상황이 더 투명해집니다.

• 작업 완료 후 — 커밋하고 최종 솔루션을 기능 브랜치에 푸시
• 퇴근 전 — 미완료 작업을 기능 브랜치에 푸시(main에는 하지 마세요!)
• PR 생성 전 — 모든 커밋이 푸시되어 검토 가능한지 확인
• 리베이스 후 --force-with-lease로 자신의 기능 브랜치에 푸시

안전한 푸시 규칙

안전한 푸시는 팀 내 데이터 손실과 충돌을 방지하는 일련의 규칙입니다. 첫 번째이자 가장 중요한 규칙: 프로젝트에 직접 배포가 구성되지 않은 경우 main 또는 master 브랜치에 직접 푸시하지 마십시오. 현대 팀에서는 main 브랜치 보호가 GitHub 브랜치 보호 수준에서 구성됩니다.

두 번째 규칙: 푸시 전에 원격 브랜치와 동기화합니다. 병합 시 병합 커밋을 피하기 위해 git pull --rebase를 실행합니다. 이렇게 하면 기록이 단순해지고 선형적으로 유지됩니다. 푸시가 거부되면 — 단순한 강제 푸시를 사용하지 말고 먼저 원격 브랜치에 어떤 커밋이 나타났는지 확인합니다.

세 번째 규칙: 전송 전에 자동으로 테스트와 린터를 실행하는 pre-push 훅을 설정합니다. 테스트가 실패하면 푸시가 차단됩니다. 이러한 훅은 Husky 또는 Git 훅(.git/hooks의 pre-push 파일)을 통해 구성됩니다.

네 번째 규칙: 큰 바이너리 파일을 푸시하지 마십시오. Git은 바이너리 아티팩트 저장용으로 설계되지 않았습니다 — 저장소를 부풀리고 작업을 느리게 합니다. 큰 파일의 경우 Git LFS(Large File Storage)를 사용하십시오. 바이너리가 이미 푸시되어 기록에 있는 경우 git filter-branch를 통해 제거해야 합니다.

푸시 실패 시 대처 방법

푸시 실패의 가장 일반적인 원인은 원격 브랜치에 로컬에 없는 커밋이 포함되어 있기 때문입니다. 이는 다른 개발자가 동일한 브랜치에 변경 사항을 푸시한 경우 발생합니다. 해결책: git pull을 실행하고, 충돌을 해결한 다음 다시 푸시합니다.

# 푸시 거부됨 — 먼저 fetch와 rebase 실행
git fetch origin
git rebase origin/main
# 충돌 해결 후:
git push --force-with-lease

# 또는 원격 변경 사항을 병합
git pull origin main
git push

두 번째 원인 — 브랜치에 대한 쓰기 권한 부족. main 브랜치가 브랜치 보호 규칙으로 보호되는 경우 직접 푸시가 금지됩니다. 해결책: 기능 브랜치에 푸시하고 Pull Request를 생성합니다. 보호 설정은 일반적으로 GitHub 설정 또는 GitLab 보호 브랜치를 통해 관리됩니다.

세 번째 원인 — 인증 문제. 오래된 자격 증명, SSH로 전환 또는 개인 액세스 토큰 변경. 해결책: 원격 URL(git remote -v)을 확인하고 자격 증명을 업데이트합니다. 2021년부터 GitHub는 HTTPS에 대한 비밀번호 인증을 중단했습니다 — 개인 토큰 또는 SSH 키를 사용하십시오.