이것은 기술 블로그가 아니다
Git의 개념과 Git-flow의 흐름

들어가기 전에

형상관리의 계보

형상관리는?

개발을 하다보면 소스코드가 자꾸 변경되기 마련이다. 사람이 모든 상황에서 완전할 수는 없는 것이라, 변경된 소스코드가 잘 안 돌아갈 수도 있고, 왜 변경했더라? 기억이 안 날 수도 있고, 동료가 트럴이라(혹은 내가 트럴이라) 전체 소스 코드의 품질이 낮아질 수도 있다.

그렇다면 소스코드의 상태를 저장할 수 있으면 되지 않냐능?

그래서 사람들은 소스코드의 변화를 추적하고 관리하는 형상관리 의 필요성을 느끼게 되었다. 일반적으로, 형상관리(형상관리를 하는 그 자체)의 이점은 아래와 같다.

형상관리의 특징 및 장점

비욘드-형상관리 시스템

예시

* Project Folder
    * v0.1(yyyymmdd)
        * 변경내역.txt
        * 파일1
        * 파일2
    * v0.2(yyyymmdd)
        * 변경내역.txt
        * 파일1
        * 파일2
        * 파일3
        * 파일4
    * (중략)
    * v0.9
        * 변경내역.txt
        * src
        * resources
        * ...
    * v0.99
        * 변경내역.txt
        * ...
    * v0.9999(final)
    * v0.9999(final-release)
    * v0.9999999(FINAL)

(사족 : 해본 적 있음)

문제점

해결법과 협업 문제

수정 이력을 내 컴퓨터의 디비에 넣으면 되겠네!

인력으로 파일을 복붙하던 것에 고통받던 고대의 선각자들은 변경 이력을 자동으로 관리할 필요를 느끼게 되었고, 이러한 내역을 디비 등으로 관리하려는 시도를 하였다. 이러한 시도는 나 혼자 소스를 수정할 때는 확실히 유용하였다.

이거 재밌겠네! 나도 끼워줘라!

문제가 있다면, 웬만하면 프로젝트를 혼자 하는 일이 드물다는 것. 로컬 디비에 내역을 저장하는 경우, 협업이 이루어지면 대략 망하는(…) 특징이 있었다. 여러 사람이 같은 파일을 수정할 경우에 대해서는 어떻게 해야 할까?

형상 관리 시스템의 등장 - 중앙 집중식 버전 관리 시스템

소스를 한 곳에 전부 모아서, 여기서 이력도 관리하고 충돌도 협의하고 하면 되지 않을까?

대충 이런 발상으로 나온 것이 중앙 집중식 버전 관리 시스템이고, SVN을 대표로 세울 수 있다.

장점

단점

분산 관리 시스템으로의 진보

서버의 복제본을 너, 나, 우리가 가진다.

Git

Git의 태동

Git은 리눅스로 일약 아이돌이 된 천재 개발자 리누스 토발즈가 개발하였다. 토발즈는 당시 프로젝트에 비트키퍼라는 상용 형상관리 툴을 사용하고 있었는데(개발자들 작명법은 세월의 흐름에 영향을 받지 않는 것 같다.), 비트키퍼의 개발이 중단된다는 소식을 듣고 급하게 하나 만든 것이 Git이다. 과연 천재는 다르다.

Git은 빠른 속도, 단순한 구조, 비선형 개발, 완전한 분산, 대형 프로젝트에서도 유용할 것을 목표로 하였는데, 토발즈가 어떤 프로젝트를 했는가를 다시 한 번 떠올려보면, 음, 과연.

Git의 특징

Git은 다른 형상관리 시스템과 비교하여, 몇 가지 두드러지는 특징을 가진다.

스냅샷

로컬 환경

무결성

Git이 관리하는 상태

커미티드

모디파이드

스테이지드

상태로 보는 작업 플로우

파일 수정과 상태 변경

원격 저장소 : Remote

Git은 로컬 저장소 환경에서만 사용할 수 있지만, 원격 저장소(레포지터리)를 추가하여 힘세고 강한 협업을 가능하게 할 수 있다.

대표적인 원격 저장소 서비스로는

