더 나은 Git 워크플로우를 향해서

최근 몇개월간 Git 활용이 일진보한듯 하여 몇글자 적어본다.

 

0. 레포구조

• 시작하기 - 버전 관리란?
• 분산 환경에서의 Git - 분산 환경에서의 워크플로

깃은 분산 버전 관리 시스템(Distributed Version Control Systems)이기 때문에 각 컴퓨터마다 레포지토리를 가질 수 있다. 

로컬, 중앙집중형, 분산형

 

개발자 각자가 로컬 커밋을 가지고 원하는 때에 서버에 반영할 수 있는 것은 물론, (시간)

레포지토리 연결구조도 원하는대로 가져갈 수 있다.  (공간)

중앙집중형, 깃허브/깃랩 방식, 계층형

위에서 가장 복잡해보이는 계층형은 리눅스처럼 거대한 프로젝트가 운영되는 방법이다.

메인테이너 밑의 관리자가 각자 분야의 기여를 받고, 최종적으로 메인테이너가 관리자 레포를 merge하는 식으로 운용한다.

이렇게 다양한 방식으로 구성할 수 있다는 점은 DVCS의 커다란 매력이다.

 

Git이 가지고 있는 다른 장점들을 보고 싶다면 다음 사이트를 참고해보자.

• Why Git is Better than X

 

1. 브랜치 구조

브랜치(분기) 전략은 Git의 처음과 끝이다.

그 중 브랜치 구조부터 뜯어보자.

Hello Serverless, Goodbye Git Flow

 

추후 나올 Master, Main, Mainline, Trunk는 모두 동일하게 쓰인다.

 

GitHub Flow

먼저 개발자들이 가장 쉽게 익힐만한 방식, Github flow.

Introduction to Git Version Control Workflow

1. 기능이나 버그 브랜치 만들기
2. 풀리퀘스트 생성
3. 피드백 받아 고치기
4. 병합

단순하고 이해하기 쉬운 방식이다.

Git Workflows

버그든 기능이든 브랜치를 만들어 병합하기만 하면 알아서 배포가 되거나 릴리즈 태그를 달아 배포하는 형태.

 

Git Flow

많은 사람들이 들어봤을 Git flow다. [A successful Git branching model]

배포를 마구마구 하는 웹이 아닌 어플리케이션이나 보다 전통적인 개발에 초점이 맞춰져 있다.

1. Feature 브랜치에서 개발해 Develop 브랜치에 병합
2. Develope 브랜치가 충분히 성숙하면 Release(Stage) 생성
3. Release 브랜치에서는 버그 수정만
4. Release가 준비되면 Master에 병합하고, 릴리즈!!
5. 릴리즈 후, 핫픽스가 생기면 다시 릴리즈하고 Develope 브랜치에도 적용

 

꽤나 체계적이다.

그러나 너무 복잡하다. 개선해보자.

 

Gitlab Flow와 Perforce Stream

GUI에서 MVC -> Flux 아키텍쳐처럼 선형적으로 넘어가는 것처럼 흐름을 보다 단순히 만들어보자.

Develop, Stage, Master는 장기적으로 유지되고, Feature, Bug, Hotfix는 단기적으로 유지하는 건 어떨까?

더 나아보인다.

 

조금만 더 바꾸어보자.

보통 Gitlab flow라고 부른다.

Gitlab flow

1. Hotfix를 Develop, Stage, Master에 모두 병합하는 대신 양옆의 2개에만 하기
2. Github Flow처럼 Develop을 Master로 하기 (경우에 따라 Staging을 Master로 할 수 도?)

 

Github 워크플로우에 한층 가깝게 만든다면 Perforce의 Stream도 좋은 예다. [What Is Perforce Streams?, Codelines and Streams]

Github 워크플로우와 차이라면 명확한 역할이 정해져 있다.

