[Git] 6장 브랜치

참조

• https://thebook.io/080212/

새로운 작업

• 브랜치(branch)는 나뭇가지, 지사, 분점 등 줄기 하나에서 뻗어 나온 갈림길을 의미합니다.
• 큰 나무 줄기에서 작은 줄기가 뻗어 나오는 것처럼 저장 공간 하나에서 가상의 또 다른 저장 공간을 만드는 것이라고 생각하면 됩니다.

브랜치 작업

• 우리는 오랫동안 알게 모르게 브랜치 작업을 해 왔습니다.
• 보통 새로운 기능을 추가하거나 많은 변경이 예상될 때 작업 폴더를 통째로 복사하고, 복사한 폴더 이름을 변경했습니다.
• 안정적인 기존 코드는 남겨 두고, 복제된 작업 폴더에서 도전적인 작업들을 하기 위해 코드를 분리합니다.
• 커밋은 파일의 수정 이력을 관리하는 데 사용한다면, 브랜치는 프로젝트를 독립적으로 관리하는데 사용합니다.
• 개발자는 항상 안정된 코드 상태를 유지하고, 개발 중인 작업과 구분하여 관리해야 합니다.
• 잦은 버그 수정과 새로운 기능을 구현할 때마다 작업 폴더를 복사하는 것은 프로젝트를 유지 관리하는 측면에서 좋지 않습니다.
• 많은 프로젝트 폴더를 복제하면 향후 코드를 통합하기 어렵습니다.
• 깃을 사용하면 프로젝트 작업 폴더를 복사하지 않고 기존 코드와 분리해서 작업할 수 있습니다.

깃 브랜치 특징

• 깃 브랜치는 기존 폴더를 복제하는 것과 다르게 가상 폴더를 사용하여 개발 작업을 구분합니다.

가상 폴더

• 깃의 브랜치는 작업 폴더를 실제로 복사하지 않고, 가상 폴더 를 생성합니다.
• 외부적으로는 물리적인 파일 하나만 있는 것으로 보입니다.
• 생성된 작업 폴더는 물리적으로 복제된 구조보다 유연하게 처리할 수 있습니다.
• 브랜치로 생성된 가상 폴더는 빠르게 공간 이동이 가능합니다.
• 개발자는 쉽게 가상 폴더인 브랜치를 이동하면서 프로젝트를 수행할 수 있습니다.

독립적인 동작

• 브랜치를 이용하면 원본 폴더와 분리하여 독립적인 개발 작업을 수행할 수 있습니다.
• 기존에는 소스 코드의 작업 폴더를 별도로 생성했습니다.
• 물리적으로 복사된 각자의 폴더에서 코드를 작업한 후 소스 코드 2개를 다시 하나로 합쳐야 했습니다.
• 코드를 하나로 합치려면 작업 내역들을 일일이 찾아 정리해야 합니다.
• 소스 코드를 하나로 통합하는 것은 매우 힘든 작업입니다.
• 하지만 깃과 같은 버전 관리 시스템을 이용하면 분리된 코드를 좀 더 쉽게 병합할 수 있습니다.
• 분리된 브랜치에서 소스 코드를 각자 수정한 후 원본 코드에 병합하는 명령만 실행하면 됩니다.
• 깃의 브랜치는 규모가 큰 코드 수정이나 병합을 처리할 때 매우 유용합니다.

실습 준비

• 깃은 기본적으로 master 브랜치 하나를 가지고 있습니다.
• 그리고 브랜치는 HEAD 포인터를 가지고 있습니다.
• 실습을 통해 구체적인 브랜치 작업과 HEAD 동작을 알아보겠습니다.

저장소 생성 및 초기화

• 브랜치 실습을 위한 환경을 구축합니다.
• 저는 소스트리를 이용하여 환경을 구축하였습니다.

$ cd 메인폴더
$ makdir gitstudy06
$ cd gitstudy06

기본 브랜치

• 모든 커밋과 이력은 브랜치에 기록됩니다.
• 깃은 최소한 브랜치가 1개 이상 필요합니다. 따라서 저장소를 처음 초기화 하면 master 브랜치 하나가 자동으로 생성됩니다.
• 첫 번째 커밋은 master 브랜치에서 시작합니다. 초기화한 후에 status 명령어를 실행해 봅니다.

