Git와 GitHub , Git Flow
모든 일이란 게 그렇다 한 번에 처리 되는 경우는 드물고 여러 번 수정 작업을 거치고 되돌리기도 한다 프로젝트를 진행할 때도 마찬가지다 결국 수정을 하고 개선을 해야하는 경우가 많다 혹은 다 엎고 다시 작업해야할 수도 있다 그런데 이렇게 수정을 할 때마다 파일이나 폴더를 새로 만들어야할까?
그래서 만들어졌을 것이다 자세한 역사는 모르지만 많은 사람들이 이것을 사용하고 아주 잘 사용하고 있다 개인부터 개인이 아닌 팀이라는 단체에서도 보다 큰 회사에서도 사용을 한다 그럼 결국 이제 개발자가 되길 희망하는 나도 알아야하고 사용해야하며 익숙해져야만 한다
솔직히 이제 첫 프로젝트에서 처음 협업이란 것을 해보고 이제 써본 나는 사용 이유는 알겠는데 사용법은 잘 모르겠다 아직 잘 모르니 뭐만 하면 에러만 나오고 생각처럼 되지 않지만 '단어의 의미나 이론적으로라도 알고 있어야 쓰면서 익숙해지지 않겠냐' 라는 생각이다
Git : 형상 관리 도구, 버전 관리 시스템이다
GitHub : 형상 관리 도구 웹호스팅 서비스, 버전 관리를 온라인으로 도와주는 것이다
즉 위 사진에서 오프라인 부분이 Git , 온라인 부분은 GitHub이다
각 단어를 자세히 알아보자
Working Directory : 작업중인 디렉토리, 말그대로 작업을 진행 중인 공간이다
add : 작업한 내용을 Staging Area에 추가하는 것이다
Staging Area : commit을 위해 대기하는 공간, 간단한 설명을 추가할 수도 있고 이 공간에 파일이 여러개가 들어갈 수도 있다 병합문제를 해결하는 공간이 되기도 한다
commit : Git에서 버전을 기록하는 단위, Staging Area에 파일들을 묶어서 버전을 만들고 그에 대한 설명을 추가할 수 있다,
Local Repository : 지역 저장소, 내 개인 pc에 commit을 쌓아두는 곳
push : 원격 저장소에 내 로컬에 커밋을 올리는 작업
fetch : 원격 저장소에서 로컬로 받아와서 적용하기 전에 확인하는 것
Clone: 원격 저장소에 있는 것을 로컬에 복사해 내려 받는 것
Remote Repository : 원격 저장소, 온라인으로 내가 올린 커밋들을 관리할 수 있게 해주는 곳이다
pull : 원격 저장소에 있는 것을 가져와서 합쳐준다 -> fetch + merge 와 비슷하다
merge : 병합, 로컬에 커밋을 작업 중인 내용과 합쳐서 새로운 커밋을 만든다 -> 방명록에서 DB에 저장 기능만 구현하고 커밋을 하면 로컬에 저장이 되고 다시 워킹 디렉토리에서 웹페이지에 뿌리는 기능을 완성하면 기존 로컬에 저장하는 기능을 가져와 병합하고 다시 로컬에 커밋한다
checkout : 어떤 작업을 선택할 건지 자유롭게 왔다갔다 할 수 있다
이건 그림만 가지고 설명했을 때이고 branch란 아주 중요한 단어가 등장한다
branch : 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다. 정보를 찾아보면 merge와 checkout이 여기에 많이 사용된다 브랜치를 병합하거나 혹은 체크아웃으로 다른 브랜치로 선택하는 것이다
저게 왜 필요할까 작업은 혼자하는 게 아니라 다수가 모여서 하는 경우가 많고 그럼 '각각의 역할을 어떻게 나누어서 어떻게 합칠까?' 이에 대한 답이 위의 브랜치의 역할이라고 이해했다 그렇다고 여기저기 브랜치가 생기면 그것도 문제가 발생한다 그래서 Git Flow 라는 전략이 등장한다
Git Flow : Git Flow는 특정 기능이 아니고 서로 간의 약속이 만들어낸 방법이다
기본적인 틀은 아래와 같지만 이게 정답은 아니고 각각의 환경이 다르기 때문에 그에 맞춰서 유동적으로 사용해야한다 당연하지만 일단 기본부터 확실히 알아야 응용을 할 수 있겠다
일반적으로 5가지의 브랜치를 사용해서 운영을 합니다.
- master : 기준이 되는 브랜치로 제품을 배포하는 브랜치 입니다.
- develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)칩니다.
- feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합칩니다.
- release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치 입니다.
- hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치 입니다.
master와 develop가 중요한 메인 브랜치이고 나머지는 필요에 의해서 운영하는 브랜치라고 보시면 됩니다.
- 일단 master 브랜치에서 시작을 합니다.
- 동일한 브랜치를 develop에도 생성을 합니다. 개발자들은 이 develop 브랜치에서 개발을 진행합니다.
- 개발을 진행하다가 회원가입, 장바구니 등의 기능 구현이 필요할 경우 A개발자는 develop 브랜치에서 feature 브랜치를 하나 생성해서 회원가입 기능을 구현하고 B개발자도 develop 브랜치에서 feature 브랜치를 하나 생성해서 장바구니 기능을 구현합니다.
- 완료된 feature 브랜치는 검토를 거쳐 다시 develop 브랜치에 합칩니다.(Merge)
- 이제 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 만듭니다. 그리고 QA(품질검사)를 하면서 보완점을 보완하고 버그를 픽스합니다.
- 모든 것이 완료되면 이제 release 브랜치를 master 브랜치와 develop 브랜치로 보냅니다. master 브랜치에서 버전추가를 위해 태그를 하나 생성하고 배포를 합니다.
- 배포를 했는데 미처 발견하지 못한 버그가 있을 경우 hotfixes 브랜치를 만들어 긴급 수정 후 태그를 생성하고 바로 수정 배포를 합니다.
Fork와 Pull requests를 활용한 보다 큰 규모도 있지만 일단은 키워드로만 남기고 위에 먼저 이해해야겠다
참고자료 : 누군가 정리한 다양한 블로그 및 생활코딩
https://backlog.com/git-tutorial/kr/stepup/stepup1_4.html
https://www.opentutorials.org/module
https://coding-groot.tistory.com/135