브랜치

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

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

프로젝트가 성장함에 따라 팀은 브랜치 네이밍 패턴을 따라 새로운 브랜치를 생성합니다. 각 브랜치는 변경 사항 세트를 나타내며, 이를 통해 개발 작업을 병렬로 수행할 수 있습니다. 한 브랜치에서의 개발 작업은 다른 브랜치에 영향을 주지 않습니다.

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

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

브랜치 생성

전제 조건:

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

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

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

빈 프로젝트에서

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

전제 조건:

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

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

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

GitLab이 기본 브랜치를 만들고 파일을 추가합니다.

이슈에서

전제 조건:

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

이슈를 보는 중에 해당 페이지에서 직접 연결된 브랜치를 생성할 수 있습니다. 이 방법으로 만든 브랜치는 이슈에서 브랜치 네임에 대한 기본 패턴 를 사용하며, 변수를 포함할 수 있습니다.

전제 조건:

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

이슈에서 브랜치를 만들려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 계획 > 이슈를 선택하고 이슈를 찾습니다.
  3. 이슈 설명 아래에서 Merge Request 생성 드롭다운 디렉터리을 찾고, 를 선택하여 드롭다운 디렉터리을 표시합니다.
  4. 브랜치 생성을 선택합니다. 이 프로젝트의 기본 브랜치를 기반으로 하여 제공된 기본 브랜치 이름입니다. 원하는 경우 다른 브랜치 이름을 입력하세요.
  5. 프로젝트의 기본 브랜치를 기반으로한 브랜치를 만들기 위해 브랜치 생성을 선택합니다.

브랜치 관리 및 보호

GitLab은 개별 브랜치를 보호하기 위한 여러 가지 방법을 제공합니다. 이러한 방법을 사용하면 브랜치가 생성된 후 삭제될 때까지 감독 및 품질 검사를 받을 수 있습니다:

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

브랜치를 다음과 같이 관리할 수 있습니다:

  • GitLab 사용자 인터페이스로
  • 명령줄의 Git을 통해
  • 브랜치 API를 통해

모든 브랜치 보기

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

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

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

  • 모든 브랜치를 볼 수 있거나 작업이 세 달 이내에 커밋된 브랜치 또는 사용되지 않는 브랜치만 볼 수 있습니다.
    • 한 브랜치가 세 달 이내에 커밋되었다면 활성 브랜치로, 그렇지 않으면 사용되지 않는 브랜치로 간주됩니다.
  • 새 브랜치를 생성할 수 있습니다.
  • 브랜치 비교를 할 수 있습니다.
  • Merge된 브랜치를 삭제할 수 있습니다.

보호가 구성된 브랜치 보기

리포지터리의 브랜치는 여러 가지 방법으로 보호될 수 있습니다. 다음을 할 수 있습니다:

  • 누가 브랜치로 푸시할 수 있는지 제한하기
  • 브랜치를 Merge할 수 있는 누구를 제한하기
  • 모든 변경 사항에 대한 승인을 요청하기
  • 외부 테스트가 통과되어야 하는 요구하기

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

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

전제 조건:

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

브랜치 규칙 개요 디렉터리을 보려면:

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

브랜치 규칙 생성

  • 16.8 GitLab에서 add_branch_rules라는 플래그로 도입되었습니다. 기본적으로 비활성화됩니다.
  • 16.11 GitLab에서 플래그 add_branch_rules가 edit_branch_rules로 이름이 변경되었고 기본적으로 비활성화됩니다.
  • 모든 브랜치 및 모든 보호된 브랜치 옵션은 17.0 GitLab에서 도입되었습니다.
이 기능의 사용 가능 여부는 피처 플래그로 제어됩니다. 자세한 내용은 이력을 확인하세요. 이 기능은 테스트용으로 사용 가능하지만, 실제 운영에는 준비되지 않았습니다.

전제 조건:

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

브랜치 규칙을 만들려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 리포지터리를 선택합니다.
  3. 브랜치 규칙을 확장합니다.
  4. 그런 다음:
    • 특정한 브랜치 이름 또는 패턴을 입력하려면:
      1. 브랜치 규칙 추가 드롭다운 디렉터리에서 브랜치 이름 또는 패턴을 선택합니다.
      2. 대화 상자에서 브랜치 규칙 생성 드롭다운 디렉터리에서 브랜치 이름을 선택하거나 *를 입력하여 와일드카드를 생성합니다.
    • 프로젝트의 모든 브랜치를 보호하려면:
      1. 브랜치 규칙 추가 드롭다운 디렉터리에서 모든 브랜치를 선택합니다.
      2. 규칙의 세부 정보 페이지에서 Merge Request 승인 아래에서 규칙에 필요한 승인 수를 입력하세요.
    • 이미 보호된 프로젝트의 모든 브랜치를 보호하려면:
      1. 브랜치 규칙 추가 드롭다운 디렉터리에서 모든 보호된 브랜치를 선택합니다.
      2. 규칙의 세부 정보 페이지에서 Merge Request 승인 아래에서 규칙에 필요한 승인 수를 입력하세요.