• status 명령어의 출력 결과 메시지에서 On branch master 를 확인할 수 있습니다.
• 깃에서는 항상 현재 작업하는 브랜치 위치를 확인하는 것이 중요합니다.
• 또는 branch 명령어 로 현재 브랜치를 확인할 수 있습니다.

• branch 명령어는 생성된 모든 브랜치를 출력합니다.
• 앞 코드에서는 master 라는 이름의 브랜치가 하나 출력 되었습니다.
• 깃에서 기본적으로 선택되는 브랜치는 master 입니다.
• 하지만 꼭 기본값인 master 이르을 그대로 사용할 필요는 없습니다.
• 통상적으로 깃이 master 브랜치를 자동으로 생성하기 때문에 이를 그대로 많이 사용할 뿐입니다.

브랜치 생성

• 브랜치는 가상의 작업 폴더입니다. 처음 깃을 초기화할 때 워킹 디렉터리는 master 브랜치를 생성합니다.
• 브랜치를 생성하려면 기준이 되는 브랜치 또는 커밋이 하나 있어야 합니다.
• 그리고 깃은 master 브랜치를 기준으로 새로운 브랜치를 생성합니다.
• 브랜치는 공통된 커밋을 가리키는 지점입니다. 그리고 브랜치는 커밋처럼 SHA1 해시키를 가리킵니다.
• 하지만 커밋의 SHA1 해시키는 기억하기가 어렵기 때문에 특정 커밋을 가리키는 별칭을 만드는 것입니다.
• 이렇게 만든 별칭이 브랜치 입니다.
• 즉, 브랜치를 생성한다는 의미는 기존 브랜치 또는 커밋에 새로운 연결 고리를 하나 더 만드는 것과 같습니다.

브랜치 생성

• 처음 생성되는 기본 master 브랜치 외의 브랜치는 사용자가 직접 branch 명령어를 입력하여 생성해야 합니다.
• 브랜치를 생성한다는 것은 기본적으로 제공되는 master 브랜치 이외에 사용자가 직접 정의한 사용자 브랜치를 이야기하는 것입니다.
• 브랜치는 깃에서 또 하나의 개발 분기점을 의미합니다.
• 새로운 개발 분기점이 필요할 때는 브랜치를 추가로 생성할 수 있습니다.
• 브랜치 생성 개수에는 제한이 없습니다.
• 필요한 만큼 여러 브랜치를 생성할 수 있으며, 각 브랜치를 구분하려면 브랜치별로 이름을 지정해야 합니다.
• 브랜치를 생성할 때는 branch 명령어를 사용합니다.
• branch 명령어 뒤에 브랜치 이름을 인자값으로 추가합니다.
• 브랜치 이름만 입력하면 현재 HEAD 포인터를 기준으로 새로운 브랜치를 생성합니다.
• 직접 커밋 ID 인자 값을 지정하면, 지정한 커밋 ID를 기준으로 브랜치를 생성합니다.

$ git branch 브랜치이름 커밋ID

브랜치 이름

• 브랜치 이름을 지을 때 사전 예약된 명칭을 따로 없습니다.
• 다만 해당 브랜치 작업을 알기 쉬운 이름으로 짓는 것이 좋습니다. 또 깃 플로에서 정의한 브랜치 이름을 적용하는 것도 좋은 방법입니다.

깃 플로에서 정의한 브랜치 이름 규칙

• 기호(-)로 시작할 수 없습니다.
• 마침표(.)로 시작할 수 없습니다.
• 연속적인 마침표(...)를 포함할 수 없습니다.
• 빈칸, 공백 문자, 물결(~), 캐럿(^), 물음표(?), 별표(*), 대괄호([]) 등은 포함할 수 없습니다.
• 아스키 제어 문자는 포함할 수 없습니다.
• 주의할 점은 브랜치 이름은 중복해서 사용하지 않아야 한다는 것입니다. 이미 생성된 브랜치 이름과 동일한 이름으로 생성한다면 오류가 발생합니다.

소스트리로 브랜치 생성

• 소스트리로 새로운 브랜치를 하나 생성해 보겠습니다.