1. Release, Main(master), Develop으로 구성
2. Release에서는 버그를 고쳐 Main 방향으로 전파 (Merge Down)
3. Main도 Develop으로 전파, 기능이 만들어지면 충돌을 없애고 Main에 반영

 

Trunk 기반

Trunk 기반 개발은 Main(Master)를 보다 효율적으로 사용하기위한 방법이다. [Git Branching Strategies vs. Trunk-Based Development,  Trunk Based Development]

Main 브랜치만 오래 유지해 충돌이 줄이는데, 구글과 페이스북 규모에서 많이 사용한다.

1. Main만 장기유지 Branch로 사용
2. 다른 Branch들은 짧게 유지
3. 기능은 플래그를 사용해 Off 상태로 병합해 항상 최신 코드 유지
4. CI/CD를 적극적으로 활용

 

정리

Staging 과정이 필요하면 Gitlab flow, 아니라면 Trunk 기반이 합리적으로 보인다.

 

2. 커밋

컨벤션

비교적 커밋 메세지 컨벤션(규약)에 관해서는 공감대가 있다고 생각한다.

• Conventional Commits
• Git Commit Guidelines

기본적으로 타입에 fix:[버그수정]와 feat:[기능추가]을 사용하며, 앵귤러 컨벤션을 따라 docs:[문서수정] style:[포매팅] refactor:[리펙토링] perf:[성능향상] test:[테스트] chore:[툴링], bump:[패키지 버전업] 등을 사용하는 경우가 일반적이다.

타입: 설명

본문(선택)

꼬리말(선택)

 

물론 합의와 일관성만 지켜진다면 선호도에 따라 조정할 수 있다고 생각한다.

• 타입에 이모지 사용: 개인적으로 터미널에서 입력하기 까다로워 불호이나 gitmoji 툴을 써볼 수 있다
• 개인적으로 "feat(api): send email to the customer"보다 "Feat: API - Send email to the customer"처럼 대문자로 위계를 주고, 적용범위는 대시를 사용하는 방식를 좋아한다

 

전 커스텀을 해서 반강제적으로 고르도록 하는 편.

당연하겠지만 추적할 이슈를 넣을 수 있다면 넣는게 좋다.

커밋을 하게된 배경등 히스토리와 문서 측면에서 상당한 장점이다.

 

단위

보통 커밋은 최소 단위별로 되어야 한다. [깃(Git) 커밋 가이드]

그러나 최소단위에 대해서는 각자의 생각이 다를수 밖에 없고 논란이 될 수 밖에 없다.

사실 이 글을 적게된 원인..

 

일단 나는 가능한 최대한 자주하고, 나중에 필요하다면 합치는 방향으로 한다.

• 커밋을 rebase로 합치기는 쉽지만, 나누기는 어려움
• 패키지 Bump, 오타수정처럼 사소한 커밋도 이미 존재

 

이때 전체가 아닌 필요한 변경사항 단위로 커밋할 수 있다면 좋다. [Git에서 변경사항 단위(Hunk)로 스테이징하기]

또한 툴에서 delta 단위로 변경사항을 비교할 수 있는지도 체크해보자.

변경단위별로 스테이징, 변경 Delta 추적

 

투기적 커밋과 선형적 기록

자, 그럼 얼마나 자주할 것인가?

나는 나중에 PR을 열기 전이든, 병합하기 전이든 추후 적절히 보이기만 하면 상관없다는 마인드라 저장이 필요하다 싶을 때마다 한다.

심지어 컴파일이나 린트를 안되는 상태에서도.

1. Stash 후 바로 pop할 상황이 아니라면 일단 스냅샷으로 만듦
2. 작업 중 다른 방법이 생각나 테스트 해볼 때
3. 다음 작업하기 전 Save가 필요할 때
4. 그냥 Remote에 백업이 필요할 때

이를 투기적 커밋이라 부른다.

 

