브랜치

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

브랜치는 프로젝트의 작업 트리 버전입니다. 새 프로젝트를 생성하면 GitLab은 귀하의 리포지토리에 삭제할 수 없는 기본 브랜치를 생성합니다. 기본 브랜치 설정은 프로젝트, 서브그룹, 그룹 또는 인스턴스 수준에서 구성할 수 있습니다.

프로젝트가 성장함에 따라 팀은 브랜치 네이밍 패턴을 따라 선호하는 브랜치를 계속해서 생성합니다. 각 브랜치는 개발 작업이 병렬로 수행될 수 있도록 변경 세트를 나타내며, 한 브랜치에서의 개발 작업은 다른 브랜치에 영향을 미치지 않습니다.

브랜치는 프로젝트에서 개발의 기초입니다:

  1. 시작하기 위해 브랜치를 생성하고 커밋을 추가합니다.
  2. 작업이 검토 준비가 되면 병합 요청을 생성하여 귀하의 브랜치에서 변경 사항을 병합하기를 제안하세요. 이 프로세스를 간소화하기 위해 브랜치 네이밍 패턴을 따르는 것이 좋습니다.
  3. 리뷰 앱을 통해 브랜치의 변경 사항을 미리 보세요.
  4. 브랜치의 내용이 병합되면 병합된 브랜치를 삭제하세요.

브랜치 생성

전제 조건:

  • 프로젝트에 대해 최소한의 개발자 역할이 있어야 합니다.

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

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. Code > Branches를 선택합니다.
  3. 오른쪽 상단에서 새 브랜치를 선택합니다.
  4. 브랜치 이름을 입력합니다.
  5. 다음 위치에서 생성에서 귀하의 브랜치의 기반이 되는 것을 선택합니다: 기존 브랜치, 기존 태그 또는 커밋 SHA.
  6. 브랜치 생성을 선택합니다.

빈 프로젝트에서

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

전제 조건:

  • 프로젝트에 대해 최소한의 개발자 역할이 있어야 합니다.
  • 유지자 또는 소유자 역할이 아닌 경우, 기본 브랜치 보호가 기본 브랜치에 커밋을 푸시할 수 있도록 부분적으로 보호함 또는 보호하지 않음으로 설정되어 있어야 합니다.

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

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 이 프로젝트의 저장소는 비어 있습니다로 스크롤하고 추가할 파일 유형을 선택합니다.
  3. 웹 IDE에서 이 파일을 원하는 대로 편집한 다음 커밋 생성을 선택합니다.
  4. 커밋 메시지를 입력하고 커밋을 선택합니다.

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

이슈에서

전제 조건:

  • 프로젝트에 대해 최소한의 개발자 역할이 있어야 합니다.

이슈를 보는 중에 해당 페이지에서 직접 연관된 브랜치를 생성할 수 있습니다. 이렇게 생성된 브랜치는 변수를 포함한 이슈로부터 브랜치 이름의 기본 패턴을 사용합니다.

전제 조건:

  • 프로젝트에 대해 최소한의 개발자 역할이 있어야 합니다.

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

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

브랜치 관리 및 보호

GitLab은 개별 브랜치를 보호하는 여러 가지 방법을 제공합니다. 이러한 방법은 브랜치가 생성되어 삭제될 때까지 감시 및 품질 체크를 받도록 보장합니다:

  • 프로젝트의 기본 브랜치는 추가로 보호를 받습니다.
  • 보호된 브랜치를 구성하여 누가 브랜치에 커밋할 수 있고, 다른 브랜치를 병합할 수 있으며, 브랜치 자체를 다른 브랜치에 병합할 수 있는지를 제한할 수 있습니다.
  • 승인 규칙을 구성하여 브랜치가 병합되기 전에 보안 관련 승인을 포함한 리뷰 요구 사항을 설정할 수 있습니다.
  • 제3자 상태 확인을 통합하여 브랜치 내용이 품질 기준을 충족하는지 확인할 수 있습니다.