브랜치 규칙 편집

  • GitLab 16.8에서 add_branch_rules 라는 플래그로 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • 피처 플래그 add_branch_rules 가 GitLab 16.11에서 edit_branch_rules로 이름이 변경되었습니다. 기본적으로 비활성화되어 있습니다.

플래그: Self-Managed GitLab의 경우, 기본적으로 이 기능을 사용할 수 없습니다. 프로젝트당이나 전체 인스턴스에 사용할 수 있도록하려면 관리자가 edit_branch_rules라는 피처 플래그를 활성화할 수 있습니다. GitLab.com 및 전용 GitLab에서는 이 기능을 사용할 수 없습니다. 이 기능은 프로덕션 환경에서 사용할 준비가 되지 않았습니다.

전제 조건:

  • 해당 프로젝트에서 적어도 유지자(Maintainer) 역할을 가져야 합니다.

브랜치 규칙을 편집하려면:

  1. 왼쪽 사이드 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 리포지터리를 선택합니다.
  3. 브랜치 규칙을 확장합니다.
  4. 편집하려는 규칙 옆에서 세부 정보 보기를 선택합니다.
  5. 오른쪽 상단에서 편집을 선택합니다.
  6. 대화상자에서 브랜치 규칙 만들기 드롭다운 디렉터리에서 브랜치 이름을 선택하거나 *를 입력하여 와일드카드를 만듭니다.
  7. 업데이트를 선택합니다.

브랜치 규칙 삭제

  • GitLab 16.8에서 add_branch_rules 라는 플래그로 도입되었습니다. 기본적으로 비활성화되어 있습니다.
  • 피처 플래그 add_branch_rules 가 GitLab 16.11에서 edit_branch_rules로 이름이 변경되었습니다. 기본적으로 비활성화되어 있습니다.

플래그: Self-Managed GitLab의 경우, 기본적으로 이 기능을 사용할 수 없습니다. 프로젝트당이나 전체 인스턴스에 사용할 수 있도록하려면 관리자가 edit_branch_rules라는 피처 플래그를 활성화할 수 있습니다. GitLab.com 및 전용 GitLab에서는 이 기능을 사용할 수 없습니다. 이 기능은 프로덕션 환경에서 사용할 준비가 되지 않았습니다.

전제 조건:

  • 해당 프로젝트에서 적어도 유지자(Maintainer) 역할을 가져야 합니다.

브랜치 규칙을 삭제하려면:

  1. 왼쪽 사이드 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 리포지터리를 선택합니다.
  3. 브랜치 규칙을 확장합니다.
  4. 삭제하려는 규칙 옆에서 세부 정보 보기를 선택합니다.
  5. 오른쪽 상단에서 규칙 삭제를 선택합니다.
  6. 확인 대화상자에서 브랜치 규칙 삭제를 선택합니다.

브랜치에 이름 지정

Git은 브랜치 이름이 다른 도구와 호환되도록 하기 위해 브랜치 이름 규칙을 강제합니다. GitLab은 잘 구성된 브랜치 이름에 대해 추가 요구 사항을 추가하고 이로 인해 추가 혜택을 제공합니다.

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

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

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

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

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

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

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

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

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

전제 조건:

  • 해당 프로젝트에서 적어도 유지자(Maintainer) 역할을 가져야 합니다.

이슈에서 생성된 브랜치의 기본 패턴을 변경하려면:

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

이슈 번호로 브랜치 이름에 접두사 붙이기

Merge Request 생성을 간소화하려면, Git 브랜치 이름을 이슈 번호로 시작하고 하이픈으로 구분하여 시작하세요. 예를 들어, 브랜치를 #123 이슈에 연결하려면 브랜치 이름을 123-로 시작하세요.

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

GitLab은 이슈 번호를 Merge Request으로 데이터를 가져옵니다:

  • 이슈는 Merge Request과 연관되었다고 표시됩니다. 이슈와 Merge Request은 서로 링크를 표시합니다.
  • 브랜치가 이슈에 연결됩니다.
  • 만약 프로젝트에 기본 종료 패턴이 구성된 경우, Merge Request의 Merge은 관련된 이슈도 자동으로 닫습니다.
  • 이슈 마일스톤과 레이블이 Merge Request으로 복사됩니다.

브랜치 비교

