브랜치

Tier: Free, Premium, Ultimate Offering: GitLab.com, 자체 관리, GitLab Dedicated

브랜치는 프로젝트의 작업 트리 버전입니다. 브랜치는 프로젝트의 개발의 기초입니다. 새 프로젝트를 생성하면 GitLab은 해당 리포지토리에 대한 기본 브랜치를 생성합니다. 기본 브랜치 설정은 프로젝트, 서브그룹, 그룹 또는 인스턴스에서 구성됩니다.

프로젝트가 성장함에 따라 팀은 더 많은 브랜치를 생성합니다. 각 브랜치는 개발 작업을 병렬로 수행할 수 있도록 변경 세트를 나타냅니다. 한 브랜치에서의 개발 작업은 다른 브랜치에 영향을 주지 않습니다.

브랜치의 개발 흐름은 다음과 같습니다:

  1. 브랜치 생성 및 해당 브랜치에 커밋 추가 이 프로세스를 간소화하려면 브랜치 이름 패턴을 따르는 것이 좋습니다.
  2. 작업이 검토 준비가 되었을 때, 병합 요청을 생성하여 해당 브랜치의 변경 사항을 병합하도록 제안합니다.
  3. 리뷰 앱으로 변경 내용 미리 보기
  4. 리뷰 요청
  5. 병합 요청이 승인되면 브랜치를 원본 브랜치로 병합합니다. 병합 방법은 프로젝트에서 병합 요청이 처리되는 방식을 결정합니다.
  6. 브랜치의 내용이 병합되면 병합된 브랜치를 삭제합니다.

모든 브랜치 보기

GitLab 사용자 인터페이스에서 브랜치를 보고 관리하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 왼쪽 사이드바에서 코드 > 브랜치를 선택합니다.

이 페이지에서 다음을 수행할 수 있습니다:

  • 모든 브랜치 보기 또는 활성 또는 미사용 브랜치만 필터링
  • 커밋이 지난 3개월 동안에 이루어진 경우 해당 브랜치가 활성으로 간주됩니다. 그렇지 않은 경우 미사용으로 간주됩니다.
  • 새로운 브랜치 만들기
  • 브랜치 비교
  • 병합된 브랜치 삭제

  • 기본 브랜치를 가리키는 병합 요청 링크 보기

    기본 브랜치를 가리키지 않는 병합 요청이 있는 브랜치는 새로 만들기 병합 요청 버튼을 표시합니다.

  • 브랜치 규칙 보기
  • 브랜치의 최신 파이프라인 상태 보기

브랜치 생성

필수 사항:

  • 해당 프로젝트의 최소한 개발자 역할을 가져야 합니다.

GitLab UI에서 새로운 브랜치를 생성하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 코드 > 브랜치를 선택합니다.
  3. 우측 상단에서 새로운 브랜치를 선택합니다.
  4. 브랜치 이름을 입력합니다.
  5. Create from에서 해당 브랜치의 기초를 선택합니다: 기존 브랜치, 기존 태그 또는 커밋 SHA.
  6. 브랜치 생성을 선택합니다.

빈 프로젝트인 경우

빈 프로젝트는 브랜치를 포함하지 않지만, 브랜치를 추가할 수 있습니다.

필수 사항:

  • 해당 프로젝트의 최소한 개발자 역할을 가져야 합니다.
  • 유지자 또는 소유자 역할이 없는 경우, 그룹의 기본 브랜치 보호 은 커밋을 기본 브랜치로 푸시할 수 있게 부분적으로 보호 또는 보호되지 않음으로 설정되어 있어야 합니다.

빈 프로젝트에 기본 브랜치를 추가하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 이 프로젝트의 리포지토리는 비어 있습니다로 스크롤하고 추가하려는 파일 유형을 선택합니다.
  3. 웹 IDE에서 이 파일에 원하는 변경 사항을 하는 다음 커밋 만들기를 선택합니다.
  4. 커밋 메시지를 입력하고 커밋을 선택합니다.

GitLab은 기본 브랜치를 생성하고 파일을 추가합니다.

이슈에서

이슈를 보는 경우 해당 페이지에서 직접 연결된 브랜치를 생성할 수 있습니다. 이 방법으로 생성된 브랜치는 변수를 포함하여 이슈에서의 기본 브랜치 이름 패턴을 사용합니다.

필수 사항:

  • 해당 프로젝트의 최소한 개발자 역할을 가져야 합니다.