브랜치를 관리할 수 있습니다: - GitLab 사용자 인터페이스로. - 명령줄에서 Git을 사용하여. - 브랜치 API를 통해.

브랜치 모두 보기

GitLab 사용자 인터페이스에서 브랜치를 보고 관리하려면 다음을 수행하세요.

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

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

  • 모든 브랜치 보기 또는 활성 또는 유효하지 않은 브랜치만 필터링하기.

    커밋이 마지막 3개월 이내에 이루어진 경우 브랜치가 활성으로 간주됩니다. 그렇지 않으면 유효하지 않은 것으로 간주됩니다.

  • 새 브랜치 생성하기.
  • 브랜치 비교.
  • 병합된 브랜치 삭제하기.

구성된 보호가 있는 브랜치 보기

History
자체 관리 GitLab에서는 기본적으로이 기능을 사용할 수 있습니다. 관리자는 기능 플래그 branch_rules를 비활성화할 수 있습니다. GitLab.com 및 전용 GitLab에서는이 기능을 사용할 수 있습니다.

저장소의 브랜치는 여러 가지 방법으로 보호될 수 있습니다. 다음을 수행할 수 있습니다:

  • 누가 브랜치로 푸시할 수 있는지 제한하기.
  • 누가 브랜치를 병합할 수 있는지 제한하기.
  • 모든 변경의 승인을 요구하기.
  • 외부 테스트 통과를 요구하기.

브랜치 규칙 요약 페이지에는 구성된 보호가 있는 모든 브랜치와 그 보호 방법이 표시됩니다:

구성된 보호가 있는 브랜치의 예시

필수 조건:

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

브랜치 규칙 개요 목록을 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 저장소를 선택합니다.
  3. 브랜치 규칙을 확장하여 보호가 있는 모든 브랜치를 볼 수 있습니다.
    • 새 브랜치에 보호 추가:
      1. 브랜치 규칙 추가를 선택합니다.
      2. 보호된 브랜치 생성을 선택합니다.
    • 기존 브랜치의 보호에 대한 자세한 정보 보기:
      1. 자세한 정보를 보려는 브랜치를 식별합니다.
      2. 자세한 정보를 보려면 세부 정보 보기를 선택하세요. 이렇게 하면 다음에 대한 정보를 볼 수 있습니다:

브랜치 이름 지정

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

GitLab은 모든 브랜치에 이러한 추가 규칙을 강제합니다:

  • 브랜치 이름에 공백을 허용하지 않습니다.
  • 40자의 16진수 문자로 구성된 브랜치 이름은 금지됩니다. 이는 Git 커밋 해시와 유사하기 때문입니다.
  • 브랜치 이름은 대소문자를 구분합니다.

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

다른 소프트웨어 패키지와의 최상의 호환성을 위해 다음만 사용하십시오:

  • 숫자
  • 하이픈 (-)
  • 밑줄 (_)
  • ASCII 표준 표의 소문자

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

특정 형식의 브랜치 이름은 여러 가지 이점을 제공합니다:

  • 브랜치 이름에이슈 번호를 접두어로 사용하여 병합 요청 작업 흐름을 간소화합니다.
  • 브랜치 이름별로 브랜치 보호 자동화합니다.
  • 브랜치가 GitLab에 푸시되기 전에 푸시 규칙을 사용하여 브랜치 이름을 테스트합니다.
  • 병합 요청에서 실행할 CI/CD 작업을 정의합니다.

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

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

필수 조건:

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

