Git

개요

과제할 때를 생각해보면 처음 작성했던 파일을 수정하고 덮어쓰고 그러다보면 이전에 작성한 글이 마음에 드는데 이미 덮어씌워버려서 확인할 수 없는 경우가 생긴다.
그래서 이런 일이 발생하는데…

코드를 짤 때도 마찬가지다. 소프트웨어는 여러 개발자가 협업하여 개발하는데 덮어쓰는 방식으론 서로의 작업내용을 합칠 때 어려움이 생긴다. > 체계적인 버전관리 도구의 필요성.

대표적인 방법이 바로 Git이라는 프로그램을 이용하여 버전을 관리하고 공용 코드 저장소인 Github에 업로드하는 것이다.

깃

사용하는 방법은 크게 두 가지 방법이 있다.

• CLI
• GUI

개인적으론 GUI를 사용하는게 편해서 소스트리를 사용하다가 깃 크라켄을 사용하고 있다.
깃 크라켄은 유료버전과 무료버전이 있는데 한 몇년 사용하면서 느낀 차이는 무료 버전은 private 깃허브 레포지토리에 코드를 업로드할 수 없다는 것이다. 무료버전을 사용해도 큰 무리가 없었다.

깃에는 세가지 공간이 있다 Working Directory, Stage, Repository로 각각 프로젝트가 위치한 공간, 다음 버전이 될 후보가 올라가는 공간, 버전이 만들어지고 관리되는 공간이다.

다음 버전이 될 후보들을 모두 스테이지에 옮긴 후 이 파일을 새로운 버전으로 만든다.

이러한 과정을 반복하면서 저장소에는 새로운 버전들이 차곡차곡 쌓이게 된다.

Working Directory에서 Stage로 옮기는 것을 ‘스테이지시킨다’ 라고 한다. 그리고 스테이지에 추가된 파일을 추가된 파일 또는 스테이지된 파일이라고 부른다.

다음 버전이 될 후보들을 모두 스테이지에 옮긴 후 이 파일을 새로운 버전으로 만든다.
이러한 과정을 반복하면서 저장소에는 새로운 버전들이 차곡차곡 쌓이게 된다.

저장소에 새로운 버전을 만드는 것을 커밋한다 라고 부른다.

이렇게 들으면 복잡해보이지만 단순하다. 깃에 의해 관리되고있는 프로젝트에서 코드를 수정한다 -> 변경사항 감지됨.
만약 코드 수정을 확정하고 싶다면 stage, commit을 걸쳐 버전으로 만든다.

이 외에도 브랜치라는 개념이 있다. 프로젝트에는 여러가지 기능이 있을 수 있고 이들의 개발을 분기하여 브랜치라는 이름으로 나누어 작업하는 전략을 사용한다.

이렇게 브랜치를 나누어 작업한 뒤 완성되면 메인 브랜치에 병합하는 식이다.
브랜치를 활용하여 협업하는 방법에는 또 여러가지가 있다.

깃 전략

깃 플로우

가장 유명한 전략은 깃 플로우 전략으로 사용하는 브랜치로는 main, dev, feature, release, hotfix가 있다.

메인 브랜치는 실제 운영 환경에 나가있는 코드만 가지고 있는 브랜치로 조심스럽게 다루어야하며 안정적인 코드만 들어가있어야한다.

데브 브랜치는 메인 브랜치를 베이스로 생성한 브랜치로 다음 배포에 나갈 피쳐를 병합하고 모든 작업 내용을 가지고있는 브랜치다.

피쳐 브랜치는 기능을 개발할 때 브랜치를 따로 만들어서 개발하는 브랜치다.

릴리즈는 실제 배포를 하고 테스트를 마무리지었을 때 메인에 머지하는 브랜치다.

핫픽스는 의도치않은 장애가 발생했을 때 빨리 수정해야하는 경우 메인에서 바로 핫픽스 브랜치를 생성하고 메인에 머지한다.

예를 들어 로그인/로그아웃 기능을 구현한 뒤 배포해야하는 상황이라고 해보자.

메인에서 데브 브랜치를 생성한 뒤 데브에서 피처브랜치를 만들고 작업을 한다. 완료되면 차례로 데브 -> 메인으로 병합한다.

다음은 배포를 하기위한 릴리즈 브랜치를 생성하고 작업한다. 만약 릴리즈 브랜치를 만든 뒤 다른 기능을 추가해야할 경우 릴리즈 브랜치를 베이스로 피쳐 브랜치를 생성하고 마무리 지은 뒤 다시 릴리즈 브랜치에 머지한다.

데브는 추가된 기능을 가지고있지 않은 상태로 새로운 기능을 릴리즈 브랜치에 머지한 뒤 메인에 머지한다. 그런 뒤 마스터를 데브에 머지해서 싱크를 맞춰주어야한다.

데브 브랜치는 메인에 없는 코드를 가지고있는 브랜치로 위와같이 하지 않는다면 dev에는 마스터에는 있지만 dev에는 없는 코드를 가지고있고 이런 상황에서 모르고 새로운 브랜치를 생성하게되면 코드가 꼬이게된다.

이런 식의 전략을 깃 플로우라고한다.

깃허브 플로우

깃 플로우는 말하자면 이미 검증을 거쳐 널리 쓰이고 있는 전략이다. 그러나 규모가 작은 프로젝트나 빠르게 배포가 나가야하는 경우 조금 투머치하다. 하나의 기능을 개발하고 배포까지 나가려면 4개의 브랜치를 생성하고 차례대로 병합해야한다.

좀 더 단순화된 전략은 없을까?
그 대안이 될 수 있는 것이 깃허브 플로우 전략이다.

깃허브 플로우는 2개의 브랜치만 사용한다. 기능 구현을 마치면 메인에 병합하고 바로 배포가 나간다.

조금 안전성이 떨어질지 모르겠지만 코드리뷰나 자동화 테스트를 활용하면 경우에 따라서는 사용할 이점이 충분하다.

깃 크라켄을 사용한다면 깃 플로우 전략을 사용할 수 있게 프로그램 자체에서 지원해준다.
이 기능을 이용하여 깃 허브 플로우를 사용할수도 있다.

사용하지 않을 브랜치를 하나 만든다. 그런 다음 프로그램의 깃플로우에 들어가서 dev에 main을 입력하고 main에는 좀전에 만든 브랜치를 입력한다. 이런식으로 하면 깃 크라켄에서도 깃허브 플로우를 쉽게 사용할 수 있다.