[Git-Flow] 잘 몰랐던 git과 git flow

트러블 슛돌이·2023년 8월 11일

서론

작업이 끝난 브랜치를 developer 브랜치에 merge하려고 할 때 pull하는 과정에서 이 메시지를 마주했다

warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:

  git config pull.rebase false  # merge (the default strategy)
  git config pull.rebase true   # rebase
  git config pull.ff only       # fast-forward only

You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
invocation.

평소 git과 git flow가 제공하는 명령어가 어떤 일을 하는지 잘 알지 못한 상태로 그저 기계처럼 사용해왔다

그래서 오류가 나면 원인을 파악하지 않고 에러를 fix하는것에 급급했다

하지만 오늘은 우리가 아는 기본적인 명령어들이 어떤 일을 수행하고 명령을 수행하는 과정에서 오류가 발생하는 이유에 대해 알아보기로했다

오늘 다룰 것

이번 프로젝트에서 git flow 전략을 처음 사용해보았다

때문에 git flow 전략의 process에 대해 간단히 알아본 후에 위 warning message의 원인과 해결법에 대해 알아보고자 한다

git flow

git flow는 5가지 브랜치들을 이용하는 브랜치 전략이다

main 브랜치들

master 브랜치

제품으로 출시될 브랜치이다
이 브랜치의 최신버전은 언제나 실행가능해야한다

devlope 브랜치

실행 가능한 상태로 만들어가는 브랜치이다
다음 출시 버전을 개발하는 브랜치이다

temporary 브랜치들

feature 브랜치

기능을 개발하는 브랜치
feature/기능이름 으로 네이밍하여 사용하고 개발 끝나면 삭제한다

release 브랜치

이번 출시 버전을 준비하는 브랜치이다
release/버전명 으로 네이밍하여 사용하고 개발 끝나면 삭제한다

hotfixes 브랜치

출시한 버전에 수정사항이 생겨 긴급해 업데이트해야할 때 사용한다
hotfixes/차기버전명으로 네이밍하여 생성하고 개발 후 삭제한다

git flow 사용하며 느낀 점

지금 까지 개발하며 느낀바에 대해 짧게 얘기해보겠다

아직 제품 출시 까지 가지 않았기 때문에 기능 구현 후 developer 브랜치에 merge하는 것이 주를 이루었다

각 인원이 맡은 기능을 개발하기 위해서 기능 별로 feature 브랜치를 만들고 개발을 한다
개발이 끝난 기능은 developer 브랜치에 merge하고 다른 기능을 개발할 때도 developer의 최신상태가 반영되어야하기 때문에 pull을 한 후 개발을 해야했다

인원이 많고 브랜치도 많은 상대적으로 규모가 큰 프로젝트라 기능을 만들고 developer브랜치에 merge할 때 충돌이 굉장히 잦았다

충돌이 생길만한 변경사항을 체크하는 것과 소통이 굉장히 중요하다고 생각했고 이에 대한 메뉴얼이 있으면 편할 것 같았다

warning message의 원인과 해결

각설하고 위 warning message의 원인에 대해서 알아보자

로그의 내용은 git pull 명령을 실행할 때 나타나는 메시지이다
이 메시지는 git이 다른 브랜치들 간에 어떤 전략으로 변경 사항을 가져와야하는지에 대한 설정이 없을 때 나타난다

기본적으로 git pull명령어는 원격 저장소로부터 최신 변경 사항을 가져오는 명령어이다
이때 변경 사항을 가져오는 방식에는 크게 3가지가 있다
바로 merge, rebase, fast forward이다

위의 각 옵션에 대한 명령어는 다음과 같다

git config pull.rebase false는 기본 전략인 merge 방식이다
git config pull.rebase true는 rebase 방식이다
git config pull.ff only는 패스트 포워드 방식이다

패스트 포워드 방식이 생소하였기 때문에 이에 대해 집고넘어가기로 한다

패스트 포워드는 git에서 브랜치를 merge하는 하나의 방식이다
이는 두개의 브랜치가 현재 공통의 커밋 조상을 가지고 있고 하나의 브랜치가 다른 브랜치보다 앞선 커밋을 가지고 있을 때 사용된다
즉, 한 브랜치가 다른 브랜치의 변경 사항을 모두 내용에 반영하고 나서 앞으로 나아가도록 merge시키는것을 말한다

예를 들어 현재 master의 버전인 B에서 파생된 feature 브랜치와 master 브랜치를 패스트 포워드 방식으로 합병하게 되면 master의 head 위치가 커밋 y로 이동하게 된다

패스트 포워드 방식에 대해서 간단히 알아보았다
결국 저 오류를 해결하기 위해서는 merge방식만 지정해주면 된다

기억하자(번외)

본인이 간과하던 git 기본 명령어를 정리해보았다

git status

현재 상태를 확인하는 명령어

변경 사항을 커밋에 반영하기 전에 어떤 파일들이 변경되었는지 확인할 수 있다
현재 작업중인 브랜치가 어떤 브랜치인지 확인할 수 있다
타 브랜치 또는 원격 저장소로부터 코드를 가져오거나 병합할 때 충돌이 발생하는 경우가 종종 있다. 이 때 git status 명령어를 사용하면 충돌 상태를 확인할 수 있다