간단 브랜치 목록

• 깃 배시에서 브랜치 목록을 확인하는 방법은 간단합니다.
• branch 명령어만 입력하면 됩니다. branch 명령어는 단독으로도 실행할 수 있습니다.
• 생성된 전체 브랜치 목록을 출력합니다.
• 브랜치 이름 앞에는 별표(*)가 붙은 것을 확인하실 수 있습니다.
• 별표(*)는 현재 선택된 브랜치를 의미합니다.

$ git branch

브랜치 해시

• 브랜치는 특정한 커밋의 해시 값(SHA1)을 가리킵니다.
• 깃의 저수준 명령어인 rev-parse를 사용하면 현재 브랜치가 어떤 커밋 해시 값(SHA1)을 가리키는 지 확인할 수 있습니다.
• 브랜치의 해시 값과 브랜치를 생성한 기준 커밋의 해시 값은 동일합니다.
• 브랜치가 커밋의 해시를 기준으로 생성된다는 것을 다시 한 번 확인 할 수 있습니다.

$ git rev-parse 브랜치 이름

브랜치 세부 사항 확인

• 기본적인 branch 명령어는 간단한 브랜치 이름만 출력합니다.
• 하지만 옵션을 사용하면 좀 더 상세한 브랜치 정보를 얻을 수 있습니다.
• branch 명령어 뒤에 -v 또는 -verbose 옵션을 함께 사용하면 브랜치 이름, 커밋 ID, 커밋 메시지를 같이 볼 수 있습니다.
• 이전보다 좀 더 상세한 출력 결과를 얻을 수 있습니다.
• 이처럼 branch 명령어는 다양한 옵션을 제공합니다.
• branch 명령어 뒤에 -help 옵션을 추가하면 자세한 사용법을 볼 수 있습니다.

$ git branch -v -----브랜치 세부 사항 확인

체크아웃(Checkout)

• 호텔에서 퇴실할 때 체크아웃이라는 말을 합니다.
• 체크아웃은 객실을 비우고 떠나는 것을 의미합니다.
• 즉, 현재 브랜치를 떠나 새로운 브랜치로 들어간다는 의미 입니다.
• 깃에서 브랜치 간 이동할 때는 checkout 명령어를 사용합니다.
• 워킹 디렉터리는 선택한 브랜치 하나만 연결되어 있습니다.
• 즉, 한 브랜치에서만 작업과 커밋을 할 수 있습니다.
• 따라서 다른 브랜치에서 작업하려면 반드시 브랜치를 변경하여 워킹 디렉터리를 재설정해야 합니다.

$ git checkout 브랜치 이름

브랜치 동작 원리

• Checkout 명령어로 브랜치가 변경되면 깃은 내부적으로 몇 가지 동작을 수행합니다.
  • HEAD 정보는 항상 변경된 브랜치의 마지막 커밋을 가리킵니다. 이처럼 HEAD가 브랜치의 마지막 커밋을 의미하기 때문에 브랜치가 이동하면 HEAD 포인터도 함께 이동합니다.
  • 변경된 브랜치로 새로운 작업을 할 수 있도록 워킹 디렉터리를 변경합니다. 브랜치를 변경하려면 기존 브랜치의 워킹 디렉터리를 정리해야 합니다. 기존 브랜치의 워킹 디렉터리를 정리하지 않고서는 브랜치를 변경할 수 없습니다.

소스트리

• 소스트리에서 브랜치를 변경해 보도록 하겠습니다.
• 브랜치에 마우스를 가져다 대고 더블클릭 하면 ○ 마크가 이동합니다.

이전 브랜치

• 브랜치를 이동하려면 브랜치 이르을 적어 주어야 합니다.
• 하지만 새로운 브랜치가 아닌 이전 브랜치로 좀 더 편하게 이동할 수 있는 방법이 있습니다.
• 대시(-)를 사용하는 방법입니다.
• 리눅스에서 대시(-) 기호는 이전 디렉터리를 의미합니다. 이 대시를 사용하여 쉽게 이전 브랜치로 이돌할 수 있습니다.

$ git checkout -

워킹 디렉터리 정리