이슈에서 만든 브랜치에 대한 기본 패턴을 변경하려면:

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

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

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

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

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. 변경 사항 표시 아래에서 브랜치 비교 방법을 선택합니다:
    • 소스에서 들어오는 변경만 (기본 설정)은 최신 공통 커밋 이후 소스 브랜치에서 발생한 차이를 보여줍니다.
      소스 브랜치가 생성된 후 대상 브랜치에 따로 발생한 관련 없는 변경 사항은 포함되지 않습니다.
      이 방법은 git diff <from>...<to> Git 명령어를 사용하여 브랜치를 비교하며,
      실제 커밋 대신 병합 베이스를 사용하므로 체리픽된 커밋의 변경 사항이 새로운 변경 사항으로 표시됩니다.
    • 소스가 생성된 이후 대상의 변경 포함은 두 브랜치 간의 모든 차이를 보여줍니다.
      이 방법은 git diff <from> <to> Git 명령어를 사용합니다.
  6. 비교를 선택하여 커밋 목록과 변경된 파일을 표시합니다.
  7. 선택 사항. 소스와 대상을 반대로 하려면 리비전 바꾸기를 선택하세요 ().

병합된 브랜치 삭제

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

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

전제 조건:

  • 프로젝트에 대한 적어도 개발자 역할이 있어야 합니다.

다음 단계:

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

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

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

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

병합 요청을 생성할 때 워크플로는 브랜치 이름을 확인합니다. 브랜치 이름이 워크플로와 일치하면 병합 요청이 지정한 브랜치를 대상으로 합니다. 브랜치 이름이 일치하지 않으면 병합 요청은 프로젝트의 기본 브랜치를 대상으로 합니다.

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

전제 조건:

  • 프로젝트에 대한 적어도 메인테이너 역할이 있어야 합니다.

대상 브랜치 워크플로를 만들려면:

  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 브랜치는 분리된 엔티티가 아니라, 커밋 SHA의 집합에 부착된 레이블입니다. GitLab이 브랜치가 병합되었는지 여부를 결정할 때, 그 브랜치의 타깃 브랜치에 해당 커밋 SHAs의 존재 여부를 확인합니다. 이러한 동작은 두 병합 요청이 동일한 커밋을 포함할 때 예상치 못한 결과를 초래할 수 있습니다. 이 예에서, 브랜치 B와 C는 모두 브랜치 A에서 커밋(3)을 시작합니다.

gitGraph commit id:"a" branch "branch A" commit id:"b" commit id:"c" type: HIGHLIGHT branch "branch B" commit id:"d" checkout "branch A" branch "branch C" commit id:"e" checkout main merge "branch B" id:"merges commits b, c, d"

브랜치 B를 병합하면, 브랜치 A도(당신의 조치 없이)병합된 것처럼 보입니다. 왜냐하면 브랜치 A의 모든 커밋이 이제 타깃 브랜치 main에 나타나기 때문입니다. 브랜치 C는 병합되지 않은 상태로 남아 있을 것입니다. 왜냐하면 커밋 5가 브랜치 A나 B의 일부가 아니기 때문입니다.

병합 요청 A는 여전히 병합된 상태이며, 해당 브랜치로 새로운 커밋을 푸시하려고 해도 그대로 유지됩니다. 만약 병합 요청 A에 변경 사항이 남아 있어(병합 요청 A의 일부가 아닌)아직 병합되지 않은 경우, 해당 변경 사항에 대한 새로운 병합 요청을 엽니다.

오류: 모호한 HEAD 브랜치가 존재함

Git 2.16.0 이전 버전에서는 HEAD라는 이름의 브랜치를 만들 수 있었습니다. 이 HEAD라는 브랜치는 Git이 활성(체크아웃된) 브랜치를 설명하는 데 사용하는 내부 참조(또한 HEAD라고 함)와 충돌합니다. 이러한 이름 충돌은 귀하의 저장소의 기본 브랜치를 업데이트하는 것을 방해할 수 있습니다: 

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

이 문제를 해결하려면:

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

Git 버전 2.16.0 이후에는 이 이름으로 브랜치를 만들 수 없습니다.

작성한 모든 브랜치 찾기

프로젝트에서 작성한 모든 브랜치를 찾으려면 Git 저장소에서 다음 명령을 실행하세요: 

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

프로젝트에 있는 모든 브랜치의 총계를, 작성자 별로 정렬하여 얻으려면 Git 저장소에서 다음 명령을 실행하세요: 

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