# 지점

GitHub 분기를 사용하여 개발 작업을 격리하고, 기본 분기를 관리하고, 끌어오기 요청 및 분기 보호를 사용하여 효과적으로 공동 작업할 수 있습니다.

## 브랜치 정보

분기를 사용하면 리포지토리의 포함된 영역에서 기능을 개발하거나 버그를 수정하거나 새 아이디어를 안전하게 실험할 수 있습니다.

항상 기존 브랜치에서 새로운 브랜치를 만듭니다. 일반적으로 리포지토리의 기본 분기에서 새 분기를 만들 수 있습니다. 그런 다음 다른 사용자가 리포지토리에 적용하는 변경 내용과 격리된 상태로 이 새 분기에서 작업할 수 있습니다.

기능을 빌드하기 위해 만드는 분기를 일반적으로 기능 분기 또는 토픽 분기라고 합니다.
[Managing branches within your repository](/ko/enterprise-server@3.19/pull-requests/how-tos/commit-changes/managing-branches-within-your-repository)을(를) 참조하세요.

분기를 사용하여 사이트를 게시할 수도 있습니다 GitHub Pages .
[GitHub Pages란?](/ko/enterprise-server@3.19/pages/getting-started-with-github-pages/what-is-github-pages)을(를) 참조하세요.

분기를 만들거나, 끌어오기 요청을 열거나, 끌어오기 요청에서 분기를 삭제하고 복원하려면 리포지토리에 대한 쓰기 권한이 있어야 합니다.
[GitHub 대한 액세스 권한](/ko/enterprise-server@3.19/get-started/learning-about-github/access-permissions-on-github)을(를) 참조하세요.

## 기본 분기 정보

GitHub에 콘텐츠가 있는 리포지토리를 만들면 GitHub가 단일 분기로 리포지토리를 만듭니다. 리포지토리의 이 첫 번째 분기는 기본 분기입니다. 기본 분기는 누구나 리포지토리를 방문할 때 표시되는 분기 GitHub 입니다. 또한 기본 분기는 누군가가 리포지토리를 복제할 때 Git에서 로컬로 체크 아웃하는 초기 분기이기도 합니다. 다른 분기를 지정하지 않는 한 리포지토리의 기본 분기는 새 끌어오기 요청 및 코드 커밋의 기본 분기입니다.

기본적으로 GitHub 새 리포지토리의 기본 분기 `main` 이름을 지정합니다.

기존 리포지토리의 기본 분기를 변경할 수 있습니다. 자세한 내용은 [기본 분기 변경](/ko/enterprise-server@3.19/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/changing-the-default-branch)을(를) 참조하세요.