리포지터리에서 브랜치를 비교하려면:

  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 명령어을 사용하여 브랜치를 비교하며, 실제 커밋 대신 Merge 베이스를 사용하므로 cherry-pick된 커밋의 변경 사항이 새 변경 사항으로 표시됩니다.
    • 원본이 생성된 이후의 대상의 변경 사항도 포함은 두 브랜치 사이의 모든 차이를 보여줍니다. 이 방법은 git diff <from> <to> Git 명령어을 사용하여 브랜치를 비교합니다.
  6. 비교를 선택하여 커밋 디렉터리과 변경된 파일 디렉터리을 표시합니다.
  7. 선택 사항. 원본과 대상을 바꾸려면 리비전 바꾸기를 선택합니다(substitute).

머지된 브랜치 삭제

모든 이 조건을 충족하는 경우에만 Merge된 브랜치를 대량으로 삭제할 수 있습니다.

  • 그들은 보호된 브랜치가 아니다.
  • 프로젝트의 기본 브랜치에 Merge되었다.

전제 조건:

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

다음을 수행하려면:

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

대상 브랜치용 워크플로 구성

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

일부 프로젝트는 develop 및 qa와 같은 개발용으로 여러 장기 브랜치를 사용합니다. 이러한 프로젝트에서 main을 기본 브랜치로 유지하길 원하지만 Merge Request이 develop 또는 qa를 대상으로 할 것으로 예상할 수 있습니다. 대상 브랜치 워크플로는 프로젝트의 적절한 개발 브랜치를 대상으로 하는지 확인하는 데 도움이 됩니다.

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

규칙은 “첫 번째 일치” 기준으로 처리됩니다. 브랜치 이름과 일치하는 두 규칙이 있는 경우, 가장 위의 규칙이 적용됩니다.

전제 조건:

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

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

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

예시

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

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

이러한 대상 브랜치는 다음을 나타내는 프로젝트의 Merge Request을 만드는 프로세스를 간소화합니다:

  • main은 응용 프로그램의 배포된 상태를 나타내는 데 사용됩니다.
  • develop와 같은 다른 장기 실행 브랜치에서 현재 릴리스되지 않은 개발 작업을 추적합니다.

작업 흐름이 처음에 새로운 기능을 main이 아니라 develop에 위치시키면, 이러한 대상 브랜치는 feature/* 또는 bug/*와 일치하는 모든 브랜치가 실수로 main을 대상으로 하지 않도록 합니다.

main으로 릴리스할 준비가 되면 release/*와 같은 이름의 브랜치를 생성하고, 이 브랜치가 main을 대상으로 하도록 합니다.

대상 브랜치 워크플로 삭제

대상 브랜치 워크플로를 제거하면 기존 Merge Request이 변경되지 않습니다.

전제 조건:

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

다음을 수행하려면:

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

관련 주제

문제 해결

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

더 깊은 기술적 수준에서 Git 브랜치는 별개의 엔티티가 아닌 커밋 SHA 집합에 부착된 라벨입니다. GitLab이 브랜치가 Merge되었는지 여부를 결정할 때 그 커밋 SHA가 있는지 대상 브랜치를 확인합니다. 이러한 동작은 두 개의 Merge Request이 동일한 커밋을 포함할 때 예상치 못한 결과를 초래할 수 있습니다. 예를 들어, 브랜치 B 및 C가 모두 브랜치 A의 동일한 커밋(3)에서 시작하는 경우:

%%{init: { "fontFamily": "GitLab Sans" }}%% 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를 Merge하면, 브랜치 A도 Merge된 것으로 나타납니다(당신의 행동과는 무관하게) 이는 브랜치 A의 모든 커밋이 대상 브랜치 main에 나타나기 때문입니다. 브랜치 C는 Merge되지 않은 상태로 남아 있습니다. 왜냐하면 커밋 5가 브랜치 A 또는 B의 일부가 아니기 때문입니다.

Merge Request A는 Merge된 상태로 유지됩니다. 심지어 해당 브랜치에 새 커밋을 푸시하려고 해도요. Merge Request A에 대한 변경 사항이 아직 Merge되지 않았으면(Merge Request A의 일부가 아니기 때문에), 이에 대한 새로운 Merge Request을 엽니다.

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

2.16.0 이전의 Git 버전에서 HEAD 라는 이름의 브랜치를 생성할 수 있었습니다. 이 이름이 HEAD인 브랜치는 Git이 활성(체크아웃된) 브랜치를 설명하는 데 사용하는 내부 참조(또한 HEAD로 명명됨)와 충돌합니다. 이러한 이름 충돌은 리포지터리의 기본 브랜치를 업데이트하지 못하게 할 수 있습니다: 

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

이 문제를 해결하려면:

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

Git의 2.16.0 버전 이후에서는 이러한 이름으로 브랜치를 생성하지 못하도록 조치되었습니다.

프로젝트에 작성한 모든 브랜치 찾기

프로젝트에서 작성한 모든 브랜치를 찾으려면 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