Git 브랜치 완벽 가이드: 생성, 전환, 삭제

Git 브랜칭을 사용하면 메인 개발 라인을 방해하지 않고 기능, 수정 또는 실험을 진행할 수 있습니다. 좋은 브랜치 습관은 변경 사항을 체계적으로 유지하고 리뷰, 테스트 및 롤백을 훨씬 쉽게 만듭니다.

브랜치는 커밋을 가리키는 가벼운 포인터입니다. 즉, 생성, 전환 및 삭제가 빠르지만, 선택한 방식이 프로젝트 기록의 명확성에 영향을 미칩니다.

Git 브랜치란?

Git 브랜치는 커밋을 가리키는 이동 가능한 이름입니다. 브랜치에서 새 작업을 커밋하면 Git은 해당 브랜치 이름을 새 커밋으로 앞으로 이동시킵니다.

대부분의 프로젝트에는 main 또는 master와 같은 기본 브랜치가 있습니다. 팀은 일반적으로 해당 브랜치를 안정적으로 유지한 다음 특정 작업을 위해 단기 브랜치를 만듭니다:

git switch -c fix-login-timeout

이 명령은 새 브랜치를 생성하고 전환합니다. 이전 Git 예제에서는 다음을 사용할 수 있습니다:

git checkout -b fix-login-timeout

두 패턴 모두 일반적이지만 git switch는 브랜치 이동에만 초점을 맞추기 때문에 더 읽기 쉽습니다.

브랜치 이름은 작업을 설명할 수 있을 만큼 구체적이어야 합니다. feature는 너무 모호합니다. feature/add-health-check-endpoint 또는 fix/nginx-502-upstream-timeout이 훨씬 좋습니다. 명확한 이름은 파일을 열기 전에 브랜치를 이해하는 데 도움이 됩니다.

브랜치 생성 및 전환

브랜치를 생성하기 전에 올바른 기준점에서 시작하세요. 대부분의 팀의 경우 기본 브랜치를 먼저 업데이트하는 것을 의미합니다:

git switch main
git pull
git switch -c feature/add-metrics-endpoint

이렇게 하면 새 브랜치가 오래된 코드에서 시작할 가능성이 줄어듭니다. 충돌을 완전히 제거하지는 않지만 더 깔끔한 시작점을 제공합니다.

로컬 브랜치를 나열하려면 다음을 실행하세요:

git branch

현재 브랜치 옆에는 별표가 표시됩니다. 원격 브랜치도 보려면 다음을 사용하세요:

git branch -a

기존 브랜치로 전환하려면:

git switch branch-name

브랜치가 원격에만 존재하는 경우 일반적으로 다음 명령으로 로컬 추적 브랜치를 만들 수 있습니다:

git switch --track origin/branch-name

추적은 로컬 브랜치를 원격 브랜치와 연결하기 때문에 중요합니다. 추적이 설정되면 git pull 및 git push와 같은 간단한 명령이 사용할 원격 브랜치를 알 수 있습니다.

구체적인 시나리오를 상상해보세요. 더 큰 Docker 이미지 정리 작업을 진행하면서 Jenkins 파이프라인 실패를 패치해야 합니다. 이러한 변경 사항을 별도의 브랜치에 넣으세요. 긴급 패치는 신속하게 검토 및 병합될 수 있으며, 더 큰 정리 작업은 이를 차단하지 않고 계속 진행될 수 있습니다.

관련 기본 사항은 Git 저장소 시작하기를 참조하세요.

브랜치 정리 유지

브랜치가 너무 오래 열려 있거나 관련 없는 변경 사항이 축적되면 지저분해집니다. 가장 좋은 브랜치는 일반적으로 작고 집중적이며 검토하기 쉽습니다.

하나의 브랜치를 하나의 목적으로 사용하세요:

• 버그 수정 브랜치에는 수정 사항과 관련 테스트가 포함되어야 합니다.
• 기능 브랜치에는 기능이 포함되어야 하며, 우연한 리팩터링이 포함되지 않아야 합니다.
• 정리 브랜치는 명확히 정리의 일부가 아닌 한 동작 변경을 피해야 합니다.

푸시하기 전에 작업을 확인하세요:

git status
git diff --staged

이렇게 하면 실수로 추가된 파일과 관련 없는 편집 내용을 잡을 수 있습니다. 생성된 파일, 로컬 구성 및 비밀 템플릿이 실제 소스 파일 근처에 있을 수 있는 DevOps 저장소에서 특히 유용합니다.

브랜치에 main의 최신 변경 사항이 필요한 경우 두 가지 일반적인 옵션이 있습니다:

git merge main

또는:

git rebase main

병합은 정확한 브랜치 기록을 유지합니다. 리베이스는 브랜치 커밋을 최신 기준 위에 다시 작성합니다. 둘 다 유용하지만 팀은 공유 작업을 병합하기 전에 어떤 스타일을 기대하는지 합의해야 합니다. 확실하지 않은 경우 프로젝트에서 문서화된 워크플로우를 선호하세요.

브랜치 안전하게 삭제

오래된 브랜치를 삭제하면 저장소를 더 쉽게 탐색할 수 있습니다. 브랜치가 병합된 후 다음 명령으로 로컬 복사본을 삭제하세요:

git branch -d branch-name

소문자 -d가 더 안전한 옵션입니다. Git은 작업이 병합되지 않았다고 판단하면 브랜치 삭제를 거부합니다.

병합되지 않은 로컬 브랜치를 정말로 삭제해야 하는 경우 다음을 사용하세요:

git branch -D branch-name

주의해서 사용하세요. 커밋이 병합되지 않았더라도 브랜치 이름을 제거합니다. 커밋은 reflog를 통해 잠시 동안 복구될 수 있지만, 이를 일반적인 안전망으로 취급해서는 안 됩니다.

원격 브랜치를 삭제하려면:

git push origin --delete branch-name

작업이 병합, 중단 또는 명확히 소유한 경우에만 원격 브랜치를 삭제하세요. 공유 팀에서 원격 브랜치는 리뷰, 배포 미리보기 또는 다른 개발자가 사용할 수 있습니다.

다음 명령으로 오래된 원격 추적 참조를 정리할 수 있습니다:

git fetch --prune

이 명령은 서버에 더 이상 존재하지 않는 원격 브랜치에 대한 로컬 참조를 제거합니다. 실제 원격 브랜치는 삭제하지 않습니다.

팀원에게 물어봐야 할 때

브랜치 생성 및 전환은 위험이 적은 작업입니다. 위험한 순간은 병합되지 않은 작업을 삭제하거나, 강제 푸시하거나, 다른 사람이 이미 사용하고 있을 수 있는 브랜치를 리베이스하는 경우입니다.

공유 브랜치에 강제 푸시하기 전에 물어보세요. 또한 직접 생성하지 않은 원격 브랜치를 삭제하기 전에 물어보세요. CI/CD가 많은 저장소에서는 브랜치가 Git만으로는 명확하지 않은 빌드, 미리보기 또는 배포 규칙을 트리거할 수 있습니다.

좋은 브랜칭은 대부분 명확성에 관한 것입니다. 올바른 기준에서 브랜치를 만들고, 작업 이름을 지정하고, 집중력을 유지하며, 더 이상 필요하지 않으면 삭제하세요. 이러한 습관은 Git을 더 쉽게 만들고 팀 전체를 더 안전하게 만듭니다.