원격 저장소에 push 할 로컬 branch 가 아니라면 브랜치 생성이든 삭제든 아무래도 상관없다. 단지 로컬 저장소에서만 이루어 지는 작업이기 때문에.

하지만 브랜치를 협업 등의 이유로 팀원과 공유하려면 원격 저장소에 해당 브랜치를 push 하고 팀원들이 fetch 받아 브랜치를 연결(tracking) 하면 된다.

1. 원격 저장소로 브랜치 공유하기

기존의 커밋들을 push 한다고 해서 내가 만들어 놓은 branch 까지 자동으로 올라가지는 않는다.

원격 저장소에도 별도로 브랜치를 만들고 로컬 저장소 브랜치와 연결을 시켜줘야 한다.

iss53 이라는 로컬 브랜치가 있다면 다음 명령어로 간단히 원격 저장소(origin)에 push 할 수 있다.

위 명령은 $ git push origin iss53:iss53 과 같다. 만약 원격 저장소의 브랜치 이름을 issue 로 바꾸려면 다음 명령을 사용한다.

이 명령으로 원격저장소에 issue 브랜치가 생성되었고 로컬 저장소의 iss53 브랜치와 연결되었다.

2. 원격 저장소에서 브랜치 가져오기

팀원이 원격 저장소에 올려놓은 브랜치를 가져오려면 fetch 나 pull 명령을 사용하면 된다.

하지만 fetch 명령을 실행한다고 해서 원격 저장소의 브랜치와 동일한 브랜치를 로컬에 생성하는 것은 아니다.

fetch 명령은 단지 원격 저장소의 브랜치 중 로컬과 연결되어 있지 않은 브랜치에 대한 포인터만 생성한다.

fetch 후에 로컬 브랜치를 하나 생성하고 원격 저장소의 브랜치와 연결만 해주면 된다.

방법은 다양하다.

위 명령들은 모두 로컬에 생성된 iss55 브랜치가 origin/iss55 브랜치를 바라보는 동일한 동작을 한다.

만약 이미 생성해 놓은 브랜치와 origin/iss55 브랜치를 연결하고 싶다면 -u (--set-upstream-to) 옵션을 사용하여 연결한다.

3. 브랜치 삭제

iss55 브랜치 작업을 끝내고 다른 브랜치와 merge 하고, 더 이상 iss55 브랜치를 사용하지 않는다면 삭제를 해도 된다.

- 로컬 브랜치 삭제

- 원격 브랜치 삭제

브랜치 작업을 하거나 충돌날 때마다 도움을 요청하는 중생들을 줄이고자, git 세미나를 준비하면서 정리한 내용들이다.

(기본적인 push, pull 정도는 할 줄 안다는 가정하에 불필요한 내용은 생략한다.)

1. 우리는 이럴 때 branch 를 사용한다.

다음 케이스를 보자.

master 브랜치 하나만 가지고 있으면서 이 작업물로 운영서버에 배포를 한다.

이 프로젝트에 [기능] 추가 요청이 들어왔고 팀원들과 협업이 필요하다.

협업이 필요하기 때문에 원격 저장소에 소스를 공유해야 한다.

기능 추가 작업중에 심각한 [버그] 를 발견하여 수정하고 다시 배포를 해야 한다면, 아직 완료되지 않은 [기능] 추가 작업이 같이 배포되어 버린다.

이를 방지하기 위해 필요한 것이 바로 branch 이다.

2. branch 란?

현재 브랜치(예를 들어 master) 에서 해오던 작업은 branch 를 추가하는 순간 별도의 공간에서 추가적으로 개발할 수 있다.

branch 는 이름 그대로 나뭇가지 처럼 작업을 분리시키는 것이다.

master 와 iss53 이라는 브랜치가 있다면 master 에서 작업하는 내용은 iss53 에 영향을 미치지 않으며, iss53 에서 작업하는 내용 역시 master 에 영향을 미치지 않는다.

위 케이스에서 [기능] 추가 작업시 iss53 이라는 브랜치를 새로 생성해서 작업한다면,

또 [버그] 수정 역시 hotfix 라는 브랜치를 새로 생성해서 작업한다면, master 에서 bugfix 를 merge 하고 배포하면 끝이다.

