머가필요해

최근에 "git sparse-checkout" 명령어를 살펴보면서 git version을 좀 따져보았었다.

  - https://www.whatwant.com/entry/sparse-checkout-size

"떡 본 김에 제사지낸다"고,

이번 기회에 Git 최신 버전을 사용하기 위한 방법을 살펴보도록 하겠다.

[ Environment ]

릴리즈된지 좀 오래되긴 했지만,

실무에서 주력으로 사용되는 Ubuntu 20.04 버전을 기준으로 하겠다.

(설마 우리 회사에서만? ^^)

[ Default ]

Ubuntu 20.04 설치 후에 "git" 설치는 손쉽게 가능하다.

버전까지 바로 확인해보자.

[ Check ]

그러면, 지금 현재 git 최신 버전은 어떻게 될까?

공식 홈페이지에서 확인되는 최신 버전은 "v2.41.0"이다.

최신 버전을 사용하는 것이 중요할까!?

"Release Notes"를 한 번 살펴봐보자.

밑으로 스크롤을 내려보면 지난 버전의 Release Note도 확인 가능한데,

뭔가 새로운 명령어나 기존 명령어의 변경 및 개선 사항들이 많이 보인다.

즉, 새로운 버전이 필요한 상황이 발생할 수 있는 여지가 많다!

[ Install ① Using Apt ]

Git PPA를 추가해서 apt를 이용해 Git 최신 버전을 설치해보자.

이걸로 끝이다.

이렇게 하면 너무 쉽기에 추천할만한 방법이지만...

간혹 내부망 등의 이슈로 PPA 추가가 어려운 경우가 있으니 다른 방법도 알아보자.

[ Install ② Source Build ]

좀 번거로울 수도 있지만, 소스코드를 내려 받아서 직접 빌드를 해보자.

일단 apt로 설치한 git 패키지를 삭제하자.

빌드에 필요한 것들을 미리 설치해두자.

소스코드를 내려받을 곳을 확인해보자.

오른쪽 하단의 tags를 클릭해보자.

소스코드 내려받고, 압축을 해제하자.

이제 빌드 진행하면 된다. 어렵지 않다.

기본 환경 설정은 필수 !!

자동완성 기능을 사용하고 싶다면 추가 설정을 진행하자.

bash를 사용하는 경우에는 다음과 같이 하면 된다.

zsh을 사용하는 경우에는 다음과 같이 하자.

뒷 부분에 다음 라인을 추가하면 된다.

shell 관련된 사항은 shell에 재진입해야 적용된다.

그게 싫다면 source 하던지...^^

빌드해서 설치까지 진행하는 과정이 어렵게 느껴질 수도 있지만

직접 버전 선택하고, 환경도 직접 꾸미는 것이 확실한 방법이긴 하다. 화이팅 !!

구글링을 하다가 우연히 발견한 멋진 제목 하나!

"Git 특정 디렉터리만 clone 하기"

여러 팀이 하나의 Repository를 사용하는 "Mono-Repo" 방식으로 소스코드를 관리할 때

너무 커져버린 용량으로 인한 어려움이 있을 경우에

이런 제목의 글이 눈에 들어오기 시작한다. ^^

3개의 팀이 다음 그림과 같이 mono-repo로 개발한다고 해보자.

3개팀에서 각자 개발하는 내용이 하나의 저장소에 모이기 때문에 2가지 이슈가 있다.

1. clone 받을 때 용량이 쓸데없이(?) 커서 오래걸린다.

2. 개발할 때 쓸데없는(?) 다른 팀 내용들까지 같이 보인다.

[ background ]

일단 보통의 방법으로 clone을 해보자.

200MB 규모의 Repository이다.

tree 방식으로 디렉토리/파일을 보기 위해 tree 유틸리티 설치 후 사용해봤다.

50MB 크기의 파일 4개로 구성된 Repository다. (테스트를 위해 만든 저장소 ^^)

[ sparse-checkout ]

0. environment

- 이하 실습을 진행하는 환경은 다음과 같다.

  . OS : Ubuntu 20.04 LTS

  . Git : v2.25.1

1. git

- "sparse-checkout" 명령어는 Git v2.25.0 부터 추가되었다.

- 천만 다행으로 Ubuntu 20.04에서 제공되는 Git 패키지의 버전이 가까스로 0.00.1을 넘겼다 ^^

- 과거 Git v1.17.0 부터 "sparse checkout"을 제공했었다! (사이에 "-"가 있고 없고의 차이)

  . 그 때의 명령어 사용법과 차이가 있는데, 많은 웹 포스팅에서 이를 섞어서 설명하고 있다.

2. 어렵게 clone 받기