• 체크아웃을 사용하여 브랜치를 이동할 때는 주의 사항이 있습니다.
• 현재 작업하고 있는 워킹 디렉터리를 정리하고 넘어가야 합니다.
• 브랜치 동작 원리에서 브랜치가 변경되면 워킹 디렉터리도 같이 변환된다고 했습니다.
• 따라서 워킹 디렉터리 안에서 작성하던 내용이 있고, 커밋을 하지 않았다면 체크아웃 할 때 경고가 발생합니다.

• 현재 마스터 브랜치에서 작업을 하고 수정된 내용이 있어서 index.html 파일이 워킹 디렉토리 영역에 있습니다.
• 여기서 다시 footer 브랜치로 바꿔 보도록 하겠습니다.
• 경고창이 뜨는 것을 확인할 수 있습니다.

브랜치 로그

• 현재까지 작업한 브랜치 로그를 확인할 수 있습니다.

$ git log -graph -all

HEAD 포인터

• 깃은 객체의 포인터 개념을 사용합니다.
• 대표적인 객체 포인터는 HEAD 입니다. 깃 동작을 정확히 이해하려면 먼저 HEAD가 무엇인지 알아 두는 것이 좋습니다.

마지막 커밋

• 깃은 마지막 커밋 정보가 중요합니다.
• 깃은 마지막 커밋 정보를 기반으로 새로운 커밋을 생성합니다. 마지막 커밋은 새로운 커밋의 부모 커밋 입니다.
• 시스템이 매번 커밋할 때마다 마지막 커밋 정보를 찾으면 부하가 발생합니다.
• 깃은 마지막 커밋을 쉽게 확인할 수 있도록 특수한 포인터를 제공합니다. HEAD 는 작업중인 브랜치의 마지막 커밋 ID를 가리키는 참조 포인터입니다.
• 깃은 마지막 커밋을 가리키는 HEAD 포인터를 부모 커밋으로 대체하여 사용합니다.
• HEAD 포인터를 사용하여 빠르게 스냅샷을 생성할 수 있습니다.

• footer 브랜치의 마지막 커밋은 8bb7b95 이고, master 브랜치의 마지막 커밋은 3329bb2 입니다.
• footer 브랜치에서 새로운 커밋을 생성할 때 부모 커밋으로 8bb7b95을 가리키는 HEAD 포인터를 사용합니다.
• master 브랜치에서 새로운 커밋을 생성할 때는 3329bb2를 가리키는 HEAD 포인터를 사용합니다.
• 그리고 각 브랜치의 마지막 HEAD 포인터를 사용하여 커밋합니다.
• 현재 HEAD는 master 브랜치의 3329bb2를 가리킵니다.

브랜치 HEAD

• 브랜치를 이동하면 HEAD 포인트도 이동됩니다. 브랜치가 여러 개면 HEAD 포인트도 여러 개입니다.
• 각각의 브랜치마다 마지막 커밋이 다르기 때문입니다.
• 브랜치마다 마지막 커밋 ID를 가리키는 HEAD 포인터가 하나씩 있습니다.

• master 브랜치로 변경한 후, HEAD 포인터 위치는 이동된 브랜치의 커밋 3329bb2 을 가리킵니다.
• HEAD 포인터는 브랜치에 따라서 위치가 달라집니다.
• HEAD는 현재 작업하는 브랜치를 가리키기 때문입니다.

상대적 위치

• 깃의 HEAD 포인터는 내부적으로 커밋을 생성하고 브랜치를 관리하는 데 매우 유용합니다.
• 또 깃의 다양한 명령어를 입력할 때도 기준점으로 사용합니다. 마지막 커밋 위치인 HEAD 를 기준으로 상대적 커밋 위치도 지정할 수 있습니다.
• 상대적 커밋 위치를 지정할 때는 캐럿(^)과 물결(~) 기호를 같이 사용합니다.
• ^과 ~은 HEAD를 기준으로 몇 번째인지 상대적인 위치를 지정합니다.
• 예를 들어 HEAD 포인터 바로 이전의 커밋을 가리킨다면 HEAD^ 또는 HEAD~ 처럼 사용합니다.
• HEAD를 기준으로 이전 3개의 위치를 지정하고 싶다면 HEAD^^^, HEAD~ 처럼 사용해도 되지만 직관적으로 보기 좋게 **HEAD^3, HEAD3** 처럼 표현합니다.