다시 iss53 브랜치를 checkout 하여 [기능] 추가 작업을 계속 하면 된다.

3. merge 란?

branch 가 작업을 분리시키는 명령이라면, 반대로 분리한 작업을 다시 합쳐주는 명령이 바로 merge 이다.

우리는 이미 pull 을 수도 없이 사용하면서 자동 merge 를 사용해 왔다. (pull 명령은 fetch + merge 를 한번에 실행해 주는 명령이다.)

master 브랜치에서 git merge hotfix 명령으로 수정된 버그를 해결하고, git merge testing 명령으로 기능까지 추가한다면,

master 브랜치는 최신 상태의 소스가 되고 배포할 준비가 된다.

branch 와 merge 는 이게 끝이다.

이제 실제로 위 케이스를 실행해 보자.

최종적으로 위와 유사한 결과를 도출할 수 있어야 한다.

[기능] 추가 요청에 대한 iss53 이라는 브랜치 생성.

위 명령은 아래 두개의 명령을 한번해 실행해 줌.

작업 및 커밋진행

도중에 [버그] 수정 요청에 대한 hotfix 라는 브랜치 생성.

master 에 기반한 브랜치를 생성해야 하므로 master 브랜치를 이동하여 브랜치를 생성.

버그를 수정한 후 커밋을 진행.

수정한 버그를 master 에 합치기 위해 master 브랜치로 이동하여 merge 실행

master 브랜치는 hotfix 브랜치를 생성한 이후에 커밋을 진행하고 있지 않았으므로 단순히 브랜치 포인터만 hotfix 의 최신 커밋으로 이동함. (fast-forward 방식)

다시 iss53 으로 이동하여 [기능] 추가 작업 마무리 하고 커밋하고 master 와 합치기 위해 merge 실행.

master 브랜치는 iss53 브랜치를 생성한(조상) 이후에 커밋이 진행되었으므로 그림처럼 두개의 브랜치가 합쳐지는 3-way merge 처리.

3-way merge 의 결과로 별도의 커밋이 만들어진다.

추가적으로 브랜치를 변경할 때는 기존의 staged 를 깨끗하게 정리하는 것이 좋다. 

commit 이나 staged 를 사용하여 충돌을 체크 및 예방한다.

IntelliJ 에서 다른 작업자가 추가한 Remote Branch 를 처음 가져오려고 봤더니, 원격의 최신 branch 상태가 나타나지 않았다.

pull 메뉴에서는 최신 branch 가 나타났지만, 현재 로컬 branch 와 merge 하게 되서 최신 branch 가져오는 새로고침만 강타했는데,

branch 메뉴에서는 최신 Remote Branch 가 나타나지 않았다.

결국 현란한 구글링 후,

메뉴에서 [ VCS | Git | Fetch ] 로 Remote Branch 를 가져왔다. (git fetch)

fetch 는 저장소의 작업물을 로컬로 가져올뿐 merge 를 하지는 않는다.

fetch + merge = pull

github 에 등록된 계정간 전환 불가.

해당 프로젝트의 git config 에 user.name / user.email 를 변경했는데도 자꾸 기존 username 으로 push 를 시도하는 이 퐝당한 순간.

검색하다가 ssh-key 를 생성하는 뻘짓까지 했지만 내가 원한 해답이 아니었던 이문제...

키체인 삭제로 해결!

해결법이 더 퐝당함...

Git 설치 후 약간의 환경 설정이 필요하다.

git config 도구로 설정 내용을 저장하는데 Git 프로젝트 별, 사용자 별, 전체 설정 이렇게 3가지 설정이 있다.

1. .git/config
   Git 프로젝트 디렉토리에만 적용되는 설정이며, 3가지 설정 중 제일 우선시 된다. (--system 옵션)
2. ~/.gitconfig
   특정 사용자에게 적용되는 설정이다. (--global)
3. /etc/gitconfig
   모든 사용자와 모든 Git 프로젝트에 적용되는 설정이다.

사용자 정보 설정

Git 은 commit 할 때마다 환경 설정에 저장되어 있는 사용자 정보(이름, 이메일)가 사용되므로, 반드시 필요한 설정이다.

환경 설정 확인