본문 바로가기
Github

[Github]🌿브랜치(Branch)로 안전하게 개발하기

by 다다면체 2025. 4. 24.
728x90
반응형

안녕하세요! GitHub 시리즈 3편에 오신 것을 환영합니다. 😊 2편에서는 로컬 저장소를 GitHub 원격 저장소와 연결하고 기본적인 add, commit, push, pull 작업을 익혔습니다. 이제 GitHub를 더욱 강력하고 안전하게 사용하는 핵심 비결, 바로 브랜치(Branch) 에 대해 알아볼 시간입니다!

혼자 개발하든, 팀과 함께 협업하든 브랜치는 마치 마법 지팡이처럼 코드 관리를 훨씬 유연하고 체계적으로 만들어 줍니다. 브랜치가 무엇이고, 왜 사용해야 하며, 어떻게 활용하는지 차근차근 배워봅시다!

반응형

🤔 브랜치(Branch)란 무엇이고 왜 사용할까요?

브랜치(Branch) 는 문자 그대로 '나뭇가지'처럼, 특정 시점의 코드 상태로부터 분기되어 독립적으로 개발을 진행할 수 있는 작업 공간을 의미합니다. 마치 평행 우주처럼, 기존 코드에 영향을 주지 않으면서 새로운 기능을 추가하거나 버그를 수정하는 등의 작업을 할 수 있게 해줍니다. 🌳

왜 브랜치를 사용할까요?

  1. 독립적인 작업 공간 확보: 여러 기능을 동시에 개발해야 할 때, 각 기능을 별도의 브랜치에서 작업하면 서로의 코드 변경에 영향을 주지 않고 독립적으로 개발을 진행할 수 있습니다. 실험적인 기능을 추가하거나 리팩토링을 시도할 때도 유용합니다.
  2. 안정적인 메인 코드 관리 (main 브랜치 보호): 보통 프로젝트의 실제 출시 버전이나 가장 안정적인 코드는 main (또는 master) 브랜치에 보관합니다. 새로운 기능 개발이나 버그 수정은 별도의 브랜치에서 충분히 테스트한 후, 문제가 없다고 판단되면 main 브랜치에 합치는(Merge) 방식으로 진행합니다. 이렇게 하면 main 브랜치는 항상 안정적인 상태를 유지할 수 있습니다. ✨
  3. 코드 변경사항 분리 및 리뷰 용이성: 특정 기능이나 수정사항에 대한 코드 변경 내역이 해당 브랜치에 모여있기 때문에, 어떤 부분이 왜 변경되었는지 추적하고 이해하기 쉽습니다. 이는 코드 리뷰(Code Review) 과정을 훨씬 효율적으로 만듭니다. (Pull Request에서 자세히 다룰 예정!)
  4. 협업 효율 증대: 여러 명의 개발자가 동시에 각자의 브랜치에서 작업하고, 나중에 그 결과물들을 합치는 방식으로 효율적인 병렬 작업이 가능해집니다.

🔀 로컬 환경에서 브랜치 다루기

이제 로컬 PC 환경에서 Git 명령어를 통해 브랜치를 직접 다뤄봅시다.

1. 브랜치 목록 확인: 현재 로컬 저장소에 어떤 브랜치들이 있는지 확인합니다. * 표시가 현재 내가 작업 중인 브랜치를 나타냅니다.

```bash
git branch
```
(아마 처음에는 `* main` 만 보일 것입니다.)

2. 브랜치 생성: 새로운 브랜치를 만듭니다. 브랜치 이름은 보통 어떤 작업을 하는지 알 수 있도록 짓는 것이 좋습니다. (예: feature/기능이름, fix/버그이름, docs/문서작업)

```bash
git branch feature/add-user-login
```
다시 `git branch`를 실행하면 `main`과 `feature/add-user-login` 두 개의 브랜치가 보일 것입니다. 하지만 `*`는 여전히 `main`에 있습니다. 브랜치를 만들기만 하고 이동하지는 않았기 때문입니다.

3. 브랜치 이동 (Checkout/Switch): 생성한 브랜치나 다른 기존 브랜치로 작업 공간을 전환합니다.

```bash
# 최신 Git 버전에서 권장하는 명확한 명령어
git switch feature/add-user-login

# 기존에 널리 사용되던 명령어 (같은 기능 수행)
# git checkout feature/add-user-login
```
이제 `git branch`를 실행하면 `*` 표시가 `feature/add-user-login`으로 이동한 것을 확인할 수 있습니다. 이제부터의 모든 작업(파일 수정, 커밋 등)은 이 `feature/add-user-login` 브랜치에 기록됩니다.

4. 브랜치 생성과 동시에 이동: 위 2, 3번 과정을 한 번에 처리하는 편리한 명령어입니다.

```bash
# 최신 Git 버전 권장
git switch -c feature/new-feature

# 기존 방식
# git checkout -b feature/new-feature
```
이 명령어를 사용하면 `feature/new-feature` 브랜치를 새로 만들고 즉시 해당 브랜치로 이동합니다.

⬆️ 로컬 브랜치를 GitHub 원격 저장소로! (Push)