깃은 DVCS라 바로 main에 반영되지 않게 또는 본인 레포의 리모트에 푸시가 가능하며, 앞서 말했듯 "잘 정리하면" 된다.

그래서 추가적인 도구를 사용한다. (써보면 후회하지 않습니다)

• Git-Branchless - 브랜치를 사용하지 않는 Git 워크플로우 지원 도구 모음

git-branchless라는 CLI 툴.

Branchless라는 이름답게 마구마구 분기를 양산해도 선형적으로 유지할 수 있다

1. git sl 또는 git smartlog를 사용하면 직관적인 그래프로 추적가능
2. git prev와 git next로 쉬운 checkout
3. git sync를 통한 자동적인 rebase, git move를 통한 커밋 옮기기
4. prev 커밋에서 리베이스로 재작성 후 git next로 움직이고 싶다면 git restack으로 고쳐주기
5. git undo로 언제든지 되돌리기!!
6. git revision보다 강력한 revset

 

글로는 와 닿지 않죠?

한번 스크린샷을 통해 확인 해보도록 합시다.

 

초기화

우선 초기화를 하고 일반적인 분기를 생성 해볼겁니다.

• git init과 git branchless init으로 초기화
• commit0 ~ commit2 이후에 featA라는 분기를 만들어 commit3, commit4 진행
• main으로 돌아오기

git init --initial-branch=main
git branchless init --main-branch=main

touch commit0
git add commit0
git commit -m "Add: commit0"

touch commit1
git add commit1
git commit -m "Add: commit1"

touch commit2
git add commit2
git commit -m "Add: commit2"

git switch -c featA
touch commit3
git add commit3
git commit -m "Add: commit3"

touch commit4
git add commit4
git commit -m "Add: commit4"

git switch main

 

로그를 보면 알겠지만 git hook을 통해 구동된다.

 

로그는 다음과 같이 보여지겠죠.

git log --graph --oneline --all --decorate --color --topo-order --branches -10 | tac

git sl(git smartlog)로도 확인을 해봅시다.

간단한 명령어로 정보를 더 보기 편하게 보여준다.

git sl

기본 사용법

이번에는 익명분기도 만들어봅시다.

둘 다 잘 추적해주고 있는 모습을 볼 수 있다.

touch commit5
git add commit5
git commit -m "Add: commit5"

git switch --detach

touch commit6
git add commit6
git commit -m "Add: commit6"

이제 바로 전 커밋인 main으로 다시 돌아가고 싶다고 해보자. 어떻게 해야 할까?

일반 git이었다면 git swith main이라 했겠지만 여기서는 전 커밋으로 전환하는 git prev 명령어로 충분하다.

git prev

 

반대로 다음 커밋으로 이동할 때도 next로 전환하기만 하면 된다.

숫자를 넣어 prev 3 하면 3 커밋전으로 전환하는 식이라 간편하다.

git next
git prev 3

 

커밋 옮기기

지금은 main 다음이 commit6이다.

그런데 commit 3과 4가 main 이후에 오도록 유지하고 싶을 수도 있다.

선형적으로 기록을 유지하려면 필요할 작업이죠.

 

git-branchless 툴을 사용하면 commit3으로 이동한뒤 git sync라고 하면 main을 기준으로 리베이스가 된다.

git next 2 -o # 오래된 커밋쪽으로 이동, 새로운 커밋쪽은 -n
git sync

이렇게 해버렸다가 후회하면 어떻게 하냐고요?

마법의 무기 git undo로 되돌려버릴 수 있다.

git undo

여기서 git sl의 장점이 하나 더 나온다.

바로 의미있는 익명분기만 똑똑하게 추적해 준다는 점!!

사실 스크린샷 찍기를 깜박해서 이미 한번 git undo로 되돌린 상태인데요,  git log 그래프를 보면 상당히 더럽습니다. (commit3과 4가 3번이나 표시)

이번에는 commit6을 commit4 뒤로 옮겨봅시다.

