최근 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

 

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

❯ sudo dpkg --install gh_2.20.2_linux_amd64.deb

❯ gh --version                                             
gh version 2.20.2 (2022-11-15)
https://github.com/cli/cli/releases/tag/v2.20.2

 

  - 인증 정보도 등록하자

❯ gh auth login --git-protocol https

 

 

 

2. Sapling Install

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

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

 

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

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

 

❯ wget https://github.com/facebook/sapling/releases/download/0.1.20221118-210929-cfbb68aa/sapling_0.1.20221118-210929-cfbb68aa_amd64.Ubuntu20.04.deb

❯ sudo dpkg --install sapling_0.1.20221118-210929-cfbb68aa_amd64.Ubuntu20.04.deb

❯ sl --version                                                                  
Sapling 0.1.20221118-210929-cfbb68aa

❯ sl config --user ui.username "whatwant <whatwant@gmail.com>"

 

 

3. clone

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

❯ sl clone https://github.com/whatwant/whatwant               
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
오브젝트 묶음 푸는 중: 100% (6/6), 15.87 KiB | 7.93 MiB/s, 완료.
https://github.com/whatwant/whatwant URL에서
 * [새로운 레퍼런스] babeb04a267ae7ac642532df70c03517d1ea86ca -> remote/main
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

 

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

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

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

❯ cd whatwant

 ls -al
합계 76
drwxrwxr-x 3 chani22 chani22  4096 11월 24 15:25 .
drwxr-xr-x 3 chani22 chani22  4096 11월 24 15:25 ..
drwxrwxr-x 6 chani22 chani22  4096 11월 24 15:29 .sl
-rw-rw-r-- 1 chani22 chani22   443 11월 24 15:25 README.md
-rw-rw-r-- 1 chani22 chani22 58078 11월 24 15:25 career.md

❯ sl
@  babeb04a2  2021-10-17 04:04  whatwant  remote/main
│  Create career.md
~

 

 

4. commit

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

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

❯ touch sapling.txt 

❯ sl add .                                     
adding sapling.txt

❯ sl commit -m 'my first commit with Sapling'                 

❯ sl                                         
  @  f63c3b928  6 seconds ago  whatwant
╭─╯  my first commit with Sapling

o  babeb04a2  2021-10-17 04:04  whatwant  remote/main
│  Create career.md
~

 

 

5. web (SmartLog)

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

❯ sl web                                     
ERROR: `node` is required to run Interactive Smartlog, but it was not
found on the $PATH. For information on installing Node.js, see:
https://nodejs.dev/en/learn/how-to-install-nodejs/

 

  - nodejs 설치하자

❯ sudo apt install nodejs npm

❯ nodejs --version                           
v10.19.0

 

  - 이제 다시 web !!

❯ sl web

  - 깔끔하고 예쁘다.

 

 

6. Pull-Request

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

❯ sl pr 
pushing 1 to https://github.com/whatwant/whatwant
created new pull request: https://github.com/whatwant/whatwant/pull/1
updated body for https://github.com/whatwant/whatwant/pull/1

 

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

 

 

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

 

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

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

 

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

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

 

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

 

 

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

 

 

반응형

[ 한글 ]
형상 관리 (소프트웨어 형상 관리)
버전 관리 (소프트웨어 버전 관리)
소스 관리 (소스 코드 관리)


[ 영어 ]
Version Control
Revision Control
Source Control
Source Code Management (SCM)
Software Version Management
Software Configuration Management (SCM)




Subversion, Git, ClearCase 등과 같은 도구를 통해서 (또는 도구가 없더라도)
소스 코드, 문서, 결과물 등을 번호(버전)를 사용하여
관리하는 것을 무엇이라고 지칭해야 할까?



소프트웨어 공학(Software Engineering)이라는 학문은
개인적으로 '공학계의 인문학'이라고 여겨진다.

바꿔말하면 무엇을 정의하는 것이 어려우며,
정답이 없는 경우가 대부분이라는 말이다.



최근 아이폰이나 안드로이드로 인하여
대중화 되어버린 "플랫폼(Platform)"이라는 것을 보아도
분야마다 사람마다 그 정의가 전부 다를 수밖에 없다.

시험 문제로 "플랫폼의 정의를 쓰시오"라고
나오면 정말 당황스러울 것 같다.



이번의 경우는 조금은 색다른 경우인데,
이것을 지칭하는 용어가 너무 많아서 문제가 된다.

같은 것을 지칭하면서
다들 다른 용어를 사용하고 있는 것이다.



일반적으로는
Subversion, Git 과 같은 것을 지칭할 때에는
"버전 관리 도구 (Version Control Tool)"
라고 한다.

그러한 버전 관리 도구를 사용하여 구축한 시스템은
"버전 관리 시스템 (Version Control System, VCS)"
이라고 부르곤 한다.



소프트웨어 공학을 공부하다 보면
상당 부분의 개념이 산업 공학 특히 생산 공학에
그 기반을 두고 있는 것을 알 수 있다.

그로 인하여, 버전 관리를 포괄하는 다른 용어가 나오는데
"형상 관리 (Configuration Management)"
가 그것이다.


그 중에서 소프트웨어 분야에 대해서는
"소프트웨어 형상 관리 (Software Configuration Management, SCM)"
라고 부르고 있다.



'소프트웨어 형상 관리'는
'버전 관리'를 포함하는 더 크게 포괄하는 의미다.

'소프트웨어 생명 주기 (Software Life Cycle)' 전반에 걸쳐서
개발 환경을 비롯한 전반적인 모든  형상물들에 대한
'변경 관리'를 위한 모든 활동을 의미한다.


형상 식별, 버전 제어, 변경 제어, 형상 감사, 형상 상태 보고 등
어려운 말로 소프트웨어 형상 관리에 대한 정의들이 있긴 하다.



어려운 이야기를 계속 하고자 하는 것은 아니다.

다만, '소프트웨어 형상 관리'라는 것이
곧 '소프트웨어 버전 관리'를 의미하는 것은 아니라는
말을 하고 싶은 것이다.

'소프트웨어 형상 관리'의 범주 안에
'소프트웨어 버전 관리'가 포함이 되어 있을 뿐이다.



문제는 이러한 것을 실무자들도 분명히 알고 있으면서도
아니, 최소한 어렴풋하게 알고 있으면서도
이 두 가지 용어를 그냥 동의어로 사용하고 있다.

또 사실 동의어로 사용해버린다고 하여
꼭 틀렸다고 할 수 없는 것도 사실이다.
( 우기면 뭐 그렇다고 할 수 밖에 없는 것이 현실! )


단순히 소스 코드에 대해서만 관리한다고 하면
"버전 관리"
소스 코드를 비롯하여 개발 환경, 빌드, 기타 등등까지라면
"형상 관리"
라고 지칭하기로 하자.


우리가 앞으로 계속 살펴볼 "Git"은
기본적으로 "버전 관리 도구"이다!


하지만, Git을 기반으로 하여 소프트웨어를 관리하는 시스템을 만든다면
그것은
"소프트웨어 형상 관리 시스템"
이라고 부르기로 하자.


[ 참고 ]
http://ko.wikipedia.org/wiki/%EB%B2%84%EC%A0%84_%EA%B4%80%EB%A6%AC
http://ko.wikipedia.org/wiki/%ED%98%95%EC%83%81_%EA%B4%80%EB%A6%AC
정보통신단체 표준, TTA.IE-828, 소프트웨어 형상 관리 계획 표준
반응형

+ Recent posts