로컬에서 git branch나 git switch -c로 만든 브랜치는 아직 내 컴퓨터에만 존재합니다. 다른 사람과 공유하거나 GitHub에서 확인하려면 원격 저장소(origin)에도 이 브랜치를 올려주어야 합니다.

예시: feature/add-user-login 브랜치를 원격 저장소에 Push 하기

  1. 해당 브랜치에서 작업 및 커밋: feature/add-user-login 브랜치로 이동(git switch feature/add-user-login)한 상태에서, 사용자 로그인 관련 기능 코드를 추가하거나 수정하고 커밋합니다. (실제 코드가 아니어도 괜찮습니다. 주석이나 간단한 출력문 등으로 테스트해보세요!)
  2. # 예시: login.py 파일 생성 및 내용 추가
    # (실제 코드는 필요 없고, 파일 추가/수정 후 아래 명령어 실행)
    
    git add .
    git commit -m "Feat: Add basic structure for user login"
    
  3. 원격 저장소에 브랜치 Push: 다음 명령어를 사용하여 로컬 브랜치를 원격 저장소(origin)에 동일한 이름으로 Push 합니다.
  4. git push origin feature/add-user-login
    
  5. 💡 첫 Push 시 -u 옵션 사용하기 (추천): 특정 로컬 브랜치를 처음으로 원격 저장소에 Push 할 때는 -u (또는 --set-upstream) 옵션을 함께 사용하는 것이 좋습니다.이 옵션을 사용하면 로컬의 feature/add-user-login 브랜치가 원격 저장소(origin)의 feature/add-user-login 브랜치를 자동으로 추적하도록 설정됩니다. 이렇게 한번 설정해두면, 이후 해당 브랜치에서 작업할 때는 단순히 git push 와 git pull 만 입력해도 Git이 알아서 연결된 원격 브랜치로 Push/Pull을 수행해 편리합니다.
  6. git push -u origin feature/add-user-login
    

결과 확인: 이제 GitHub 웹사이트의 my-first-repo 저장소 페이지로 가보세요.

  • 파일 목록 위쪽에 있는 'main'이라고 표시된 드롭다운 메뉴를 클릭하면 방금 Push한 feature/add-user-login 브랜치가 새롭게 나타난 것을 확인할 수 있습니다.
  • 해당 브랜치를 선택하면 그 브랜치에서 커밋한 내용(예: login.py 파일)을 볼 수 있습니다.

🌐 GitHub 웹사이트에서 브랜치 생성 및 확인

GitHub 웹사이트 인터페이스를 통해서도 브랜치를 만들 수 있습니다.

  • 저장소 페이지의 브랜치 드롭다운 메뉴를 클릭합니다.
  • 텍스트 입력 상자에 새로운 브랜치 이름을 입력합니다. (예: docs/add-contribution-guide)
  • 하단에 나타나는 'Create branch: [새 브랜치 이름] from 'main'' (또는 현재 브랜치) 옵션을 클릭하면 해당 브랜치를 기반으로 새로운 브랜치가 원격 저장소에 바로 생성됩니다.

주로 로컬에서 개발 작업을 시작하며 브랜치를 만들지만, 가끔 웹에서 간단한 문서 수정 등을 위해 바로 브랜치를 생성해야 할 때 유용합니다.

🔗 브랜치 병합(Merge)이란? (개념 소개)

자, 이제 main 브랜치와 feature/add-user-login 브랜치, 이렇게 두 개의 브랜치가 존재합니다. feature/add-user-login 브랜치에서 로그인 기능 개발 및 테스트를 완료했다면, 이제 그 변경 사항을 원래의 main 브랜치에도 반영하여 실제 서비스에 적용해야겠죠?

이렇게 나누어졌던 브랜치의 작업 내용을 다른 브랜치와 하나로 합치는 과정병합(Merge) 이라고 합니다. 🔀

Git에는 git merge라는 직접적인 병합 명령어가 있지만, GitHub에서 협업할 때는 보통 Pull Request(풀 리퀘스트, PR) 라는 기능을 통해 병합을 진행합니다. Pull Request는 단순히 코드를 합치는 것 이상의 의미를 지닙니다. 내가 작업한 내용을 다른 팀원들에게 알리고, 코드 리뷰를 거쳐 피드백을 반영하며, 충분한 검토 후에 안전하게 main 브랜치에 병합하는 협업 워크플로우의 핵심입니다.

Pull Request에 대한 자세한 내용은 다음 4편에서 집중적으로 다룰 예정이니 기대해주세요! 😉

👀 GitHub에서 브랜치 흐름 시각적으로 보기

내 프로젝트의 브랜치들이 어떻게 분기되고 합쳐져 왔는지 그 역사를 시각적으로 확인하고 싶을 때 유용한 기능이 있습니다.

  • GitHub 저장소 페이지 상단의 'Insights' 탭을 클릭합니다.
  • 왼쪽 메뉴에서 'Network' 를 선택합니다.