git move -s 7de4f31 -d d4b489a

 

undo후 featA 브랜치인 commit3과 commit4를 commit6 뒤로 옮겨볼 수도 있다.

git undo
git move -b featA -d 7de4f31 # 같은 분기에 속한 -b 413c2f2 또는 -b d4b489a 를 해도 상관없음

이렇게 모든 커밋 기록을 꼭 선형으로 유지해야 할 필요는 없다.

하지만 Feature  브랜치를 병합하기 전이라던가 제한적으로 쓸때도 편하다고 생각한다.

 

분기 없이 유지하기

짜잔~ 커밋 그래프를 선형적으로 유지하기가 이렇게나 쉽습니다?

그런데 생각해보니 commit6과 commit3을 rebase하고 싶어졌습니다.

git rebase -i HEAD~2

..? 새로운 커밋이 생성되기 때문에 분기가 생겨버렸네요.

다행히 안내가 뜨는대로 git restack 명령어로 깔끔히 해결되니 걱정마십시오.

git restack

이를 이용하면 처음 언급했던대로 투기적 커밋 후 리베이스하는 방식으로  할 수 있다.

코드를 작성한 컨텍스트는 보존되고 뒷감당은 툴이 해줍니다.

이에 관심있다면 git record와 git amend도 읽어보십시오.

 

또한 git restack은 rebase뿐만 아니라 git commit --amend 일 때도 모두 적용이 가능하다!!

sync나 move시 conflict가 생길 경우 명시적으로 --merge 옵션을 추가하도록 실패하며, 설사 merge를 시도하다 안되겠다 싶으면 언제든지 git undo로 되돌릴 수 있다.

 

이제부터 더 간단해보이는 커밋 그래프와 두려움 없는 git 명령어들을 누려보세요.

참고로 HEAD~같이 단순한 revision보다 강력하고 쉬운 revset이 있으니 선택자가 필요하다면 확인해보길 바란다.

익명분기 추적, revset 모두 Mercurial(hg)의 훌륭한 자산이었던 것들이다.

 

git branchless 개발자가 메타 출신 엔지니어라서 그런지 메타의 VCS인 Sapling과 굉장히 유사하다.

 

3. 병합

단위

메인 분기에 병합하기 전에 가장 걸리는 것은 바로 코드 리뷰다.

4~5000라인? 아니 1000라인 정도만 되도 "다른사람이 작성한" 코드를 보기란 쉽지 않다.

 

패치 스택(Patch Stack)

이를 해결하기 위해 나온 방식이 바로 Patch stack이다.

•  Stacked pull requests: make code reviews faster, easier, and more effective
•  A Better Model for Stacked (GitHub) Pull Requests

기능[1/3], 기능[2/3], 기능[3/3]처럼 쪼개서 리뷰 후 병합하면 체크해야할 양이 현저히 줄기 때문에 좋다.

리뷰할 때는 기능[1/3], 기능[2/3], 기능[3/3] 순으로 하여 커밋이 필요하면 추가하고, 병합할 때는 기능[3/3], 기능[2/3], 기능[1/3] 순으로 병합하기 때문에 Patch Stack이라 불린다.

일반 분기 vs 패치 스택

 

git-branchless의 경우 git submit이라는 명령어를 통해 branch들을 push하는 형태이고,

본격적인 툴로 Graphite가 존재한다. (Phabricator나 gerrit도 참고해볼만하나 phabricator는 메타가 버렸고, gerrit은 구글 전용 느낌이다.)

찾아보니 메타의 경우 ReviewStack이라는 깃허브와 연동되는 도구를 새로 만들어서 쓰는 것 같다.

 

패치 스택과 관련된 글을 보면 알겠지만, 여기서도 선형적 커밋 그래프 관리가 빛을 발한다.

병합 커밋 vs 선형적

이렇게 선형적으로 관리를 하면 보기 좋은 것은 물론 git bisect를 이용해 문제있는 커밋 식별하기도 쉬워진다.

