인프런 영문 브랜드 로고
인프런 영문 브랜드 로고

인프런 커뮤니티 질문&답변

BANG님의 프로필 이미지

작성한 질문수

Git & GitHub, 작동 원리 파악하고 모든 오류 해결하기 [완성편]

github 협업 내용 관련 질문 있습니다

해결된 질문

작성

·

57

0

git flow 이미지에서

1. release 브랜치는 점으로만 존재하는데 운영 배포될 때마다

release 브랜치도 계속 범위를 늘려가며 존재하는게 아닐까요??

release 브랜치 생성시 버전을 붙여서 각각의 다른 브랜치로 그때만 사용되는걸까요??

2. 실습화면에서 만약 협업하는 사람이 3명일 경우, 3명이 모두 각각 코멘트를 작성하고,

3명 모두 각각 merge pull request 버튼을 다 눌러야 pull request가 되는걸까요??

 

3. 깃헙에서 conflict가 발생할 경우도 협업하는 사람이 여러명일 경우 어떻게 되는지 궁금합니다.

pull request 요청시에 merge pull request 버튼이 비활성화 된걸 보고 작업자가

요청한 pull request를 취소?하고

로컬에서 conflict를 해결하고 다시 새로운 pull request를 요청하는 걸까요??

답변 2

1

geek님의 프로필 이미지
geek
지식공유자

안녕하세요, BANG 님 😀

1번 질문.
말씀해 주신 부분을 제가 정확히 이해하지 못한 것 같아요 ㅠ.ㅜ
정말 죄송하지만, 조금만 더 자세히 설명해주실 수 있을까요? 🙂

2번 질문.

코멘트의 경우, 팀내 협업 정책에 따라 다를 수 있어요! 다만, merge pull request 는 단 한 번만 클릭해도 브랜치가 머지됩니다.

3번 질문.
이 경우는 두 가지 해결 방법이 있어요. 하나는 깃헙에서 직접 해결하는 방법이구요. 또 하나는 로컬에서 rebase를 활용해 해결하는 방법이에요.
'협업할 때 conflict 해결하기' 회차에서 더욱 자세히 배우실 수 있습니다 😀

BANG님의 프로필 이미지
BANG
질문자

1번 내용은 release 브랜치가 왜 점으로만 존재하는건지 궁금합니다.

1부터 7번까지의 기능을 미리 개발해 놓고 1, 2기능만 release 브랜치로 만들어서 운영배포하고 다음에 3, 4기능을 추가로 해서 운영배포를 하려면

release 브랜치가 이미 있으니 선으로 연결되어 1,2,3,4 기능을 담은 브랜치가 되는게 아닌가요??

점으로 존재하는걸로 보면 1, 2기능만 있는 release브랜치와 1,2,3,4 기능이 있는 release 브랜치가 서로 다른 브랜치인지 궁금합니다.

geek님의 프로필 이미지
geek
지식공유자

아하 이해했습니다!
상세한 설명 감사드립니다.

운영 배포 할 때 마다, release브랜치를 새롭게 만든다고 보시면 됩니다.
(참고로... 브랜치 이름으로, release/v1 , release/v2 ... 를 사용해볼 수 있겠죠!)

그래서, 1,2 기능만 있는 release 브랜치와 1,2,3,4 기능이 있는 release브랜치는 서로 다른 별개의 브랜치라고 보시면 됩니다. 🙂

따라서, release 브랜치에 점으로 표시된 커밋들이 '점'으로만 존재하고 '선'으로 서로 연결되지 않았던 것입니다.

궁금하신 부분이 해결되었을까요?
추가로 궁금한 내용이 있다면, 언제든 질문주세요!

0

인프런 AI 인턴님의 프로필 이미지

안녕하세요, 인프런 AI 인턴입니다. BANG님, Git과 GitHub에서 협업과 관련된 질문을 주셨군요.

1. Release 브랜치의 역할과 사용 방법

  • Release 브랜치는 주로 배포 준비가 끝난 코드의 테스트 및 배포를 지원하기 위해 사용됩니다. 일반적으로 특정 버전의 릴리스를 준비하는 동안에만 존재하고 이후에는 main 브랜치(또는 master 브랜치)에 병합된 후 제거됩니다.

  • 버전 관리: 릴리즈 브랜치를 생성할 때 버전을 명시하여 (release-v1.0.0, release-v1.1.0 등) 각 릴리즈를 관리합니다. 이로 인해 릴리즈마다 독립된 브랜치로 사용할 수 있습니다.

2. 협업 시 Pull Request 관리

  • 3명의 협업자: Pull Request를 생성한 이후에는 일반적으로 하나의 승인한 번의 병합 버튼 클릭만 필요합니다. 협업자들은 모두 리뷰를 할 수 있지만, 모든 사람이 Merge Pull Request 버튼을 누를 필요는 없습니다. 보통 한 사람(리뷰 담당자)이 최종 결정하여 Merge합니다.

3. Conflict 발생 시 처리 방법

  • Conflict 처리: 협업 시 여러 작업자가 같은 파일의 동일한 부분을 수정하게 될 경우 충돌(conflict)이 발생할 수 있습니다.

  • Pull Request 시: 충돌이 있는 경우 GitHub에서는 Merge가 비활성화됩니다. 이 경우 작업자는 로컬에서 해당 충돌을 해결해야 합니다.

    • 과정: 로컬 저장소에서 최신 리모트 브랜치를 병합한 후 충돌을 직접 해결합니다. 이후 수정된 내용을 커밋하고, 다시 Push하여 Pull Request를 업데이트하거나, 새로운 Pull Request를 생성합니다.

이 과정에 관하여 유사한 예시와 추가 정보를 확인할 수 있는 링크를 제공드리겠습니다:
- Git 협업 중 conflict 해결하기

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

BANG님의 프로필 이미지

작성한 질문수

질문하기