그러면 브랜치들이 어떤 커밋에서 갈라져 나왔고, 각 브랜치에 어떤 커밋들이 쌓였는지 그래픽으로 보여주는 네트워크 그래프를 볼 수 있습니다. main 브랜치와 방금 만든 feature/add-user-login 브랜치가 특정 커밋에서 분기되어 각자의 길을 가는 모습이 시각적으로 나타날 것입니다. 프로젝트 히스토리를 파악하는 데 큰 도움이 됩니다.

⚠️ 문제 해결: 흔한 브랜치 관련 실수 및 대처법

1. 실수로 main 브랜치에 직접 커밋했을 때

가장 흔하면서도 주의해야 할 실수입니다. 중요한 기능을 개발하거나 버그를 수정할 때는 반드시 별도의 브랜치를 따서 작업해야 하는데, 깜빡하고 main 브랜치에서 바로 작업하고 커밋까지 해버리는 경우입니다.

  • 문제점:
    • 안정적이어야 할 main 브랜치에 검증되지 않은 코드가 바로 반영될 위험이 있습니다.
    • Pull Request를 통한 코드 리뷰 과정을 건너뛰게 됩니다.
    • 협업 시 다른 팀원들에게 혼란을 줄 수 있습니다.
  • 대처 아이디어 (개념만!):
    1. 일단 당황하지 마세요! 아직 push 하지 않았다면 로컬에서 쉽게 되돌릴 수 있습니다. push 했더라도 방법은 있습니다.
    2. 아이디어: 현재 main 브랜치의 상태(실수로 커밋한 내용 포함)를 기반으로 원래 작업했어야 할 새 브랜치를 만듭니다. (예: git switch -c feature/missed-feature)
    3. 그다음, main 브랜치를 실수하기 직전의 올바른 커밋 상태로 되돌립니다. (git reset --hard <돌아가고 싶은 커밋 해시> 명령어를 사용할 수 있지만, 매우 주의해야 합니다! 커밋이 유실될 수 있습니다. git reflog 명령어로 이전 커밋 해시를 찾을 수 있습니다.)
    4. 이제 새로 만든 브랜치(feature/missed-feature)에는 원하는 변경사항이 남아있고, main 브랜치는 깨끗한 상태가 됩니다. 이후에는 정상적인 워크플로우(Push -> Pull Request)를 따르면 됩니다.
    • 🚨 중요 경고: git reset --hard는 강력하지만 위험한 명령어입니다. 잘못 사용하면 작업 내용을 영구적으로 잃을 수도 있습니다. 이 시나리오에 대한 자세하고 안전한 복구 방법은 추후 문제 해결 심화 편(예: 8편)에서 구체적인 예시와 함께 다룰 예정입니다. 지금은 '아, 이런 실수를 하면 안 되고, 해결할 방법이 있구나' 정도로만 인지하고 넘어가세요! 항상 작업 시작 전에 git branch나 git status로 현재 브랜치를 확인하는 습관을 들이는 것이 최선입니다.

2. 로컬 브랜치와 다른 이름으로 원격 브랜치에 Push 해야 할 때

일반적이지는 않지만, 로컬 브랜치 이름과 GitHub 원격 저장소에 Push할 브랜치 이름을 다르게 지정해야 하는 경우가 있을 수 있습니다. (예: 로컬에서는 my-feature로 작업했지만, 팀 규칙에 따라 원격에는 feature/user-auth로 올려야 할 때)

이때는 git push 명령어에 콜론(:)을 사용하여 로컬 브랜치 이름과 원격 브랜치 이름을 명시해주면 됩니다.

git push origin <로컬_브랜치_이름>:<원격_브랜치_이름>

예시:

git push origin my-feature:feature/user-auth

이 명령은 로컬의 my-feature 브랜치의 내용을 원격 저장소(origin)의 feature/user-auth 라는 이름의 브랜치로 Push 합니다. 만약 원격에 해당 이름의 브랜치가 없다면 새로 생성됩니다.


🎉 이제 여러분은 GitHub 개발 워크플로우의 핵심인 브랜치를 다룰 수 있게 되었습니다! 브랜치를 통해 코드를 안전하게 분리하여 작업하고, 원격 저장소와 동기화하는 방법을 익혔습니다. 실수를 방지하고 협업을 원활하게 하는 브랜치의 중요성을 꼭 기억하세요.

💡 브랜치 이름 규칙: 팀이나 프로젝트마다 브랜치 이름 규칙(Naming Convention)을 정해두면 좋습니다. 예를 들어, 기능 개발은 feature/, 버그 수정은 fix/, 문서 작업은 docs/, 긴급 핫픽스는 hotfix/ 등의 접두사를 사용하는 방식입니다. 일관된 규칙은 브랜치 목적을 파악하는 데 도움을 줍니다.

👉 다음 편에서는...

  • 드디어 협업의 꽃, Pull Request(풀 리퀘스트) 를 생성하고,
  • 동료의 코드를 리뷰(Code Review) 하고 피드백을 주고받으며,
  • 안전하게 변경사항을 병합(Merge) 하는 실질적인 협업 과정을 자세히 알아보겠습니다!

GitHub를 통한 스마트한 개발 여정, 계속 함께해요! 궁금한 점은 언제든 댓글로 남겨주세요. 😊

728x90
반응형