- 블로그를 돌아다니다 보면 조금 어렵게(?) 아니 번거롭게(?) clone 받는 방법을 소개하고 있다.

으응?!

- Work Directory의 내용만 보면 내가 원하는대로 client/ 디렉토리만 존재한다.

- 하지만, clone 받는 용량이 줄어든 것은 아니다.

- sparse-checkout 명령어는 work directory를 다루기 위한 명령어이지 전송받는 데이터 용량을 줄여주는 것은 아니다.

- 그렇다면, 위와 같이 어렵게(?) clone을 받을 필요가 없다.

3. 편하게 sparse-checkout 적용하기

- 일반적인 방법으로 clone을 받고 sparse-checkout을 이용해서 정리하는 것이 훨씬 편하다.

- 훨씬 간단하지 않은가?! ^^

4. 결론

- "sparse-checkout"은 전송 용량을 줄이기 위한 것이 아니고,

- 내가 개발하는 내용(파일)만 보면서 개발하기 위한 용도로 사용하는 것이다.

[ --filter=blob:none ]

0. background

- 웹서핑을 하다보니, clone을 순식간에 할 수 있다는 옵션을 소개하곤 했다.

1. clone

- "--filter=blob:none" 옵션을 사용하면 필요한 만큼만 blob를 내려받는다.

- 보통의 방식으로 clone 받는 것과 비교해보자.

- 어!? 용량이 차이가 난다! 이건 써볼만한 방법이다!!!

2. with sparse-checkout and 'no-checkout'

- clone 받을 때 "--no-checkout" 옵션을 넣으면 working directory에 checkout을 하지 않는다

- 이렇게 clone을 받은 후 해당 디렉토리를 들어가면 필요한 일부 blob를 내려받느라 시간이 조금 소요된다.

- 용량이 또 줄었다! ^^

3. 결론

- clone 받을 때 "--filter=blob:none --no-checkout" 옵션을 추가해서 최소한으로 다운받고,

- 'sparse-checkout' 명령어를 섞어주면 내려받는 전체 용량을 확실히 줄여줄 수 있다.

git sparse-checkout 명령어에 대한 자세한 내용은 다음 링크를 참조하기 바란다.

- https://git-scm.com/docs/git-sparse-checkout/2.41.0

최근 SW 개발자들이라면 `Git`이라는 버전관리 도구를 무조건 한 번 이상 사용해봤을 것이다.

사실 대부분 회사일로던 개인적인 사유로던 `GitHub` 계정이 이미 있을 것이고

Repository 하나 이상쯤은 만들어봤고, clone도 받아봤을 것이다.

`Git` 외에 다른 버전관리 도구들이 다양하게 존재하긴 하지만

일단 `Git`이 SW 개발자의 기본 소양이 되어버렸다는 사실은 그 누구도 부정하지 못할 것이다.

`StackOverflow Survey 2021` 에서 개발자들의 약 93%가 Git을 사용한다고 답한 것을 보면 확실하다!!!

'22년 Survey에서도 결과를 확인할 수 있으면 좋았을텐데, Git 항목이 2022년에는 빠져서... 아쉽다.

  - https://insights.stackoverflow.com/survey/2021#other-tools

그러면, 여러 Global 기업들도 모두 Git을 사용할까?!

`결론은 대부분 Git을 사용한다!` 이지만, 지금은 이걸 알아볼 때가 아니니 다음 기회로 넘기기로 하고...

Facebook(현 Meta)에서는 어떤 개발환경을 사용하고 있을까!?

  - 버전관리: Mercurial

  - 코드리뷰 및 태스크 관리: Phabricator

https://engineering.fb.com/2014/01/07/core-data/scaling-mercurial-at-facebook/

https://secure.phabricator.com/book/phabricator/article/introduction/

그런데, 위에 있는 링크를 타고 들어가보면 알겠지만,

Meta에서는 Mercurial을 그대로 사용하지 않고 상당히 많은 customizing을 가해서 사용하고 있었다.

Mercurial 자체도 Git과의 호환성을 보장하지만,

Meta에서는 특히 Git을 중심에 두고 GitHub 지원도 강화하기 위해 막대한 투자를 했다고 한다.

그리고 이렇게 Meta에서 10년 동안 열심히 개발한 버전관리 도구를 "Sapling"이라는 이름으로 공개했다!

  - https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/

어떤 도구인지 직접 한 번 설치해 보고 사용해봤다.

개발환경 구성이니만큼 Ubuntu 20.04 환경에서 진행했다.

사실 Ububtu 18.04 환경에서 하고자 했으나, Sapling이 Ubuntu 20.04/22.04 버전만 지원한다.