무언가 자동적으로 식별한 후 고치고 싶다면 git-branchless의 git test을 사용해보자.

 

병합 큐(Merge Queue)

병합에 있어 또 다른 문제는 다양한 이슈에서 생기는 풀리퀘스트를 병합할 때 문제가 생길 수 있다는 것이다.

앞선 Patch stack이 한 문제를 잘개 쪼개는 방법론이라면, 병합큐는 여러 이슈에서 생기는 병합 요청을 통합하여 해결하자는 방법이다. (개념적으로는 비슷하나 병합 큐는 전역적이다)

 

예를 들어, 잘 작동하는 feature1과 feature2라는 풀리퀘스트가 있다고 가정해보자.

각각 병합할때는 괜찮지만, 두개가 모두 병합될때는 충돌이 생길수도 있다.

Merge queues: An intro for mobile engineers

 

때문에 바로 병합하는 대신 git의 stage 영역의 개념처럼 Merge ready 상태를 도입한다.

1. 풀리퀘스트를 바로 병합하는 대신 Merge queue에 추가함
2. Merge queue에 존재하는 분기의 상태로 풀리퀘스트를 업데이트
3. 다시 CI 검사를 실행함

 

내가 아는한 Shopify가 도입한 기능으로,

• Introducing the Merge Queue
• Successfully Merging the Work of 1000+ Developers

 

깃랩은 merge train, 깃허브에서는 merge queue라 부른다.

• Merge trains
• How starting merge trains improve efficiency for DevOps
• How to use merge train pipelines with GitLab
• Merge train/Release train/Merge when master succeeds: run build on merged code before merging
• GitHub merge queue is generally available

 

+

