작성한 질문수 2

0

안녕하세요, 짐코딩입니다.

네! 개발 브랜치에 핫픽스된 메인을 다시 반영하셔야 합니다.

개발 브랜치는 "작업 시작 시점의 메인 복사본"에서 출발합니다. 메인이 핫픽스로 업데이트됐으면 내 개발 브랜치는 옛날 버전 기반이라, 그대로 머지하면 핫픽스가 덮어써지거나 충돌이 날 수 있어요.

그래서 핫픽스된 메인을 개발 브랜치로 먼저 가져와서 동기화한 다음, 개발 완료되면 메인에 머지하는 순서로 진행합니다.

git checkout develop
git merge main     # 또는 git rebase main

비유하자면, 같은 문서를 두 사람이 편집 중인데 한 명이 먼저 오타 수정분을 반영했으면, 나머지 한 명도 자기 작업본에 그 수정사항을 먼저 가져와야 나중에 합칠 때 꼬이지 않는 것과 같습니다.

참고로 말씀드리면, 브랜치 관리 전략은 팀마다, 상황마다 정말 천차만별이에요. 1인 개발이냐 팀 개발이냐, 팀 인원이 몇 명이냐, 배포 주기가 어떻게 되냐에 따라 완전히 다릅니다. 강의에서 보여드린 방식은 하나의 흐름이고, 실무에서는 본인 팀 상황에 맞게 규칙을 정해서 쓰시면 됩니다. 정답이 있는 영역이 아니라는 점 참고하세요!

감사합니다 🙂

0

안녕하세요, 인프런 AI 인턴입니다. requiem315님.

Git 브랜치 관리에 대한 질문을 주셨군요. 개발 중에 발생할 수 있는 문제이기도 한 부분입니다. 질문하신 내용에 대한 간단한 해설을 드리겠습니다.

핫픽스와 개발 브랜치 머지

1. 핫픽스 작업: 메인 브랜치에서 버그가 발생했을 때, ‘핫픽스’라는 별도의 브랜치를 만들어 해당 버그를 수정합니다. 그런 다음 핫픽스 브랜치를 다시 메인 브랜치에 합칩니다.

2. 개발 브랜치 업데이트: 개발 브랜치는 메인 브랜치의 이전 버전(버그가 있었던 시점)을 기반으로 하고 있을 가능성이 있기 때문에, 핫픽스된 최신 메인의 내용을 개발 브랜치에도 통합(머지)해야 합니다. 이를 통해 개발 브랜치도 최신 상태와 버그 수정사항을 갖게 됩니다.

3. 최종 병합: 이후 개발 브랜치가 충분히 안정적이거나 기능이 완성되었다면, 그때 수정된 메인 브랜치의 상태와 비교하고 병합합니다.

관련 자료

• Git Flow에 기반한 병합 전략 이해하기 라는 게시글을 통해 다양한 브랜치 전략을 더 알아보실 수 있습니다.
  
• 강의 중 언급한 11:50초 정도 내용은 이러한 맥락을 설명하고 있을 가능성이 큽니다. 따라서 강의를 다시 살펴보시는 것도 도움이 될 것입니다.
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.