이전 포스팅에서 깃과 깃헙을 이용해 첫 저장소를 생성해보았다.
이번엔 좀더 진보한 사용법을 익혀보자.
앞선포스팅에서는 커맨드라인을 이용해 status를 확인하고 commit, push 했지만 깃을 좀 더 편하게 GUI에서 사용할수있도록 지원하는 툴들이 있다.
개인적으로는 회사에서 처음 사용해본 source tree 라는 툴을 사용하고있는데 이 툴을 중점으로 포스팅하겠다.
일단 소스트리를 설치하자.
설치가 완료됐으면 실행하자. 다음과 같은 화면을 볼수있다. 윈도우는 살짝 다른걸로 알고있는데 진행에는 큰 무리가 없을것이다(나도 회사에선 윈도우로 사용중이다.).
로컬저장소는 존재하지않고 원격저장소만 존재할경우(기 진행중인 프로젝트를 다운받는경우가 이에 해당할 것이다.) URL에서 복제를 선택해 진행하면 된다.
우리는 이전 포스팅에 이어서 진행할것이고 이미 커맨드라인을 통해 로컬저장소와 원격저장소를 모두 보유중이니 다시 원격에서 받을 필요는 없다. 로컬 저장소 추가하기를 선택한 후 지난 포스팅에서 깃 로컬저장소로 설정했던 디렉토리를 열면 된다.
해당 디렉토리를 선택하면 로컬저장소가 추가될것이다. 우클릭-열기 혹은 더블클릭을하자.
이런 창이 뜰것이다. 아마 윈도우는 소스트리를 처음 실행하면 이 창이 뜰텐데 위에서 말한것 그대로 진행하면 된다. 로컬저장소 추가하기를 진행하여 로컬저장소를 열어주자.
왼쪽이 가장 많이 클릭할 메뉴들인데 간단히 설명하겠다.
파일상태 - 전 포스팅에서 말한 파일의 상태를 확인할 수 있다. 변경된 파일, 커밋할 파일을 확인할 수 있으며 커밋을 진행할 수 있다.
히스토리 - 깃의 커밋로그들을 확인할 수 있다.
그리고 그 아래 branches 라는게 있는데 말 그대로 브랜치들이다.
깃은 프로젝트를 브랜치로 관리하게되는데 동일한 프로젝트에서 여러 개발자들이 동시에 작업을 하게되면 충돌이 날 확률이 높아지게 되고 문제가 생겼을때 롤백하기도 쉽지않을것이다.
그래서 각자 개발자들이 새로운 브랜치를 생성해 개발을 진행하고, 개발이 완료된 후 브랜치들을 합치는 방식으로 개발을 하게된다. 이런 브랜치들을 좀 더 의미있게 사용하자는 의미에서 브랜치전략들이 많이 나왔고 git flow라는 전략이 매우 유명하다. 이는 잠시 후 다시 설명하겠다.
저장소가 원격, 로컬로 나뉘어 있는만큼 브랜치도 원격 브랜치와 로컬브랜치가 존재한다. 보통 로컬브랜치와 원격브랜치가 1:1로 대응되게하고 명칭도 같은 명칭으로 하는 경우가 대부분이지만 꼭 그렇게 해야하는것 아니다.
가장 초기에 생성되는 브랜치는 master 브랜치이며 현재 원격과 로컬에 모두 master가 존재하는것을 볼 수 있을것이다.
이전 포스팅에서 파일 수정 후 git commit, push 명령어로 원격저장소에 올렸던것처럼 이번엔 소스트리를 이용해서 해보자.
매우 직관적인 인터페이스를 가지고있고 툴자체도 거의 완벽한글화를 지원하기때문에 특별한 설명은 필요없을것이라고 본다.
지난 포스팅에서 pull 명령어에 대해서는 설명하지않았는데 원격저장소에서 변경된 파일을 로컬저장소로 내려받는 기능이다. 혼자 개발할땐 나말고 변경하는 사람이 없으니 당연히 쓸일이 없을테고, 동료개발자의 작업내용을 받을때 사용한다. 소스트리에서 해당 브랜치에 변경된부분이 있다고 표시해주면 그때 브랜치 우클릭 후 pull을 받으면 된다.
커맨드를 사용하는것보다 훨씬 편하기때문에 소스트리 자체에 대한 설명은 크게 필요한게 없을것이다. 10~20분 혼자 클릭하다보면 대충 손에 익게될것이다.
이제 위에서 뒤로 짬시킨 git flow에 대해서만 간략히 알아보고 마치겠다.
http://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html
해당 주소에서 매우 자세하고 쉽게 설명하고있으니 참고하자.
위에서 말했지만 브랜치는 브랜치일뿐 특별한 의미가 있는 브랜치는 없다. 하지만 그 브랜치에 역할을 입혀 논리적인 의미를 입히고 그 전략대로 브랜치를 사용하는것이 브랜치 전략이며 git flow가 그 중 하나다.
git flow는 브랜치를 크게 몇가지로 나누고 있는데 이런식이다.
develop - 개발의 중심이 되는 브랜치이다. 해당 브랜치에서 직접 작업하는것은 지양해야하며 추가기능을 개발할때 해당 브랜치에서 feature 브랜치를 생성해 진행한 후 작업이 완료되면 해당 브랜치를 develop에 머지한다.
feature - 직접적인 개발이 진행되는 브랜치이다. 해당 브랜치에서 각각 개발자들이 작업을 하게된다.
master - 최신으로 운영에 배포된 상태의 브랜치이다.
release - delveop에서 각자의 브랜치를 생성해 개발을 진행한 후 개발이 완료되면 다시 develop 브랜치에 머지하게된다. 그리고 새로운 배포가 나갈때 develop 브랜치에서 release 브랜치를 생성하게된다. release 브랜치를 이용해 배포전 테스트를 진행하며 이미 큰 틀의 개발은 feature에서 진행된 후이기떄문에 해당 브랜치에서는 배포전 테스트에서 발생하는 버그들을 주로 수정하게된다. 테스트가 완료되면 해당 브랜치에서 변경된 사항들은 develop, master 브랜치에 머지되며 이후 master브랜치의 배포가 진행된다.
hotfix - 운영에 배포된 상태에서도 긴급한 수정사항이 발생할 수 있다. 이때 master 브랜치에서 hotfix 브랜치를 생성하게되며 해당 브랜치에서 수정된 사항은 다시 delvelop, master에 머지하게된다.
소스트리에서는 툴 자체에서 git flow를 지원하고있다. 메뉴에서 git flow 시작하기버튼을 누르면 develop과 feature 브랜치를 생성해주며 그 이후엔 깃플로우 버튼을 누르면 따로 브랜치생성할 필요없이 필요한 브랜치를 GUI를 이용해서 생성해준다.
마지막으로 깃헙에서 지원하는 풀리퀘스트에 대해 알아보도록하겠다.
굳이 깃 플로우일필요는 없지만 위에서 브랜치의 역할에 대해 설명했으니 깃 플로우관점에서 설명을 하자면 delvelop 브랜치에서 내가 추가개발하고자하는 개발을 진행하기위해 feature 브랜치를 생성하게된다.
이후 작업이 완료되면 해당 브랜치를 delvelop에 머지해야하는지 그 이전에 코드리뷰를 진행하는 단계가 풀리퀘스트다.
개발을 진행한 feature 브랜치를 원격으로 푸시해주고 깃헙 사이트에 접속하자.
풀리퀘스트 메뉴에가면 new pull request라는 버튼이 보인다. 클릭하자.
클릭하면 base branch와 compare branch가 있는데 compare를 base에 머지하겠다 라는 뜻이다.
그대로 풀리퀘스트를 생성하게되면 해당 프로젝트를 진행중인 개발자들에게 알람이 가게되고 코드리뷰를 진행할 수 있게된다.
코드리뷰를 진행한 후 해당 페이지에 있는 merge 버튼을 클릭하면 자동으로 브랜치가 머지되며 반대로 내가 로컬에서 수동으로 develop에 머지한후 푸시하게되면 풀리퀘스트가 종료되게된다.
이로 깃 포스팅을 마치겠다.
회사를 이직한 후 가장 당황했던건 여태 SVN만 쓰던 내가 깃을 접하게 됐던것이다.
지금와서 생각해보면 배우기가 힘들었던것도 아니고 그리 어려운것도 아닌데 그때는 가장 힘들었던게 깃이었다.
도움이 될진 모르겠지만 나같은 상황을 맞닥뜨린, 혹은 깃을 써보고싶은데 뭐가뭔지 모르는사람들에게 조금이라도 도움이 될수 있었음 좋겠다.