AHEAD, BHEAD

• HEAD 앞에 A 또는 B가 붙은 AHEAD 와 BHEAD 포인터도 있습니다.
• 원격 저장소와 연동하여 깃을 관리한다면 브랜치마다 HEAD가 2개 있습니다.
• 로컬 저장소 브랜치의 HEAD 포인터와 원격 저장소 브랜치의 HEAD 포인터입니다.
• 원격 저장소와 로컬 저장소는 물리적으로 서로 다른 저장소입니다. 따라서 두 저장소의 마지막 커밋 위치가 일치하지 않을 수 있습니다.
• 이는 서로 다른 커밋을 가리키는 HEAD 포인터를 가진다는 의미입니다.
• AHEAD와 BHEAD는 서로 다른 저장소 간 HEAD 포인터의 위치 차이를 의미합니다.
• 깃은 항상 원격 저장소의 HEAD와 로컬 저장소의 HEAD를 비교합니다.
• HEAD 는 브랜치마다 다릅니다. 브랜치를 여러 개 운영한다면 다수의 AHEAD 와 BHEAD가 생길 수 있습니다.

생성과 이동

• 깃의 브랜치를 생성하는 동작과 이동하는 동작은 별개입니다.
• 브랜치 생성은 branch 명령어를 사용하고, 브랜치 이동은 checkout 명령어를 사용합니다.
• 브랜치를 생성하면서 동시에 생성된 브랜치로 이동하려면 별도의 명령을 실행해야 합니다.

자동 이동 옵션

• 브랜치 생성과 이동 명령을 따로 두 번씩 입력하는 것은 불편합니다.
• 깃은 브랜치 생성과 이동 명령을 한 번에 처리하는 옵션을 제공합니다.
• 다음과 같이 체크아웃할 때 -b 옵션을 같이 사용하면 브랜치 생성과 이동을 한 번에 할 수 있습니다.
• 새로운 hotfix 브랜치가 보이고 앞에 (*) 가 표시된 것을 확인할 수 있습니다.

$ git checkout -b 브랜치이름

커밋 이동

• 브랜치는 특정한 커밋에 별명을 부여한 것과 같습니다.
• 일반적으로 브랜치를 생성할 때는 마지막 커밋을 기준으로 합니다. 그리고 커밋 해시 값을 지정한 별칭으로 브랜치 목록에 등록합니다.
• 이러한 동작 원리를 볼때 브랜치 이름은 커밋 해시키와 동일 합니다. 따라서 브랜치로 이동할 때 꼭 브랜치 이름만 사용할 필요는 없습니다.
• 브랜치 이름 대신 커밋 해시키를 사용하여 체크아웃 할 수도 있습니다.

$ git checkout 커밋해시키

• 커밋 해시키를 사용하여 체크아웃 하려면 해시키를 알아야 합니다.
• 커밋 해시 값은 40자리로 매우 길어 입력할 때 오류가 많이 생깁니다.
• 해시키를 전체 사용하지 않고, 앞의 7자리 정도만 사용해도 무리가 없습니다.
• 이는 유일한 해시 값이 가지는 특징입니다. 7자리만 사용해도 중복될 확률이 적습니다.
  

  

HEAD 를 활용한 이동

• 커밋의 해시키를 사용하여 체크아웃하려면 복잡한 해시키를 알고 이어야 합니다.
• 또 복잡한 영어와 숫자로 표현하므로 입력 오류도 많이 생깁니다.
• 좀 더 간편하게 HEAD 포인터를 사용하여 체크아웃할 수도 있습니다.

$ git checkout HEAD~1 ------- 현재의 한 단계 전

돌아오기

• 커밋 해시키 또는 HEAD를 사용하여 과거의 커밋으로 체크아웃했다면 다시 현재 시점으로 돌아와야 합니다.
• 간단하게 다시 돌아오는 방법은 대시(-) 를 사용하는 것입니다.

$ git checkout -

원격 브랜치

