보통 일반적으로 알고 있는 머지 전략이다. 이 방법은 머지 브랜치가 삭제되더라도 히스토리 그래프 상에는 다른 가지로 남아있다.'어떤 브랜치에서 어떤 커밋이 진행되어 어떻게 머지 되었군'을 자세하게 알 수 있는 히스토리가 남는다. 머지가 수행되면 머지커밋(merge commit)이 생긴다. 이는 '어느 순간에 어떤 브랜치의 변경 사항이 머지되었다.'를 알려준다. 다만 브랜치의 개수가 많아지거나 머지 횟수가 많아지면 히스토리 그래프의 가독성이 떨어진다.

Squash and merge(Squash)

여기서 squash는 여러 개의 커밋을 하나로 합치는 기능을 말한다. 이 전략은 머지 브랜치의 커밋을 전부 하나의 커밋으로 합친 뒤 타겟 브랜치에 커밋하는 방식으로 머지가 진행된다. 여기서 발생하는 머지 커밋은 실질적인 머지로 생긴 것이 아니라, 머지 브랜치의 변경 사항을 하나로 뭉친 변경 사항에 대한 커밋이다. 그렇기 때문에 머지 브랜치의 가지가 타겟 브랜치로 들아가는 것이 아니라 타켓 브랜치에 새로운 커밋이 추가된 모습으로 히스토리 그래프에 나타난다.

히스토리 상에서 알아보기 쉽고, 버전 별로 어떤 것이 변경되었는지 쉽게 알 수 있다. 그리고 머지 브랜치의 자잘한 커밋이 남지 않기 때문에 '머지 되었다.'라는 것에 집중하기 때문에 변경 사항을 읽기 수월하다. 하지만 일반 적인 머지 커밋보다는 정보력이 떨어진다. 어떤 커밋을 통해 어떤 부분을 수정했는지는 알 수 없다.

Rebase and merge(Fast forward)

rebase는 브랜치의 히스토리들의 베이스를 변경하는 방법이다. 이를 이용하여 브랜치를 머지하는 전략이다. 누가 언제, 어떤 부분을 수정했는지 머지 브랜치의 커밋을 모두 살려놓는다. 하지만 어느 시점에 머지 되었는지 알 수 없다. 이를 해결하기 위해 tag기능을 사용한다.

머지 시 충돌이 날 경우 각각의 커밋에 대해 충돌이 발생한다. 그 이유는 머지 브랜치의 히스토리 자체를 복사해서 타켓 브랜치에 박아버리는 방식이기 떄문이다.

JS Transpiler

Babel은 ES6 이상의 최신 문법을 ES5 이하의 문법으로 작성한 것 처럼 소스코드 내의 문법 형태를 변경해주는 JS transpiler. JS compiler라고 부르기도 한다. Babel을 사용해 문법 형태가 변경된 소스 코드는 최신 문법을 지원하는 실행 환경 뿐만 아니라 아직 최신 문법들이 적용되지 않은 실행 환경에서도 작동한다.

compile은 인간이 작성한 소스 코드를 컴퓨터가 이해할 수 있도록 머신 코드로 바꿔주는 과정을 뜻한다. transfile은 다른 실행 환경에서도 돌아갈 수 있도록 같은 언어를 유지한체 소스 코드의 형태만 바꾸는 과정을 뜻한다. JS는 인터프리터 언어이기 때문에 컴파일 과정이 필요 없지만 JS 커뮤니티에서는 이 두 용어가 혼용되어 사용되고 있다.

기능

• 구문 변환
• Polifill 지원 (@babel/polifill)
• 소스 코드 변환
• +a

예시

// Babel Input: ES2015 arrow function
[1, 2, 3].map((n) => n + 1)

// Babel Output: ES5 equivalent
[1, 2, 3].map(function(n) {
  return n + 1;
})

사용해보자!

@babel/core, @babel/cli

# npm
$ npm install --save-dev @babel/core @babel/cli

# yarn
$ yarn add -D @babel/core @babel/cli

@babel/core,@babel/cli를 devDependencies에 추가한다. 그 이유는 Babel은 빌드 시에 필요하기 때문이다.

@babel/core는 항상 필요로 하는 패키지이며 transform에 필요한 도구이다. @babel/cli는 터미널에서 cammand line을 통해서 transpile 할 수 있는 도구이다.

plugin / preset

Babel은 plugin과 preset을 통해 코드를 어떻게 변환할지 판단하고 동작한다. plugin은 규칙 하나하나 미세하게 적용할 때 사용한다. preset은 plugin의 배열으로 여러 개의 규칙을 한번에 적용한다.

이는 Babel의 설정 파일인 babel.config.js 혹은 .babelrc에 입력해준다.

Babel command를 실행할 때마다 매번 옵션을 붙이기 번거로워 Babel 설정 파일을 이용한다. 설정 파일은 root에 추가하여 사용한다.