이슈에서 브랜치를 생성하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. Plan > 이슈를 선택하고 해당 이슈를 찾습니다.
  3. 이슈 설명 하단에서 병합 요청 생성 드롭다운 목록을 찾고 을 선택하여 드롭다운 목록을 표시합니다.
  4. 브랜치 생성을 선택합니다. 기본 패턴을 기반으로 한 기본 브랜치 이름이 제공되며, 원하는 경우 다른 브랜치 이름을 입력합니다.
  5. 프로젝트의 기본 브랜치를 기반으로한 브랜치를 생성하려면 브랜치 생성을 선택합니다.

브랜치 이름 지정

Git은 브랜치 이름 규칙을 강제하여 브랜치 이름이 다른 도구와 호환되도록 보조합니다. GitLab은 브랜치 이름에 대해 추가적인 요구사항을 강제하고 잘 구조화된 브랜치 이름에 대한 이점을 제공합니다.

GitLab은 모든 브랜치에 다음과 같은 추가 규칙을 강제합니다:

  • 브랜치 이름에 공백이 허용되지 않습니다.
  • 40자의 16진수 문자로 이루어진 브랜치 이름은 유사한 Git 커밋 해시와 유사하여 금지됩니다.
  • 브랜치 이름은 대소문자를 구분합니다.

Docker와 같은 일반적인 소프트웨어 패키지는 추가 브랜치 이름 제한 사항 을 강제할 수 있습니다.

다른 소프트웨어 패키지와의 최상의 호환성을 위해 ASCII 표준 테이블에서:

  • 숫자
  • 하이픈 (-)
  • 밑줄(_)
  • 소문자 ASCII 표준 테이블에서 사용합니다.

또한 브랜치 이름에는 슬래시 (/) 및 이모지를 사용할 수 있지만, 다른 소프트웨어 패키지와의 호환성은 보장할 수 없습니다.

특정 형식의 브랜치 이름은 추가적인 혜택을 제공합니다:

이슈에서 브랜치 이름의 기본 패턴 구성

기본적으로 GitLab은 이슈에서 브랜치를 만들 때 %{id}-%{title} 패턴을 사용하지만, 이 패턴을 변경할 수 있습니다.

전제 조건:

  • 프로젝트에 대한 최소한 Maintainer 역할이 있어야 합니다.

이슈에서 생성된 브랜치의 기본 패턴을 변경하려면 다음을 수행합니다:

  1. 좌측 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 저장소를 선택합니다.
  3. 브랜치 기본값을 확장합니다.
  4. 브랜치 이름 템플릿으로 스크롤하고 값을 입력합니다. 이 필드에서는 다음 변수를 지원합니다:
    • %{id}: 이슈의 숫자 ID
    • %{title}: 이슈의 제목으로, Git 브랜치 이름에 사용 가능한 문자만으로 수정됩니다.
  5. 변경 사항 저장을 선택합니다.

이슈 번호로 브랜치 이름에 접두사 추가

병합 요청을 간소화하기 위해 Git 브랜치 이름을 이슈 번호로 시작한 후 하이픈을 붙입니다. 예를 들어, 브랜치를 #123 이슈에 링크하려면 브랜치 이름을 123-으로 시작합니다.

이슈와 브랜치는 동일한 프로젝트에 있어야 합니다.

GitLab은 이슈 번호를 사용하여 데이터를 병합 요청에 가져옵니다:

  • 이슈가 병합 요청과 관련되었음을 표시합니다. 이슈와 병합 요청은 서로에 대한 링크를 표시합니다.
  • 브랜치는 이슈에 연결됩니다.
  • 귀하의 프로젝트가 기본적으로 종료하는 패턴으로 구성된 경우, 병합 요청을 합병하면 관련된 이슈도 닫힙니다.
  • 병합 요청이 동일한 프로젝트에 있고 포크가 아니라면, 이슈 마일스톤 및 레이블이 병합 요청으로 복사됩니다.

브랜치 관리 및 보호

GitLab은 개별 브랜치를 보호하는 여러 가지 방법을 제공합니다. 이러한 방법은 브랜치가 생성될 때부터 삭제될 때까지 감시 및 품질 확인을 받도록 보장합니다. 브랜치 보호를 보고 편집하려면 브랜치 규칙을 참조하세요.

브랜치 비교