• 깃은 다수의 개발자와 협업으로 코드를 유지할 수 있습니다.
• 주요 개발 작업들을 로컬 저장소에서 하지만 협업은 저장소도 공유합니다.
• 로컬 저장소도 하나의 저장소고, 원격 저장소도 하나의 저장소입니다.
• 깃은 분산형 버전 관리로서 다수의 저장소를 만들어 연결할 수 있기 때문입니다.
• 이번에는 브랜치를 이용하여 협업하는 방법을 알아 봅니다.

리모트 브랜치

• 원격 저장소에 생성한 브랜치를 리모트 브랜치 라고 합니다.
• 로컬 저장소에 생성한 브랜치는 서버로 공유할 수 있습니다.
• 원격 저장소와 연결된 로컬 저장소에서 새로운 브랜치를 생성한다고 해서 자동으로 원격 저장소에도 브랜치가 생성되는 것은 아닙니다.
• 또 원격 저장소에 등록된 브랜치가 자동으로 로컬 저장소를 만들지도 않습니다. 별도 명령을 실행하여 저장소를 동기화해야 합니다.
• 원격 저장소와 로컬 저장소의 브랜치 이름은 보통 같지만, 반드시 일치하지 않아도 괜찮습니다.
• 서로 다른 이름으로 브랜치를 연결할 수도 있습니다.
• 두 저장소는 서로 다른 브랜치로 운영 관리할 수 있습니다.

브랜치 추적

• 깃의 브랜치는 특정 커밋 해시 값을 가리키는 포인터입니다.
• 리모트 브랜치 또한 원격 저장소의 브랜치를 가리키는 포인터입니다.
• 원격 저장소의 브랜치를 가리키는 것을 브랜치 추적이라고 합니다. 다른 용어로 트래킹 브랜치 라고 합니다.
• 트래킹 브랜치는 원격 브랜치를 가리키는 북마크와 같습니다.
• 추적 브랜치는 원격 브랜치의 마지막 커밋 해시 값을 가리킵니다.

브랜치 업로드

• 지금까지 로컬 저장소에서만 브랜치를 생성했습니다.
• 로컬 저장소의 브랜치 정보는 원격 저장소에 자동으로 등록되지 않습니다.
• 등록된 원격 저장소의 리모트 브랜치는 remote show 명령어로 확인할 수 있습니다.

$ git remote show origin -------- 원격 브랜치

이름이 다른 브랜치

• 일반적으로 로컬 저장소의 브랜치 이름과 원격 저장소의 브랜치 이름은 동일하게 사용합니다.
• 하지만 반드시 이름이 동일할 필요는 없습니다.
• 가끔은 동일한 브랜치 이름을 사용하기 어려울 때가 있습니다.
• 예를 들어 다른 개발자가 만든 원격 서버의 브랜치를 테스트 하려고 할 때 자신의 브랜치 이름과 동일하면 충돌이 생깁니다.
• 깃은 서로 다른 로컬 브랜치와 리모트 브랜치를 수동으로 지정하여 연결할 수 있습니다.
• 브랜치를 직접 수동으로 지정할 때는 콜론(:) 으로 구분합니다.

$ git push origin 브랜치이름 : 새로운브랜치

업스트림 트래킹

• 업스트림(upstream) 은 브랜치 추적을 다르게 표현한 것입니다.
• 리모트 브랜치는 브랜치 이름을 동일하게 생성할 수도 있고, 다른 이름으로 생성할 수도 있습니다.
• 이처럼 로컬 저장소의 브랜치와 원격 저장소의 브랜치는 업로드 할 수 있도록 매칭되어 있습니다.
• 이러한 매칭을 업스트림 트래킹 이라고 합니다.
• 트래킹 브랜치(업스트림 트래킹) 리모트 브랜치와 로컬 브랜치를 연결해 주는 중간 다리 역할을 합니다.
• clone 명령어로 저장소를 복제할 때 원격 저장소에 등록된 트래킹 브랜치들을 자동으로 함께 설정합니다.

업스트림 연결

• 기존에 있는 브랜치를 업스트림으로 직접 설정할 수도 있습니다.
• 브랜치를 생성한 후 직접 트래킹 브랜치를 지정했습니다.
• 업스트림을 직접 설정하면 원격 저장소로 트래킹 브랜치가 설정됩니다.
• -u 옵션은 -set-upstream-to 의 약자입니다.
• 기존 브랜치를 특정 원격 브랜치로 추적합니다.