1. GitHub CLI

  - Sapling에서 GitHub 연결할 수 있도록 하기 위해 GitHub CLI 도구를 설치하자

  - https://cli.github.com/

  - Ubuntu 환경에서의 설치는 아래 링크에 친절히 나와있다.

  - https://github.com/cli/cli/releases/download/v2.20.2/gh_2.20.2_linux_amd64.deb

  - 1회성으로 다운로드 받아서 설치할 수도 있다.

  - https://github.com/cli/cli/releases

  - 인증 정보도 등록하자

2. Sapling Install

  - 본래 주력으로 사용하고 있는 Ubuntu 18.04에서 테스트 진행하려다 보니... 안타깝게도 18.04는 지원하지 않는다.

  - 빌드를 직접 해보면 될지 모르겠지만, 귀차니즘으로... 그냥 20.04 환경에서 진행했다.

  - 설치 과정은 다음 링크를 참조하면 된다.

  - https://sapling-scm.com/docs/introduction/installation#linux

3. clone

  - 기본적인 사용법은 git 명령어 체계를 따라가는 것 같다.

  - 기본적인 모습은 조금 특이하긴 하다.

  - clone을 받았을 때 `.git` 디렉토리가 아니라 `.sl` 디렉토리가 생긴다.

  - `sl` 명령어를 치면 지금 현재 브랜치 정보를 보여준다.

4. commit

  - committ 생성 과정을 살펴보자.

  - `git` 하고 차이는 마지막에 `sl` 명령어를 쳤을 때 나오는 정보 뿐이다.

5. web (SmartLog)

  - Sapling은 멋지게도 web 인터페이스를 제공해주는데 ... 그냥 실행하면 에러 나온다.

  - nodejs 설치하자

  - 이제 다시 web !!

  - 깔끔하고 예쁘다.

6. Pull-Request

  - PR 생성도 그냥 명령어 한 줄이면 된다.

  - 실제 GitHub에 생성되었는지 확인해보자.

여기까지 간단한 사용법을 살펴봤는데... 그냥 Git을 사용하는 것과의 큰 차이는 느끼지 못하겠다.

Git과의 차이점을 설명해주고는 있다.

  - https://sapling-scm.com/docs/introduction/differences-git

Staging Area가 없는 것과 몇 가지 차이가 보이기는 하지만,

사실 대용량 Repository일 때 Sapling의 장점이 돋보일 것 같기는 한데...

실제 작업하면서 사용을 해봐야 제대로 느껴볼 수 있을 것 같다.

이번 포스팅은 그냥 Sapling 맛만 보는 것으로...

요즘 개발자는 당연하고,

디자이너나 기획자들도 git 사용은 필수인 시대가 되었다.

인공지능(머신러닝, 딥러닝) 관련해서

공부를 하려고 해도 `git`을 사용할 수 밖에 없다.

아니, 사실 솔직히 말하면 git이라기 보다는 `GitHub.com`을 사용해야 하는 것이지만,

그 기반을 이루고 있는 git은 이제 일반 상식이다.

조금만 공부하면 사용할 수 있긴 하지만,

제대로 사용하려면 정말 어렵기만한 도구가 바로 git이다.

하지만, 실수를 했을 때 되돌릴 수 있는 방법만 알고 있다면

무서워 할 필요가 없다.

그리고, 어려움을 느끼고 있는 우리를 대신해서 욕을 해주고 있는 사이트도 있다 !!!

  - https://ohshitgit.com/ko

정겹지 않은가?! 

말이 좀 거칠긴 해도,

설명해주는 내용은 정말 말 그대로 꿀팁이다 !!!

그런데,

회사에서 보기에는 조금 부담스러울 수도 있다.

그런 분들을 위해 정중한 표현을 하고 있는 사이트도 제공을 해준다.

  - https://dangitgit.com/ko

아주 정중하지 않은가?!

재미로만 느껴질 수도 있겠지만,

내용은 정말로 상당히 괜찮다.

각자의 git 생활에 도움이 되기를 기원하며 ...

`git`에 대해서 한창 공부할 때도 있었는데,

요즘엔 쓰던 명령어만 쓰면서 그렇게 지내고 있던 와중에...

새로운 명령어(기능?)가 `high-level commands`로 추가되었다는 소식을 듣게 되었다.

`v2.23.0` 버전의 릴리스 노트에 `switch / restore` 2개의 새로운 명령어를 소개하고 있다.

  - https://github.com/git/git/blob/master/Documentation/RelNotes/2.23.0.txt

이하 과정은 `Ubuntu 18.04` 환경에서 진행했다.

1. 설치된 버전 확인

  - 새로운 명령어를 사용해보기 위해서는 `v2.23.0` 이상의 버전이 필요하다.

  - Ubuntu 환경에서 apt 패키지를 통해 설치되어있는 git 버전을 확인해보자.

  - 오래된 버전을 삭제하려면 다음과 같이...