이슈 관리에 있어서도 종속성을 다룰 수 있었으면 한다. [about:Mozilla's blockers and needinfos, QA/Bugzilla/Fields/Status]

버그질라에는 blocker와 needinfos라는 이슈 종속성 시스템이 존재한다.

• blocker: A이슈로 인해 B이슈가 해결될 수 없다면, A이슈는 B의 blocker이다.
• needinfo: 더 많은 정보가 제공될 때까지 재현 및 수정될 수 없는 버그

 

충돌 - 일급 충돌 및 3 Way diff

Git에 없어서 아쉽지만, Jujutsu, Pijul에는 일급충돌이란 개념이 있어서 충돌을 기록할 수 있다.

이렇게되면 한번 해결한 충돌이 나중에 또 일어나는 일이 적다.

Jujutsu는 깃과도 호환되니 사용해 볼 수 있음.

 

git note에 메타데이터를 저장하는 방법을 제안했으나 많이 느려서 써먹기가 어렵다는 모양이다 ㅠㅠ

그리고 Jujutsu의 3-way diff방식은 매우 보기 편하다.

# Git 방식
  <<<<<<< left
  apple
  grapefruit
  orange
  ======= base
  apple
  grape
  orange
  ||||||| right
  APPLE
  GRAPE
  ORANGE
  >>>>>>>

# Jujutsu 방식
  <<<<<<<
  %%%%%%%
   apple
  -grape
  +grapefruit
   orange
  +++++++
  APPLE
  GRAPE
  ORANGE
  >>>>>>>

 

Jujutsu의 3way diff 방식은 깃에도 들어갔으면 하는 바램이다.

단, 위 방식이 기존 IDE, 에디터의 문법강조와 호환이 안될 가능성이 높고, 2개의 Diff등을 원할 수 있기 때문에 Better conflict marker 제안을 해보는 중.

아마 Jujutsu쪽에 다시 글을 올리게 될 것 같다.

 

충돌 - 바이너리

Git이 충돌날때 고질적인 단점 중에 하나는 바이너리의 처리다.

매번 충돌이 생겼으니 알아서 하라는 방종이 마음에 안들었다.

일단 충돌이 생겼다는데 어떻게 하라는 건지..

 

학교에 돌아가면 PDF라던가 바이너리 파일을 다룰일이 많으므로 러스트로 간단히 바이너리 충돌동작 개선안을 만들어봤다.

• Binary conflict

보다시피 3개의 파일을 볼 수 있다.

• base: 분기의 시작인 파일
• 그냥: 충돌 나기 전에 병합된 현재 보여지는 파일
• their: 병합을 시도하는 새로운 파일

 

이렇게 3개의 파일을 동시에 보여주게 되면 필요한 파일이면 추가, 필요없으면 제거를 함은 물론 워드나 프리젠테이션 파일이면 열어서 직접 비교한 후 병합할 수 있다.

 

패치와 메일

• 분산 환경에서의 Git - 프로젝트에 기여하기
• 분산 환경에서의 Git - 프로젝트 관리하기
• Learn to use email with git!

제가 사용하지는 않지만 필요한 사람을 위해 남겨놓는다.

 

최근 깃 사용에서 다른 사람의 변경사항을 반영하는 방법은 Pull Request를 생성 후 병합(Merge)하는 방식일 것이다.

왜 Pull request인가 하면 옛날에 깃허브에서 프로젝트에 기여를 하기 위해 요청하면 기여자의 리포트 레포에서 git pull을 하라는 메일이 갔기 때문이며 git request-pull 이라는 명령도 존재한다.  [Better Pull Request Emails]

지금은 버튼만 누르면 깃허브나 깃랩등 서버에서 대신 해준다.

pull 요청 메일

 

다른 방식이라면 나처럼 젊은 개발자들은 익숙하지 않겠지만 패치 파일을 생성하고 이메일 처리하는 방식이 있다.

리눅스나 org mode같은 전통있는 오픈소스들이 애용하는걸로 알려져 있다.

다음은 Free desktop에서 제공하는 예제이다.

# == 설정 ==
# 본인 정보
git config --global user.name "My Name"
git config --global user.email "myemail@example.com"

# 본인의 메일 서버 연동
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpserver mail.messagingengine.com
git config --global sendemail.smtpuser tanuk@fastmail.fm
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtppass hackme

# 메일 받을 대상 설정
git config sendemail.to pulseaudio-discuss@lists.freedesktop.org

# == 보내기 ==
# 패치 전송
git send-email HEAD^

# 패치 버전2 전송
git send-email -v2 HEAD^

# 패치 생성 후 보내기
git format-path origin/master # 이메일용 패치 생성
git send-mail *.patch

# == 적용하기 ==
# 패치 적용
git am filename.mbox

# 리눅스의 경우
b4 am -o- <url> | git am

 

최근에는 SourceHut이라고 git send-email과 메일링 리스트(예시)를 최대한 사용하는 서비스도 있는 듯 하다.

리눅스의 경우 b4라는 툴을 직접 만들어 사용하는 모양이다.

만약 이 방식을 사용할 것이라면 이메일과 관련된 git 명령어들 모음도 확인 바란다.

 

4. 기타 관리 방법

기능개발과 버그 수정을 동시에 - Worktree

• Git worktree 소개
• git-worktree - Manage multiple working trees
• Get your git game up with git worktrees

git worktree 기능을 사용하면  git history는 공유된 채로 작업파일들만 여러곳에 체크아웃하여 작업들을 동시에 진행할 수 있다.

나같은 경우는 기능개발과 버그수정을 동시에 할 필요가 있을 때 사용한다.

stash나 커밋 후 branch 전환후 작업하거나 clone을 새로 받을 필요가 없다.

 

주요 명령어는 다음과 같다.

git worktree add [path]        # 워크트리 추가
git worktree remove [worktree] # 워크트리 제거
git worktree list              # 등록된 워크트리들을 보여줌

 

위 설명을 들으면 마치 SVN의 분기를 떠오르게 하는 방식이다.

SVN 브랜치(branch)와 merge

 

대용량 파일 - Git LFS

이제부터 나오는 내용들은 예전 CI/CD 성능 관련해 적었을 때 소개한 적이 있을 것 이다.

그 중 첫번째는 대용량 파일로 깃허브의 경우, 50MB 파일은 경고 100MB 이상 파일은 차단하고 있다.

대부분의 경우 Git LFS로 해결할 수 있지만 여전히 최대 파일 크기가 제약되어 있다.

Git LFS

 

아니면 다음 솔루션들을 고려해볼만 하다

• DVC: Git Annex와 비슷하나 머신러닝 데이터처럼 더 커다란 파일과 클라우드에서 공유 #211
  • 비슷하게 Git과 호환되는 xetdata, diversion이 있는 것 같다
• Snowtrack: 2D/3D 디자인 리소스들 관리에 최적화, 관심있다면 SnowFS도 확인하자
• elfshaker: 바이너리 압축이 고도로 가능
• JamSync: Rsync에 기반하여 항상 최신으로 유지

 

모노레포 - 부분복제

• Get up to speed with partial clone and shallow clone
• Bring your monorepo down to size with sparse-checkout

모노레포는 분리된 다양한 관심사가 한데 모여있어 쓰지도 않은데 괜히 차지하는 용량이 크다.

예전에 나왔던 내용의 동어반복이겠지만, 핵심은 2가지다.

.git(bare git)의 내용을 부분복제(Partial clone)하기와 작업파일 부분 체크아웃(Sparse checkout)하기.

 

먼저 부분복제로 다운로드하는 시간을 줄여보면 clone시 파일(--filter=blob:none), 디렉토리(--filter=tree:0), 커밋기록(--depth=1) 등을 제한 시킬 수 있다.

파일, 디렉토리, 커밋 기록 제외

git이 clone되고 나면 실제 작업파일들을 보여줘야 한다.

이때 시간이 오래 걸리므로 필요한 작업파일들만 사용할 수도 있다.

사용하는 작업 디렉토리만 보여주기!!

 

그렇다면 리눅스 소스코드를 다운로드 받아보자.

20분이나 걸리던 작업이..

 

겨우 1분만에 다운로드 받아진 것을 볼 수 있다.

git clone --depth=1 --sparse https://github.com/torvalds/linux

나 같은 경우 sparse-checkout은 github action이나 문서처럼 의존성이 적은 작업의 커밋이 필요할때 유용하게 쓰고 있다.

 

특정한 폴더만 받는 기능도 SVN의 킬러 기능이었으나 모두 대체 가능해지면서,

깃허브는 2024년 1월 8일에 SVN 지원을 제거하게 된다.

 

모노레포 - 스칼라!!!!!!

• The Story of Scalar
• Introducing Scalar: Git at scale for everyone

이 기능에는 마소의 눈물겨운 노력이 깃들어있다..ㅠㅠ

윈도우 소스코드가 너무 커서 다운로드에 12시간, 체크아웃에 3시간이나 걸려 개선하기 위한 형태의 종착역이다.

 

sparse checkout이 기본은 물론, GVFS라는 프로토콜로 빠르게 다운로드가 가능하다고 한다(Azure devops만 현재 지원).

 

그리고 관리를 위해 여러 커스터마이징이 된 부분들이 존재한다.

• 빌드 결과물을 소스와 분리하기 위해 clone시<project_name>/src에 소스코드가 위치
• 인덱스와 수정된 크기 추적 및 압축
• 백그라운드에서 fetch, 커밋그래프 작성, 팩 파일 정리 및 색인 생성 작업을 실행

앞서 depth=1을 하면 커밋기록이 사라지는 것과 달리 기록이 보존되면서 파일들이 필요하게 되면 적절히 다운로드를 해준다.

대형 레포를 가지고 있는 곳이라면 시도해볼만 하겠다.