"git" 태그로 연결된 3개 게시물개의 게시물이 있습니다.

git-flow#

git-flow 는 Vincent Driessen의 브랜칭 모델을 적용하여 레포지토리를 작업할 수있도록 하는 git의 확장이다. 더 알아보기

git-flow vs git-flow-avh#

git-flow 설치 방법을 찾아보면, git-flow-avh를 설치하라는 가이드가 나오는데, git-flow 저장소가 있고, 이게원본인 것 같아서 약간의 혼란이 있었다.

다행히 git-flow-avh의 깃헙 위키의 Home과 FAQ에 간략한 설명이있다.

git-flow에서 hooks와 filter 구현이 필요했기 때문에 원본 git-flow에 대한 패치를작성했습니다. 5개월이 지나도, 패치가 구현되지 않았고 우리는 AVH Edition을 만드는 일에 집중하기로 결정했습니다.

AVH는 A Virtual Home이라는 작성자의 개인 웹사이트 이름에서 따왔다고 한다. 참고

AVH Edition이 git-flow의 기본 기능들을 포함하면서 hooks와 filter 기능을 제공하고 , cheatsheet 를 포함해서 AVH Edition으로 가이드하는 문서가 많아서 AVH Edition으로 설치를 진행했다.

설치하기#

Installation 에서 운영체제 별 설치 가이드를 볼 수 있다.

MacOS 기준으로는 brew를 사용하여 설치한다.

brew install git-flow-avh

1.7.0 버전에서 git flow init 시에 에러가 발생했는데, (이슈) ~/.gitflow_export 에 FLAGS_GET_OPT_CMD 환경 변수가 있는 것이 원인이었다. 버전이 업데이트 되면서 이를 삭제해야 한다고 한다. 참고

시작하기#

먼저, git 레포지토리를 생성한다.

git init hello-git-flow

git 레포지토리로 이동한 후, git flow를 시작한다.

cd hello-git-flowgit flow init

CLI의 질의에 따라 진행하여 브랜치 컨벤션을 정한다.

명령어#

git-flow 명령어 한짤 요약

느낀점#

평소 하나의 Origin 레포지토리를 두고, main, develop, feature/, fix/ ... 으로 브랜칭한 후, Pull Request -> Merge -> Pull (develop) 방식의 workflow를 사용했는데 git flow의 finish 명령어가 로컬에서 머지되는 방식이라, Pull Request와 함께 어떻게 사용하는 것이 가장 적절한지 고민이 들었다.

다행히, Stack Overflow에 비슷한 고민이있었다. 기존 워크플로우 대로 사용하려면, finish 명령어를 사용하지 않고, publish -> PR -> Merge -> Pull 식으로 진행하면 된다. 추가적으로 git-flow-avh의 hooks 기능을활용해 PR 작성 스크립트를 활용할 수 있다.

또는, 하나의 Upstream 레포지토리를 두고 fork하여 협업 대상자의 개인 Origin 레포지토리에서 PR하는 방식으로 진행하는 방식도 있다. 참고

이러한 방식을 사용하면, 각자의 Origin repo에서 부담없이 다양한 실험들을 해볼 수있는 장점도 있을 수 있다고 한다.

Reference#

git-flow cheatsheet

우린 Git-flow를 사용하고 있어요

빈 브랜치 생성하기#

git checkout --orphan empty-branch

git rm -rf .

# 빈 커밋 생성하기git commit --allow-empty -m "Initial commit"

Git Pull 전략#

git pull 을 별도 옵션 없이 실행했을 때 경고 문구가 나타났다.

warning: Pulling without specifying how to reconcile divergent branches isdiscouraged. You can squelch this message by running one of the followingcommands sometime before your next pull:
git config pull.rebase false  # merge (the default strategy)git config pull.rebase true   # rebasegit config pull.ff only       # fast-forward only
You can replace "git config" with "git config --global" to set a defaultpreference for all repositories. You can also pass --rebase, --no-rebase,or --ff-only on the command line to override the configured default perinvocation.

• default (merge) : 로컬 브랜치와 리모트 브랜치의 Head가 다른 위치에 있을 때, pull 받으면, Merge 커밋을 생성함.

• rebase : 로컬 브랜치와 리모트 브랜치의 Head가 다른 위치에 있을 때, pull 받으면, 리모트 브랜치를 rebase 하여 history를 정리함.

• fast-forward only : fast-forward 관계에 있을 때만 pull 을 허용함.

Git - git-pull Documentation

[GIT] Git pull 전략 (default, --ff -only, --rebase)

GitHub 환경에서의 실전 Git 레시피 : NHN Cloud Meetup

Conventional Commit#

Conventional Commits

Git commit 메세지 규약 - Conventional Commits

Merge Options#

Merge#

기본적인 Merge 방법으로 하나의 브랜치의 변경 이력 전체를 합치는 방법이다.

두 변경 이력을 병합한 Merge commit이 새로 생성된다.

Squash and merge#

브랜치 상의 모든 커밋을 하나로 병합한 내용을 다른 브랜치에 추가하는 방법이다.

PR에 있는 commit log들을 한 개의 커밋으로 추려서 main 브랜치에 병합할 수 있기 때문에, 1 PR = 1 commit 처럼 사용할 수 있다.

참고자료#

[Git] Merge 이해하기 (Merge / Squash and Merge / Rebase and Merge)

6. Github으로 협업하는 법

GitHub의 Merge, Squash and Merge, Rebase and Merge 정확히 이해하기 : TOAST Meetup

Rebase and Merge#

브랜치 상의 모든 commit들을 합치지 않고 main 브랜치에 추가하는 방법이다.

GitHub과 GitLab의 Squash and merge 차이#

GitHub#

Github에서는 PR에 대한 머지 방법을 다음 사진과 같이 제공한다.

Squash and merge 기능을 사용할 경우, Merge commit이 따로 생성되지 않고, PR 타이틀을 커밋 제목으로 하고, 브랜치의 commit log들이 커밋 내용으로 생성된다.

GitLab#

반면, GitLab에서는 MR을 머지할 때, Squash commits의 옵션을 체크할 수 있도록 하는데, GitHub과 달리 기본적으로 Merge commit이 생성되도록 설정되어 있다.

Merge commit을 생성하지 않기 위해서는 Fast-forward merge를 사용해야 한다.

Fast-forward merge requests

Fast-Forward Merge를 사용하고 Squash commits 옵션을 체크하지 않으면, Rebase and Merge 처럼 동작한다.

Fast-Forward Merge를 사용하고 Squash commits 옵션을 체크하면 Squash and Merge 처럼 동작한다.

하지만 GitHub에서 자동적으로 커밋 메시지 body에 브랜치의 커밋 로그를 기록해주는반면, GitLab에서는 커밋 로그를 기록해주지 않는다. Merge Request의 내용이 있다면이 내용을 담을 수 있고, Modify commit message 버튼을 사용하여 직접 수정하는 것도가능하다.

참고자료#

Merging a pull request

Merge requests