2. 신규 버전 설치 (PPA)

  - 가장 편리한 방법인 PPA 추가해서 apt를 통해서 관리하는 방법이다.

3. 신규 버전 설치 (Source)

  - 개인적인 취향으로 좋아하는 방식인 Source Code 빌드해서 사용하기 ^^

    . https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

  - 자동 완성 기능도 설정하자

    . bash

  . zsh

  - git에서 결과 화면이 전환되는 방식으로 나오는 것이 싫은 경우

4. New Command

  - 새로운 명령어 `switch / restore`는 기존 `checkout` 명령어의 일부 기능이 분리된 것이다.

    . `checkout` : Switch branches or restore working tree files

    . `switch` : Switch branches

    . `restore` : Restore working tree files

5. Before (As-was)

  - 기존에 해왔던 방식을 살펴보자

  - git source code를 가지고 알아보겠다. (사이즈가 좀 크지만 그래도 ^^)

  - branch 정보를 살펴보자

  - local에 `develop` branch를 생성해보자 = local branch 생성 + 현재 작업 branch 변경

  - 다시 `master` branch로 변경해보자

  - 파일 하나를 변경하고 staging까지 해보자

  - staged 상태에 있는 파일을 빼내자

  - 변경된 파일을 원복 해보자

6. Now (To-be/is)

  - 이제 새로운 명령어로 위의 과정을 다시 해보자

  - `develop-2` branch를 생성하고 이동해보자

  - `master` branch로 이동!

  - 파일 하나 수정

  - 파일을 일단 unstaged 상태로~

  - 파일 원복!

지금까지 git에 새롭게 추가된 2개의 명령어 `switch / restore` 에 대해서 살펴보았다.

보면 알겠지만 기존에 안되던 새로운 기능이 추가된 것은 아니고

`checkout`에서 했던 기능 中 일부분을 분리해서 구성한 것일뿐이다.

기존에 `checkout`을 잘 사용해왔던 분들이라면, "굳이 왜~?"라는 말을 할 수도 있겠으나

처음 git을 접하는 분들이라면 조금 더 직관적인 명령어로 느끼지 않을까라는 생각이 든다.

그 동안 너무 git을 멀리해왔던 것 같아서 간만에 포스팅해봤다!

정말 간만에 해보는 git 설치.

거기에다가 windows 10 환경은 정말 정말 오랜만이다.

1. Homepage

   - 모든 시작은 홈페이지

   - https://git-scm.com/

2. Download & Install

   - 홈페이지에서 친절하게 알맞은 아이를 추천해준다.

   - 오른쪽 모니터 화면에 있는 `Download for Windows`를 클릭해서 다운로드 후 설치 진행하자.

   - 잘 모르겠으면 추천하는대로 `Next`를 선택하면 된다 ^^

   - 개인적인 취향으로 기본 에디터를 선택하면 되는데, 저는 `nano`를 좋아하므로... ^^

3. Test

   - 잘 설치되었는지 확인해보자.

   - 윈도우즈의 `cmd`를 이용해서 해도 되지만, 이왕이면 `Git Bash`로 한 번 해보자.

   - 시작 메뉴에서 `Git Bash`를 클릭하자.

   - 그리고 실행

끝~

Git 저장소를 오래 운영하다보니

호스팅하고 있는 서버의 스토리지가 부족한 일이 종종 발생한다. (Gerrit 또는 GitHub Enterprise)

(대체 왜 자꾸 바이너리를 올리는 것인지... 우이쒸~!!)

스토리지를 팍팍 늘리면 좋겠지만... 우리는 가난하기에.. ^^

이럴 때 보통 "git gc"를 실행하곤 하는데...

이게 성능/효과가 얼마나 있는지 실험을 해보고 싶었다!!!

0. target

    - 실험할 repo가 필요해서 찾던 中 최근 유명한 tensorflow를 대상으로 정했다.

    - 저장공간을 줄이는 것에 대한 실험이니만큼 "--bare" 옵션으로 clone 하였다.

    - 기본 저장 공간은 "455M"

1. [ git gc --aggressive ]

    - 가장 기본적으로 사용하는 옵션으로 해봤다. (오래걸렸다)

2. [ git gc --aggressive --prune=now ]

    - 구글링을 했더니, 안전하게 그리고 확실하게 gc를 하는 방법이라고 되어있는 2단계 실행법이다.

        . reflog는 "git rebase" 같은 작업을 하다가 발생하는 끈 떨어진(?) log들에 대한 정보이다.

뭐 결론은 2번 방법으로 실행하면 되겠다~!!!

안전한게 짱이지~!!

조금은 실망~