$ git branch -u origin/브랜치이름

브랜치 푸시

• 깃의 푸시 작업은 로컬 저장소의 파일들을 원격 저장소로 전송합니다.
• 파일 뿐만 아니라 브랜치 정보와 커밋까지 모두 전송합니다.
• 처음에는 커밋과 브랜치를 푸시하는데 업스트림 설정이 필요합니다.
• 원격 저장소 연결만으로 업스트림이 자동으로 설정되지는 않습니다. 이는 깃이 원격 저장소의 어느 브랜치에 어떻게 푸시해야 할 지 모르기 때문입니다.

$ git push -set-upatream origin master ------- 원격 서버 전송

브랜치 페치

• 리모트 브랜치 페치는 일반적인 커밋 페치와 동일합니다.
• 리모트 브랜치를 페치한다고 해서 자동으로 로컬 저장소에 새로운 브랜치가 생성되지는 않습니다.
• 페치 동작은 원격 저장소에서 리모트 브랜치 내용을 내려받기만 할 뿐이지 자동으로 병합하지 않기 때문입니다.
• 리모트 브랜치가 페치되면 깃은 단순히 원격저장소별칭/브랜치 포인터만 생성합니다.
• 원격 저장소에서 페치된 커밋들을 새로운 로컬 브랜치로 반영하려면 병합 명령을 실행해야 합니다.

$ git merge 원격저장소별칭/브랜치이름

브랜치 삭제

• 생성된 브랜치를 삭제하는 것은 생각보다 간단합니다.
• 하지만 브랜치를 삭제하는 것은 해당 브랜치 내용과 커밋을 모두 삭제하는 것입니다.
• 따라서 삭제 명령을 실행할 때는 주의해야 합니다.
• 브랜치 삭제는 크게 스테이지 상태에 따라 달라집니다.
• 가장 주의해야 할 점은 현재 자신이 있는 브랜치는 삭제할 수 없다는 것입니다.
• 그래서 삭제하고자 할 때는 다른 브랜치로 이동해서 삭제해야 합니다.

일반적인 삭제 방법

• 일반적으로 브랜치를 삭제할 때는 -d 옵션을 사용합니다.
• -d 옵션은 스테이지 상태가 깨끗할 때만 삭제를 허용합니다.
• 워킹 디렉토리에 작업한 기록이 있거나 add 명령어로 스테이지의 인덱스가 변경된 상태라면 삭제하지 않습니다.
• 삭제하려면 반드시 최종 상태가 커밋되어 깨끗한 스테이지 상태여야 합니다. 또 병합하지 않는 브랜치는 -d 옵션으로 삭제할 수 없습니다.

$ git branch -d 브랜치 이름

강제로 삭제하는 방법

• 워킹 디렉터리 또는 스테이지에 추가 커밋 작업이 남아 있다면 일반적인 방법으로는 브랜치를 삭제할 수 없습니다.
• 이때는 강제로 삭제해야 합니다.
• 소스트리에서 삭제해보도록 하겠습니다.

리모트 브랜치를 삭제하는 방법

• 원격 브랜치를 삭제하려면 먼저 삭제 명령을 푸시해야 합니다.

$ git push origin -delete 리모트브랜치이름

정리

• 브랜치는 기존 코드를 가상으로 분리합니다.
• 분리해서 격리된 브랜치는 상호 간섭 없이 별개 작업을 수행할 수 있습니다.
• 새로운 프로젝트로 발전시켜 나아갈 때 브랜치 기능은 매우 유용합니다.
• 깃의 브랜치는 다른 개발자와 협업하여 프로젝트를 진행할 때도 매우 유용합니다.
• 서로 간섭 없이 코드를 개선하고, 나아가 병합도 가능하기 때문입ㄴ디ㅏ.
• 처음에는 브랜치를 좀 어렵게 느낄 수 있지만, 깃의 원리와 개념을 잘 이해하고 자주 사용하다 보면 생각보다 어렵지 않다는걸 알 수 있습니다.