저장소에서 브랜치를 비교하려면:

  1. 좌측 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 코드 > 리비전 비교를 선택합니다.
  3. 소스 브랜치를 선택하여 원하는 브랜치를 검색합니다. 정확한 일치 항목이 먼저 표시됩니다. 연산자로 검색을 더 정밀하게 할 수 있습니다:
    • ^는 브랜치 이름의 시작 부분과 일치합니다: ^feat는 feat/user-authentication와 일치합니다.
    • $는 브랜치 이름의 끝 부분과 일치합니다: widget$은 feat/search-box-widget와 일치합니다.
    • *는 와일드카드로 일치합니다: branch*cache*는 fix/branch-search-cache-expiration와 일치합니다.
    • 연산자를 결합할 수 있습니다: ^chore/*migration$은 chore/user-data-migration와 일치합니다.
  4. 대상 리포지토리와 브랜치를 선택합니다. 정확한 일치 항목이 먼저 표시됩니다.
  5. 변경 사항 표시 아래에서 브랜치 비교 방법을 선택합니다:
    • 소스로부터의 들어오는 변경만 표시 (기본값)은 최신 공통 커밋 이후 소스 브랜치의 변경 사항을 표시합니다. 소스 브랜치가 생성된 후 대상 브랜치에 관련없는 변경 사항은 포함되지 않습니다. 이 방법은 실제 커밋 대신에 머지 베이스를 사용하므로 체리픽된 커밋의 변경 사항이 새로운 변경 사항으로 표시됩니다.
    • 소스 생성 이후 대상의 변경 포함은 두 브랜치 간의 모든 차이를 표시합니다.
  6. 비교를 선택하여 커밋 목록과 변경된 파일을 표시합니다.
  7. 선택 사항: 소스와 대상을 반전하려면 리비전 바꾸기를 선택합니다 ().

합병된 브랜치 삭제

합병된 브랜치는 다음 기준을 모두 충족하는 경우 대량으로 삭제할 수 있습니다:

  • 보호된 브랜치가 아닙니다.
  • 프로젝트의 기본 브랜치로 병합되었습니다.

전제 조건:

  • 프로젝트에 대한 최소한 Developer 역할이 있어야 합니다.

다음을 수행합니다:

  1. 좌측 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 코드 > 브랜치를 선택합니다.
  3. 페이지의 우측 상단에서 더보기 를 선택합니다.
  4. 병합된 브랜치 삭제를 선택합니다.
  5. 대화상자에 delete를 입력하여 확인한 다음 합병된 브랜치 삭제를 선택합니다.

대상 브랜치를 위한 워크플로 구성

Tier: 프리미엄, 얼티밋 Offering: GitLab.com, Self-managed, GitLab Dedicated

일부 프로젝트는 개발 및 qa와 같은 여러 장기 브랜치를 사용하며, 이러한 프로젝트에서는 main을 기본 브랜치로 유지하되, 병합 요청이 develop 또는 qa를 대상으로 하는 것을 기대할 수 있습니다. 대상 브랜치 워크플로는 프로젝트의 적절한 개발 브랜치를 타깃으로 하는 병합 요청을 보장합니다.

병합 요청을 생성하면 워크플로가 브랜치 이름을 확인합니다. 브랜치 이름이 워크플로와 일치하면 병합 요청이 지정한 브랜치를 타깃으로 합니다. 브랜치 이름이 일치하지 않으면 병합 요청이 프로젝트의 기본 브랜치를 타킷으로 합니다.

규칙은 “첫 번째 일치” 기준으로 처리됩니다 - 동일한 브랜치 이름에 대해 두 규칙이 일치하는 경우 맨 위에 있는 규칙이 적용됩니다.

전제 조건:

  • 최소한 Maintainer 역할이 있어야 합니다.

대상 브랜치 워크플로를 생성하려면 다음을 수행합니다:

  1. 좌측 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 병합 요청을 선택합니다.
  3. 병합 요청 브랜치 워크플로로 스크롤합니다.
  4. 브랜치 대상 추가를 선택합니다.
  5. 브랜치 이름 패턴에는 브랜치 이름과 비교할 문자열 또는 와일드카드를 제공합니다.
  6. 타깃 브랜치를 선택하여 브랜치 이름 패턴과 일치하는 경우 사용할 타깃 브랜치를 지정합니다.
  7. 저장을 선택합니다.

대상 브랜치 워크플로우 예시

프로젝트를 다음과 같은 대상 브랜치 워크플로우로 구성할 수 있습니다:

브랜치 이름 패턴 대상 브랜치
feature/* develop
bug/* develop
release/* main

이러한 대상 브랜치는 다음과 같은 프로젝트에 대한 병합 요청을 생성하는 프로세스를 간소화합니다:

  • main을 애플리케이션의 배포 상태를 나타내는 데 사용합니다.
  • develop와 같은 다른 장기 브랜치에 현재 릴리스되지 않은 개발 작업을 추적합니다.

작업 흐름이 처음에는 새로운 기능을 main이 아닌 develop에 배치하는 경우, 이러한 대상 브랜치는 feature/* 또는 bug/* 중 하나와 일치하는 모든 브랜치가 실수로 main을 대상으로 하지 않도록 보장합니다.

main으로 릴리스할 준비가 되었을 때, release/*라는 브랜치를 만들고 이 브랜치가 main을 대상으로 하도록합니다.

대상 브랜치 워크플로우 삭제

대상 브랜치 워크플로우를 제거하면 기존의 병합 요청이 변경되지 않습니다.

전제 조건:

  • 적어도 유지자(Maintainer) 역할이 있어야 합니다.

다음을 수행하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 병합 요청을 선택합니다.
  3. 삭제하려는 대상 브랜치에서 삭제를 선택합니다.

관련 주제

문제 해결

동일한 커밋을 포함하는 여러 브랜치

보다 심층적인 기술적 수준에서 Git 브랜치는 별도의 엔티티가 아니라 세트의 커밋 SHAs에 부착 된 레이블입니다. GitLab은 브랜치가 병합되었는지 여부를 결정할 때 해당 커밋 SHAs의 대상 브랜치를 확인합니다. 두 병합 요청에 동일한 커밋이 포함될 때 예상치 못한 결과를 초래할 수 있습니다. 이 예에서 브랜치 B와 C는 모두 브랜치 A의 커밋 (3)에서 시작합니다:

%%{init: { "fontFamily": "GitLab Sans" }}%% gitGraph accTitle: 동일한 커밋을 포함하는 여러 브랜치 다이어그램 accDescr: 브랜치 A 및 B에는 동일한 커밋이 포함되어 있지만, 브랜치 B에는 다른 커밋도 포함되어 있습니다. 브랜치 B를 병합하면 모든 커밋이 병합되기 때문에 브랜치 A가 병합된 것처럼 보입니다. 브랜치 C는 브랜치 A 또는 B에 포함되지 않은 커밋 (5) 때문에 병합되지 않은 상태로 남아 있습니다. commit id:"a" branch "브랜치 A" commit id:"b" commit id:"c" type: HIGHLIGHT branch "브랜치 B" commit id:"d" checkout "브랜치 A" branch "브랜치 C" commit id:"e" checkout main merge "브랜치 B" id:"병합된 커밋 b, c, d"

브랜치 B를 병합하면 브랜치 A도 병합된 것처럼 보입니다 (귀하의 조치가 없어도), 왜냐하면 브랜치 A의 모든 커밋이 이제 대상 브랜치 main에 나타나기 때문입니다. 브랜치 C는 브랜치 A 또는 B에 속하지 않는 커밋 5 때문에 아직 병합되지 않은 상태입니다.

병합 요청 A는 여전히 병합되어 있으며, 해당 브랜치에 새로운 커밋을 푸시하려고 하더라도 마찬가지입니다. 병합 요청 A에 변경 사항이 아직 병합되지 않은 경우 (병합 요청 A에 포함되지 않았기 때문), 해당 변경 사항에 대한 새로운 병합 요청을 엽니다.

오류: 모호한 HEAD 브랜치가 존재합니다

2.16.0보다 낮은 Git 버전에서 HEAD라는 이름의 브랜치를 만들 수 있었습니다. 이 HEAD이라는 브랜치는 Git이 활성화(체크아웃)된 브랜치를 설명하는 데 사용하는 내부 참조(또한 HEAD로 명명됨)와 충돌합니다. 이 네이밍 충돌로 인해 리포지토리의 기본 브랜치를 업데이트할 수 없을 수 있습니다: 

오류: 기본 브랜치를 설정할 수 없습니다. 리포지토리에 'HEAD'라는 이름의 브랜치가 있나요?

이 문제를 해결하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 코드 > 브랜치를 선택합니다.
  3. HEAD라는 이름의 브랜치를 검색합니다.
  4. 브랜치에 변경 사항이 없는지 확인합니다.
  5. 브랜치 삭제를 선택하고, 그럼 예, 브랜치 삭제를 선택합니다.

2.16.0 이상의 Git 버전에서는 이 이름으로 브랜치를 만드는 것을 방지합니다.

작성한 모든 브랜치 찾기

프로젝트에서 작성한 모든 브랜치를 찾으려면 Git 리포지토리에서 다음 명령을 실행합니다: 

git for-each-ref --format='%(authoremail) %(refname:short)' | grep $(git config --get user.email)

작성한 모든 브랜치의 총 수를 얻으려면 작성자별로 정렬된 모든 브랜치의 총 수를 얻으려면 Git 리포지토리에서 다음 명령을 실행합니다: 

git for-each-ref --format='%(authoremail)'  | sort | uniq -c | sort -g