새 리포지토리의 기본 분기 이름을 설정할 수 있습니다. 자세한 내용은 [리포지토리의 기본 분기 이름 관리](/ko/enterprise-server@3.19/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-the-default-branch-name-for-your-repositories), [조직의 리포지토리에 대한 기본 분기 이름 관리](/ko/enterprise-server@3.19/organizations/managing-organization-settings/managing-the-default-branch-name-for-repositories-in-your-organization), [엔터프라이즈에서 리포지토리 관리 정책 적용](/ko/enterprise-server@3.19/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-repository-management-policies-in-your-enterprise#enforcing-a-policy-for-the-default-branch-name)을(를) 참조하세요.

## 보호된 브랜치 작업하기

보호된 분기는 유지 관리자가 중요한 분기에 규칙을 적용하는 데 도움이 됩니다. 보호된 분기는 강제 푸시 또는 삭제를 차단하거나, 상태 검사가 필요하거나, 검토가 필요하거나, 코드 소유자 승인이 필요하거나, 변경 내용이 병합되기 전에 서명된 커밋을 요구할 수 있습니다.

이러한 보호 기능은 팀이 중요한 분기를 안정적으로 유지하고 끌어오기 요청이 병합되기 전에 기대치를 명확하게 하는 데 도움이 됩니다. 끌어오기 요청을 병합할 수 있는지 확인하려면 끌어오기 요청의 **대화** 탭 아래쪽에 있는 병합 상자를 선택합니다. [보호된 분기 정보](/ko/enterprise-server@3.19/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)을 참조하세요.

> \[!NOTE]
> 리포지토리 관리자인 경우 분기 보호가 “관리자 포함”으로 설정되지 않은 한 끌어오기 요청이 요구 사항을 충족하지 않더라도 분기 보호가 설정된 분기의 끌어오기 요청을 병합할 수 있습니다.

## 끌어오기 요청의 분기 비교

끌어오기 요청은 헤드 분기에서 제안된 변경 내용을 기본 분기와 비교합니다. 끌어오기 요청을 만들 때 변경 내용을 비교하는 기본 분기를 변경할 수 있습니다.
**파일 변경 탭**에는 끌어오기 요청이 병합될 경우 변경되는 내용이 표시됩니다.

Diff 보기는 검토자가 모든 커밋을 읽지 않고도 변경 내용을 이해하는 데 도움이 됩니다. 통합 차이, 분할 차이, 리치 차이 또는 원본 차이는 볼 수 있습니다. 공백 변경 무시; 또는 파일을 필터링하여 가장 관련성이 큰 변경 내용에 집중합니다.

![끌어오기 요청의 "파일 변경됨" 탭 스크린샷 "Diff view" 메뉴가 짙은 주황색으로 윤곽선이 그려져 있습니다.](/assets/images/help/pull_requests/diff-settings-menu.png)

끌어오기 요청이 리포지토리 차이 제한을 초과하거나 리포지토리의 *.gitattributes* 파일의 규칙에 의해 파일이 숨겨지는 경우 차이는 표시되지 않을 수 있습니다.
[리포지토리 제한](/ko/enterprise-server@3.19/repositories/creating-and-managing-repositories/repository-limits#diff-limits) 및 [변경된 파일이 GitHub 표시되는 방식 사용자 지정](/ko/enterprise-server@3.19/repositories/working-with-files/managing-files/customizing-how-changed-files-appear-on-github)을(를) 참조하세요.

### 세 점 및 두 점 Git Diff 비교

이 `git diff` 명령은 두 가지 비교 메서드를 지원합니다. 3점 차이 표시에 GitHub 대한 끌어오기 요청입니다.

| Method | Command          | 비교되는 내용                                      |
| ------ | ---------------- | -------------------------------------------- |
| 3점     | `git diff A...B` | 두 분기(병합 기준)의 가장 최근 커밋과 토픽 분기의 최신 버전입니다.      |
| 2점     | `git diff A..B`  | 기본 분기의 가장 최근 상태(예: `main`)와 토픽 분기의 최신 버전입니다. |

두 개의 점 Diff는 SHA 또는 OID(개체 ID)와 같은 두 개의 Git 커밋 참조를 서로 직접 비교합니다. 2 GitHub도트 차이 비교의 Git 커밋 참조를 동일한 리포지토리 또는 해당 포크로 푸시해야 합니다.

*Pro Git* 책 사이트에서 [Git diff 옵션을](https://git-scm.com/docs/git-diff#git-diff-emgitdiffemltoptionsgtltcommitgtltcommitgt--ltpathgt82308203) 참조하세요.

### 약 3점 비교 GitHub

3점 비교는 병합 베이스를 사용하므로 "끌어오기 요청이 도입하는 내용"에 중점을 둡니다.

2점 비교를 사용하는 경우 토픽 분기를 변경하지 않은 경우에도 기본 분기가 업데이트되면 diff가 변경됩니다. 또한 2점 비교는 기본 분기에 중점을 두어 토픽 분기에 의해 도입된 변경 내용을 이해하기 어렵게 만들 수 있습니다.

반면, 3점 비교는 분기가 서로 다른 이후 토픽 분기에 의해 도입된 변경 내용을 계속 보여 줍니다.

### 자주 병합합니다.

혼동을 방지하려면 기본 분기(예: `main`)를 자주 토픽 분기에 병합합니다. 기본 분기를 병합하면 2점과 3점 비교로 표시되는 차이는 동일합니다. 가능한 한 빨리 풀 리퀘스트를 병합하실 것을 권장합니다. 이렇게 하면 참가자가 끌어오기 요청을 더 작게 만들 수 있습니다. 일반적으로 권장됩니다.

## 추가 읽기

* [끌어오기 요청](/ko/enterprise-server@3.19/pull-requests/reference/pull-requests)
* 용어집의 GitHub[GitHub 용어집](/ko/enterprise-server@3.19/get-started/learning-about-github/github-glossary#branch)
* Git 설명서의 [분기에 대한 설명 요약](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell)
* [포크들](/ko/enterprise-server@3.19/pull-requests/reference/forks)