이 있고, 위의 두 서비스가 마음에 들지 않는다면 자신의 서버에 Git 및 관련 서비스를 추가하는 것으로 수제 레포지터리를 만들어낼 수도 있다. 혹은 GitLab 을 설치하여 사용하는 방법도 있다. 개인적으로는 UI가 취향이라 좋아함.

기본 원격 저장소의 이름은 origin 으로 설정되는데, 원한다면 다른 것으로 해도 무방하다. 어차피 push는 명령을 보고 수행한다.

원격 레포지터리와 로컬 레포지터리의 차이

Git 명령어

add

commit

fetch

pull

push

Git의 브랜치

Git이 개별 브랜치의 데이터를 저장하는 방법

기타 용어

Tag

checkout

merge

브랜치 삭제

Fast-Forward

충돌

Git-Flow

Git-Flow는 Git의 브랜치 흐름을 효율적으로 관리하는 관리 모델이다. 깃 플로우는 개발 상황에 따라 서로 다른 브랜치를 생성하도록 유도하여, 병렬적이고 능률적인 개발을 달성하게 한다.

메인 브랜치

메인 브랜치는 어떤 경우에도 항상 존재하는 브랜치들이다. master 와 develop 브랜치 두 개로 구성된다.

master

master 브랜치는 배포본을 의미한다. 배포시에는 master 브랜치의 커밋을 사용하며, master 브랜치의 가장 최근 커밋에는 최신 배포 버전이 자리잡고 있어야 한다.

develop

develop 브랜치에선 다음 배포를 위한 소스 작업을 진행한다. 개발이 완료되면 develop 브랜치의 소스는 일련의 과정을 통해 master로 머지된다. 배포는 개발 환경에 대해서만 진행한다.

서포팅 브랜치

서포팅 브랜치는 개발 상황에 따라 있을 수도, 없을 수도 있는 브랜치들이다. 프로젝트 진행 중, 개발자의 필요에 의해 생성한다. 이러한 서포팅 브랜치들은 복수의 팀 멤버들이 병렬적으로 작업할 수 있도록 도와준다. feature 브랜치와 release 브랜치, 그리고 그다지 반갑지만은 않은 hotfix 브랜치로 이루어진다.

feature

특정 기능을 개발하기 위해 사용하는 feature 브랜치는 develop 브랜치에서 생성된다. feature 브랜치의 작명법은 팀마다 다르지만, 이슈 관리 툴에 등록된 이슈넘버와 연관되게 작명하는 경우와, 개발하는 기능(이슈)를 반영하여 작명하는 경우로 나눌 수 있다.

각 개발자는 자신의 개발 변경을 feature 브랜치로 한정하여 협업하는 동료에게 영향이 가지 않게 하며, 이는 develop 브랜치에 대해서도 마찬가지이다. 이러한 방법을 통해 Git-Flow 모델은 병렬적인 개발을 달성한다.

feature 브랜치에서 개발이 완료된 변경사항은 PR 등의 과정을 거쳐 그리운 어머니 develop 브랜치로 머지한다. 이 때, 개발한 기능의 병합을 커밋으로 구분할 수 있게 하기 위해, 패스트 포워드를 사용하지 않는 경우가 일반적이다.

release

release 브랜치는 배포 준비를 위해 develop 브랜치에서 분리되어 나온다. develop 브랜치의 개발 진척이 성과를 보여, 배포에 충분한 수준으로 성숙되었다고 판단하면, 배포 준비 과정에 들어가며 develop 브랜치에서 release 브랜치를 생성한다.

release 브랜치를 사용하여 QA를 진행하며, 배포에 필요한 메타 데이터를 설정하거나, 작은 버그 등(QA 지적사항)을 수정한다. 이러한 변경사항은 master 브랜치와 develop 브랜치 양쪽에 머지해야 이후의 배포와 개발에서 문제가 발생하지 않는다.

hotfix

hotfix 브랜치는 master 브랜치의 운영 환경 배포 이후, 다음 배포까지 여유롭게 수정할 수 없는 위급한 이슈를 수정하기 위해 생성한다. hotfix 브랜치에서는 이런 다급한 버그 등을 수정하며, 수정 사항은 master 브랜치와 develop 브랜치에 동시에 머지해야 한다.

여담

© 2017 - 2018 AwayDay. All rights reserved.