[TortoiseGit] git 사용법(2) - pull, branch, merge

실무에서, 또는 뭐... 부트캠프라든가 어딘가에서라도 교육을 받으면 팀별로 협업해서 프로젝트를 보통 하나 합니다. 저도 몇 번 했었고요. 그럴 때 git으로 팀원들과 코드를 공유하면 편리합니다.

라떼는(?) 그런 프로젝트 자리에서 git 잘 쓰면 고수 취급받았는데 지금은 어떨지 모르겠네요.

 

다만 git을 처음 사용하면 굉장히 조심스럽게 됩니다. 내가 혹시 잘못해서 다른 팀원이 작성했던 코드를 날려버리는 건 아닐까 하고 두려워지죠. 실제로도 신입이 그런 실수를 저질렀단 사례가 주위에 가끔 있습니다.

그래서 git 사용법을 잘 이해하는 게 중요합니다.

 

저번 포스팅에선 개인 프로젝트에서 쓸 수 있는 commit, push를 다뤘었죠. 이번 포스팅에선 다른 사람과 협업할 때 쓰이는 명령어들을 다뤄보겠습니다.

 

1. pull

현재 내가 clone으로 받아온 로그인 기능만 있는 프로젝트가 있다고 합시다.

다른 사람이 그 프로젝트를 받아서 회원가입 기능을 추가한 후 push를 했습니다.

 

그러면 회원가입 기능이 추가된 프로젝트는 원격 저장소에 저장이 되어 있겠지요.

하지만 로컬에서의 내 프로젝트는 여전히 로그인 기능만 있는 상태입니다.

 

여기서 pull 명령어를 사용하면 원격 저장소의 코드 중 추가/수정된 부분만 가져옵니다.

즉, 추가된 회원가입 기능 부분의 코드만을 가져옵니다.

 

한 번 보겠습니다.

저번 포스팅에서 로그인 기능까지 원격 저장소에 push해 놓은 프로젝트를 하나 더 clone해 왔습니다.

 

그러고는 저번 포스팅에서 clone으로 받아왔던 곳으로 가서...

 

이 프로젝트에 저는 회원가입 기능(join)을 추가했습니다.

 

commit message를 작성 후 commit.

 

그런 다음 원격 저장소에 push까지 해 줍니다.

 

그럼 아까 clone으로 받아왔던 프로젝트 폴더는 어떨까요?

 

당연히 join 기능이 없습니다.

이때 pull로 가져와 봅시다.

 

프로젝트 폴더에서 우클릭 후 tortoiseGit > pull을 클릭하면 pull 창이 표시됩니다. 아까도 master branch에 push했었으므로 당연히 가져올 브랜치는 master로 하여야겠지요. OK를 클릭합니다.

 

참고로, Options에 있는 Prune은 원격 저장소에 더 이상 존재하지 않는 branch를 로컬에서도 지워버리는 옵션인데

 

이렇게 체크하면 작용합니다.

다시 해당 프로젝트에 들어가보면

 

정상적으로 join 기능이 들어와있는 것을 확인할 수 있겠습니다.

 

2. branch

branch는 어떤 프로젝트가 있을 때, 그 프로젝트의 현재 시점의 환경과 똑같은 환경을 하나 더 만드는 개념입니다.

 

프로젝트는 항상 기본적으로 master 라는 branch가 만들어져 있는데, master를 기준으로 여러 사람들이 자신만의 branch를 만들고, 작업이 끝나면 branch를 master에 합칩니다. 이 합치는 과정을 merge라고 부릅니다.

 

보통 branch는 기능 단위로 만듭니다.

로그인 branch, 회원가입 branch 를 예시로 들 수 있겠네요.

 

그럼 왜 굳이 branch를 만들어야 하나? master에 다 push해버리면 되는 거 아니냐?

라고 할 수 있지만... master에 직접 push하는 건 실전에선 암묵적으로 금지돼있습니다. master 브랜치는 보통 배포용입니다. 즉 오류 없는 궁극적인 기능만이 들어가야 하기 때문이죠. 그 전 브랜치들에서 기능들의 충돌 등 모든 문제를 해결 후 master로 넘어가야 합니다.

 

그럼 branch를 만들어보겠습니다.

TortoiseGit > Switch/Checkout 으로 들어갑니다.

 

맨 위엔 해당 branch의 기반이 될 branch 명을 씁니다. 현재는 master입니다.

저는 프로그램 이용자들에게 인사하는 기능을 넣고 싶어서 feature/greeting이라는 branch를 만들었습니다.

 

feature란 기능 단위의 branch를 작성할 때의 통상적인 이름입니다. 통상적인 branch 구조가 궁금하시면

A successful Git branching model

이 사이트의 그림을 참고하시면 됩니다.

저는 보통, master에서 딴 develop이란 branch에 모든 feature branch들을 합치고, 그 이후 최종적으로 master 브랜치에 합치는 과정을 거칩니다.

 

지금 만드는 feature branch를 기반으로도 새로 branch를 딸 수 있습니다.

큰 기능을 만들 땐 그렇게도 한다고 하더군요.

 

현재 branch가 master에서 feature/greeting으로 변경되었습니다.

 

그리고 파일을 하나 새로 만들어서 저런 기능을 추가했습니다.

 

그리고 commit후 push해줍니다. Remote에 저렇게 아무 것도 쓰여 있지 않다면 feature/greeting이라는 원격 branch가 하나 새로 생깁니다.

 

원격 저장소엔 master branch에 가 보면, 이번에 추가한 인사 기능이 없습니다.

 

클릭하면, branch 목록이 뜨는데 이번에 추가한 아까 설명드린 대로 branch가 생긴 걸 볼 수 있습니다.

 

해당 branch로 전환하면 인사 기능이 잘 들어가 있습니다.

이제 master branch에 합쳐 봅시다.

 

Compare & Pull request를 클릭합니다.

 

또 message를 쓰라고 하는데, 특이사항이 없다면 commit message와 비슷하게 쓰면 됩니다. 사실 디폴트로 commit message 내용이 알아서 들어갑니다.

 

여기선 현재 branch를 master에 합쳐도 충돌이 일어나지는 않는지 git에서 알아서 검사해줍니다.

다행히 충돌이 일어나지 않는다고 하는군요.

Merge pull request 버튼을 눌러줍니다.

 

Confirm merge 클릭

 

merge 성공 후엔 저런 메시지가 뜨는데, 보통 merge 후엔 branch가 필요없으므로 웬만하면 Delete branch를 눌러줍니다. 여러 개 생기면 지저분하고 헷갈리기 때문이죠.

 

master branch에도 정상적으로 기능이 올라갔습니다.

그런데 항상 이렇게 정상적으로 합쳐지는 건 아닙니다.

충돌(Conflict)이 일어날 수 있기 때문이죠.

다음 포스팅에선 충돌이 일어났을 때 충돌을 해결하는 방법에 대해 다뤄보겠습니다.