ex) babel.config.js

module.exports = fuction(api) {
  api.cache(true)

  const presets = ['next/babel']

  const plugins = [
    [
      '@babel/plugin-proposal-decorators',
      {
        legacy: true,
      },
    ],
    [
      '@babel/plugin-proposal-class-properties',
      {
        loose: true,
      },
    ],
  ]

  return { presets, plugins }
}

위의 예시에서는 nextjs를 사용하고 있기 때문에 nextjs의 preset을 적용하였다. 가장 범용적으로 사용하는 preset은 @babel/preset-env이다.

plugin의 경우에는 Babel 공식 사이트 - plugins 혹은 검색을 이용하여 적절하게 사용하는 것이 좋다.

참고

Babel 공식 사이트 Babel User Handbook (번역) Everything you need to know about BabelJS BabelJS(바벨)

위 명령은 origin이라는 저장소의 refs/heads/candidates/${_NODE_ENV}/*의 브랜치에 push를 한다. 이 명령어를 보고 시작한 Refspec 개념 정리입니다.

형식

+ <src>:<dst>

• + : fast-forward가 아닌 업데이트를 허용한다는 의미, 생략 가능
• <src> : source 패턴, 원본
  • 리모트 저장소의 Refs 패턴(??)
  • 기본적으로 refs/heads/* 로 설정
• <dst> : destination 패턴, 합쳐야 할 대상
  • 리모트 저장소에 매칭되는 로컬 저장소의 Refs 패턴(??)
  • 리모트 저장소는 로컬 저장소의 refs를 매핑해 refs/remotes/리모트 저장소명/*으로 Refs를 저장해 둔다.(로컬 저장소의 refs와 동일한 해시값을 가진다.)

기본적으로 git은 git remote add 명령으로 생성한 설정을 참고하여 리모트 서버에서 refs/heads/에 있는 Refs를 가져다 로컬의 refs/remotes/origin/에 기록

예시

git log

로컬의 히스토리 접근

$ git log master
$ git log heads/master
$ git log refs/heads/master

리모트의 히스토리 접근

$ git log origin/master
$ git log remotes/origin/master
$ git log refs/remotes/origin/master

git fetch

# .git/config
fetch = +refs/heads/*:refs/remotes/origin/*

이는 해당 리모트 저장소에서 git fetch 명령을 실행할 때 자동으로 사용되는 Refspec이다.

$ git fetch origin master:refs/remotes/origin/mymaster

리모트 브랜치 master(원본)를 로컬 브랜치 origin/mymaster(합쳐야 할 대상)로 가져온다.

git push

$ git push origin master

위에서 master는 refs/heads/master:refs/heads/master를 의미한다. <src>는 푸쉬하기를 원하는 브랜치의 refs(원본), <dst>는 리모트에 푸시가 될 때 업데이트 될 브랜치의 refs(합쳐야 할 대상)이다.

$ git push origin master:refs/heads/qa/master

로컬의 master 브랜치를 리모트의 qa/master로 push한다.

끝맺음

정리하면서도 계속 헷갈리는 개념이다. 앞으로 cli로 삽질 하면서 익히는 수 밖에 없을 것 같다.

참고 10.5 Git의 내부 - Refspec

git의 커밋은 key-value 형식으로 이루어져 있는데, key 값은 SHA-1으로 만들어진 해쉬값이다. 이를 사람들이 기억하기 어렵기 때문에 외우기 쉬운 이름의 파일에 저장되어 있는데, 이를 저장해 놓은 파일을 References 혹은 Refs라고 한다.

모든 refs는 .git/refs에 저장된다.

브랜치

git의 브랜치는 어떤 작업 중 마지막 작업을 가르키는 포인터 또는 Refs이다. 브랜치는 직접 가리키는 저밋과 그 커밋으로 따라갈 수 있는 모든 커밋을 포함한다.

git의 git branch <branch>를 실행하면 내부적으로 update-ref명령을 실행하고, 입력받은 브랜치 이름과 현 브랜치의 마지막 커밋의 SHA-1 값을 가져다 update-ref명령을 실행

HEAD

HEAD 파일은 현 브랜치를 가리키는 간접 Refs다. 이 Refs는 다른 Refs를 가리키는 것이라서 SHA-1 값이 없다.

git commit 을 실행하면 커밋 개체가 만들어지는데, 지금 HEAD가 가리키고 있던 커밋의 SHA-1 값이 그 커밋 개체의 부모로 사용된다. HEAD 파일도 손으로 직접 편집할 수 있지만 git symbolic-ref 라는 명령어가 있어서 좀 더 안전하게 사용할 수 있다. 이 명령으로 HEAD의 값을 읽고 변경할 수 있다.(다만 refs 형식에 맞춰야 한다.)

태그

태그는 커밋이랑 매우 비슷하다. 커밋처럼 누가, 언제 태그를 달았는지 태그 메시지는 무엇이고 어떤 커밋을 가리키는지에 대한 정보가 포함된다. 태그는 Tree가 아니라 커밋을 가르킨다.

브랜치처럼 커밋을 가리키지만 옮길 수는 없다. 태그는 늘 그 이름이 뜻하는 커밋만 가리킨다.

리모트

refs/heads 에 있는 Refs인 브랜치와 달리 리모트 Refs는 Checkout 할 수 없고 읽기 용도로만 쓸 수 있는 브랜치인 것이다. 이 리모트 Refs는 서버의 브랜치가 가리키는 커밋이 무엇인지 적어둔 일종의 북마크이다.

리모트를 추가하고 Push 하면 Git은 각 브랜치마다 Push 한 마지막 커밋이 무엇인지 refs/remotes 디렉토리에 저장한다.

참고

10.3 Git의 내부 - Git Refs

원래는 Github flow를 통해 지속적인 CI/CD를 진행하였는데, 이는 앞으로 서비스에 반영될 기능들이 충분히 테스트 되지 못하고 배포되는 문제점을 해결하기 위해 flow를 어떻게 하면 좋을까를 고민하는 사수를 보며 구체화 되지 않은 개념들을 조금이나마 구체화하고, 이해하기 위해 정리해야겠다는 생각이 마구 들어서 개인적으로 정리하기 위한 글입니다.

잘못된 개념과 수정사항은 언제든 환영합니다!

Git Flow

구조

• 구조 : feature > develop > release > hotfix > master
• develop과 master가 base가 된다.

1. master에서 develop을 분기한다.
2. 기능 구현을 위해 develop에서 feature를 분기한다.
3. 기능 구현이 완료되면 feature를 develop에 merge한다.
4. 배포를 위해 develop에서 release를 분기한다.
5. 테스트를 진행하면서 발생하는 버그 수정은 release 브랜치에 직접 반영한다.
6. 테스트가 완료되면 release를 master와 develop에 merge 한다.

브랜치

master

• production을 위한 브랜치

develop

• base branch : master
• 개발을 위한 브랜치

feature

• base branch : develop
• 새로운 기능을 추가하기 위한 브랜치
• origin에 반영되지 않으며 local repo에만 존재

release

• base branch : develop
• 새로운 production 릴리즈를 위한 브랜치
• 현재까지의 기능들을 묶어서 develop에서 release를 따옴
  • develop에는 다음번 릴리즈를 위한 기능들을 추가
  • release의 버그는 release에 직접 반영하고, 필요하다면 변경사항을 develop에도 반영해준다.
• 릴리즈 준비가 완료되면 master에 merge 진행. 그 이후 develop에도 merge

hotfix

• base branch : master
• production에서 발생한 버그들을 fix하는 브랜치
• 수정 후 master, develop에 반영 (release가 존재한다면 release에도 반영)

Github flow

특징

• master의 role이 정확하다.
  • master는 항상 최신 상태를 유지하며, stable 하다.
  • 이는 master는 언제든 배포가 가능하다는 것을 의미한다.
• 자동화의 개념이 추가
• pull request를 통해 master에 반영(코드 리뷰 기능)
• 릴리즈의 개념이 없다.
• hotfix와 가장 작은 기능을 구분하지 않는다.
• 원격 브랜치로 수시로 push

Git flow + Github flow

구조

• develop > staging > production
• Github flow의 지속적인 merge와 Git flow의 테스트가 완료된 커밋들을 선별적으로 배포할 수 있는 구조
• Github flow에 staging 브랜치를 추가하고 interactive rebase를 이용하여 develop에서 원하는 커밋들을 staging에 반영

브랜치

develop

• 개발을 위한 브랜치(기능 구현에 초점)
  • pull request를 거친 커밋들이 자유롭게 올라간다.
• production의 배포와 관계가 없다.
  • 배포 주기에 구애받지 않는다.

staging

• develop에서 배포가 확정된 커밋들이 존재
• staging은 지속적으로 유지가 되는 브랜치
  • 배포 가능한 빌드를 staging 빌드로 테스트 가능
• 실제 production 환경에서 테스트
  • 배포 기능과 버그 수정에 집중

production

• 실제 배포가 되는 브랜치
• staging에서 테스트 후 production으로 merge가 되면 배포가 완료

정리

이번 flow 정리를 통해 사수에게 미안함을 또 한번 느끼고, 이 참에 이런 정리의 시간을 가지게 해줘서 감사의 마음을 느낍니다.

Github flow에 develop(staging 겸용)을 추가하며, git으로 삽질을 했는데.. 이런 flow 보다도 upstream이나, rebase와 merge의 차이점에 대해 공부해야겠다는 생각도 듭니다.

참고

• 지속적 통합/배포(CI/CD)를 위한 Git Workflow 전략