최근 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 맛만 보는 것으로...

 

 

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

git 실수해도 괜찮아요  (0) 2022.07.02
GitHub에서 수식 입력 하기 (with LaTex)  (0) 2022.06.07
Universe 2021 & GitHub Actions  (0) 2022.01.18
github.dev (Web-IDE)  (1) 2021.11.03
git switch/restore (git 새로운 명령어)  (1) 2021.10.17

 

요즘 개발자는 당연하고,

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

 

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

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

 

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

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

 

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

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

 

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

무서워 할 필요가 없다.

 

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

  - https://ohshitgit.com/ko

 

oh shit git

정겹지 않은가?! 

 

 

 

말이 좀 거칠긴 해도,

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

 

 

그런데,

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

 

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

  - https://dangitgit.com/ko

 

dangit

아주 정중하지 않은가?!

 

 

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

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

 

각자의 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 버전을 확인해보자.

$ git --version 
git version 2.17.1

 

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

$ sudo apt remove git

$ sudo apt autoremove

 

 

2. 신규 버전 설치 (PPA)

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

$ sudo add-apt-repository ppa:git-core/ppa

$ sudo apt update

$ sudo apt install git

 

 

3. 신규 버전 설치 (Source)

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

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

$ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev gettext libssl-dev asciidoc xmlto libz-dev docbook2x install-info

$ cd /srv/install/git

$ wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.33.1.tar.gz

$ tar zxvf git-2.33.1.tar.gz

$ cd git-2.33.1

$ make configure

$ ./configure --prefix=/usr/local

$ make all doc info

$ sudo make install install-doc install-html

 

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

    . bash

$ sudo cp ./contrib/completion/git-completion.bash /etc/bash_completion.d/

  . zsh

$ mkdir -p ~/.zsh

$ cp ./contrib/completion/git-completion.bash ~/.zsh/
$ cp ./contrib/completion/git-completion.zsh ~/.zsh/_git

$ nano ~/.zshrc
...
zstyle ':completion:*:*:git:*' script ~/.zsh/git-completion.bash
fpath=(~/.zsh $fpath)

autoload -Uz compinit && compinit
$ source ~/.zshrc

 

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

$ git config --global pager.branch false

 

 

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를 가지고 알아보겠다. (사이즈가 좀 크지만 그래도 ^^)

$ cd /srv/workspace

$ git clone https://github.com/git/git.git

$ cd git/

  - branch 정보를 살펴보자

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/maint
  remotes/origin/master
  remotes/origin/next
  remotes/origin/seen
  remotes/origin/todo

 

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

$ git checkout -b develop                            
새로 만든 'develop' 브랜치로 전환합니다

$ git branch -a          
* develop
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/maint
  remotes/origin/master
  remotes/origin/next
  remotes/origin/seen
  remotes/origin/todo

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

$ git checkout master
'master' 브랜치로 전환합니다
브랜치가 'origin/master'에 맞게 업데이트된 상태입니다.

$ git branch -a      
  develop
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/maint
  remotes/origin/master
  remotes/origin/next
  remotes/origin/seen
  remotes/origin/todo

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

$ nano README.md

$ git status   
현재 브랜치 master
브랜치가 'origin/master'에 맞게 업데이트된 상태입니다.

커밋하도록 정하지 않은 변경 사항:
  (무엇을 커밋할지 바꾸려면 "git add <파일>..."을 사용하십시오)
  (use "git restore <file>..." to discard changes in working directory)
수정함:        README.md

커밋할 변경 사항을 추가하지 않았습니다 ("git add" 및/또는 "git commit -a"를
사용하십시오)

git add README.md

git status
현재 브랜치 master
브랜치가 'origin/master'에 맞게 업데이트된 상태입니다.

커밋할 변경 사항:
  (use "git restore --staged ..." to unstage)
수정함:        README.md

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

$ git reset HEAD README.md
리셋 뒤에 스테이징하지 않은 변경 사항:
M README.md

$ git status
현재 브랜치 master
브랜치가 'origin/master'에 맞게 업데이트된 상태입니다.

커밋하도록 정하지 않은 변경 사항:
  (무엇을 커밋할지 바꾸려면 "git add <파일>..."을 사용하십시오)
  (use "git restore <file>..." to discard changes in working directory)
수정함:        README.md

커밋할 변경 사항을 추가하지 않았습니다 ("git add" 및/또는 "git commit -a"를
사용하십시오)

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

$ git checkout -- README.md 

$ git status               
현재 브랜치 master
브랜치가 'origin/master'에 맞게 업데이트된 상태입니다.

커밋할 사항 없음, 작업 폴더 깨끗함

 

 

 

6. Now (To-be/is)

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

 

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

$ git switch -c develop-2
새로 만든 'develop-2' 브랜치로 전환합니다

$ git branch -a
  develop
* develop-2
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/maint
  remotes/origin/master
  remotes/origin/next
  remotes/origin/seen
  remotes/origin/todo

  - `master` branch로 이동!

$ git switch master
'master' 브랜치로 전환합니다
브랜치가 'origin/master'에 맞게 업데이트된 상태입니다.

$ git branch -a
  develop
  develop-2
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/maint
  remotes/origin/master
  remotes/origin/next
  remotes/origin/seen
  remotes/origin/todo

  - 파일 하나 수정

$ nano README.md

$ git status
현재 브랜치 master
브랜치가 'origin/master'에 맞게 업데이트된 상태입니다.

커밋하도록 정하지 않은 변경 사항:
  (무엇을 커밋할지 바꾸려면 "git add <파일>..."을 사용하십시오)
  (use "git restore <file>..." to discard changes in working directory)
수정함:        README.md

커밋할 변경 사항을 추가하지 않았습니다 ("git add" 및/또는 "git commit -a"를
사용하십시오)

git add README.md

git status
현재 브랜치 master
브랜치가 'origin/master'에 맞게 업데이트된 상태입니다.

커밋할 변경 사항:
  (use "git restore --staged ..." to unstage)
수정함:        README.md

  - 파일을 일단 unstaged 상태로~

$ git restore --staged README.md

$ git status
현재 브랜치 master
브랜치가 'origin/master'에 맞게 업데이트된 상태입니다.

커밋하도록 정하지 않은 변경 사항:
  (무엇을 커밋할지 바꾸려면 "git add <파일>..."을 사용하십시오)
  (use "git restore <file>..." to discard changes in working directory)
수정함:        README.md

커밋할 변경 사항을 추가하지 않았습니다 ("git add" 및/또는 "git commit -a"를
사용하십시오)

  - 파일 원복!

$ git restore README.md

$ git status
현재 브랜치 master
브랜치가 'origin/master'에 맞게 업데이트된 상태입니다.

커밋할 사항 없음, 작업 폴더 깨끗함

 

 

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

 

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

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

 

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

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

 

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

 

 

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

Universe 2021 & GitHub Actions  (0) 2022.01.18
github.dev (Web-IDE)  (1) 2021.11.03
git 설치 (Git 2.33.0, Windows 10)  (0) 2021.10.02
GitHub Copilot 처음 써보기  (0) 2021.07.26
GitHub CLI (GitHub Command line)  (0) 2020.09.20

 

정말 간만에 해보는 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 --version

 

끝~

반응형

'SCM > Git-GitHub' 카테고리의 다른 글

github.dev (Web-IDE)  (1) 2021.11.03
git switch/restore (git 새로운 명령어)  (1) 2021.10.17
GitHub Copilot 처음 써보기  (0) 2021.07.26
GitHub CLI (GitHub Command line)  (0) 2020.09.20
git clone [bare/mirror] 에 대해서 알아보기  (0) 2020.01.01


옛날 옛날 한 옛날에.... 잠시 궁금했던 git clone 옵션들... [ bare / mirror ]


한 번 테스트 해본다고 마음 먹은지 몇 년만에 갑자기 하고 싶다는 의욕이 불끈! ... 은 거짓말이고

회사 업무 中 [ bare / mirror ]  옵션의 차이에 대한 문의가 있었고

이에 대해서 한 번 살펴보고 싶어졌다!!!


0. clone

    - 일단 무조건 clone 해봤다.

$ git clone git@github.com:tensorflow/tensorflow.git ./tensorflow-normal

Cloning into './tensorflow-normal'...

remote: Enumerating objects: 3, done.

remote: Counting objects: 100% (3/3), done.

remote: Compressing objects: 100% (3/3), done.

remote: Total 796000 (delta 0), reused 3 (delta 0), pack-reused 795997

Receiving objects: 100% (796000/796000), 453.08 MiB | 8.29 MiB/s, done.

Resolving deltas: 100% (643770/643770), done.

Checking out files: 100% (19052/19052), done.


$ du -hs ./tensorflow-normal
690M    ./tensorflow-normal


$ git clone --no-checkout git@github.com:tensorflow/tensorflow.git ./tensorflow-no

Cloning into './tensorflow-no'...

remote: Enumerating objects: 3, done.

remote: Counting objects: 100% (3/3), done.

remote: Compressing objects: 100% (3/3), done.

remote: Total 796000 (delta 0), reused 3 (delta 0), pack-reused 795997

Receiving objects: 100% (796000/796000), 453.51 MiB | 8.85 MiB/s, done.

Resolving deltas: 100% (643732/643732), done.


$ du -hs ./tensorflow-no
475M    ./tensorflow-no


$ git clone --bare git@github.com:tensorflow/tensorflow.git ./tensorflow-bare

Cloning into bare repository './tensorflow-bare'...

remote: Enumerating objects: 3, done.

remote: Counting objects: 100% (3/3), done.

remote: Compressing objects: 100% (3/3), done.

remote: Total 796000 (delta 0), reused 3 (delta 0), pack-reused 795997

Receiving objects: 100% (796000/796000), 455.34 MiB | 8.28 MiB/s, done.

Resolving deltas: 100% (643815/643815), done.


$ du -hs ./tensorflow-bare
477M    ./tensorflow-bare


$ git clone --mirror git@github.com:tensorflow/tensorflow.git ./tensorflow-mirror

Cloning into bare repository './tensorflow-mirror'...

remote: Enumerating objects: 1124, done.

remote: Counting objects: 100% (1124/1124), done.

remote: Compressing objects: 100% (1116/1116), done.

remote: Total 1055983 (delta 805), reused 21 (delta 8), pack-reused 1054859

Receiving objects: 100% (1055983/1055983), 1.09 GiB | 8.69 MiB/s, done.

Resolving deltas: 100% (783532/783532), done.


$ du -hs ./tensorflow-mirror
1.2G    ./tensorflow-mirror



1. 정리

    - 위 내용을 표로 정리하면 아래와 같다.


구분 

 normal

 --no-checkout

--bare 

--mirror 

objects 

796,000 

796,000 

796,000 

1,055,983 

Receiving Size 

453.08 MiB 

453.51 MiB 

455.34 MiB 

1.09 GiB 

du Size 

690 M 

475 M 

477 M 

1.2 G 



2. 도식화

    - 위의 상황을 그림으로 설명해보면 아래와 같다.




3. 설명

    - normal

        . 당연히 commit 이력을 모두 담고 있고, 거기에다가 기본 branch로 설정된 소스코드가 working tree에 존재하게 된다.

    - no-checkout

        . commit 이력을 모두 담고 있고, 아직은 working tree에 소스코드를 넣어놓지는 않은 상태다.

    - bare

        . commit 이력만 담고 있다

    - mirror

        . 일반적인 commit 이력뿐만 아니라, 숨어있는(?) 모든 이력들을 담고 있다.


    # 적고나니 이게 뭔 설명인가 싶네.... ^^



4. 차이점 살펴보기

    - normal vs no-checkout

        . HEAD가 가리키는 기본 branch의 latest commit으로 checkout 했냐/안했냐의 차이만 있다.

        . no-checkout으로 clone 한 뒤에 "git checkout -b master"를 하면 결국 똑같다.


    - normal vs bare

        . bare 옵션으로 clone을 하는 것은 개발을 하고자 하는 용도가 아니다. 그러므로 working tree는 없다.

        . normal clone을 했을 때 ".git" 디렉토리 부분만 있는 것이 bare 옵션이기 때문이다.

$ diff ./tensorflow-bare/config ./tensorflow-normal/.git/config

4c4,5

<       bare = true

---

>       bare = false

>       logallrefupdates = true

6a8,11

>       fetch = +refs/heads/*:refs/remotes/origin/*

> [branch "master"]

>       remote = origin

>       merge = refs/heads/master

        . 위의 차이를 보면 알겠지만, bare 옵션으로 clone을 하게 되면 remote를 바라보지 않는다


    - bare vs mirror

        . mirror 옵션은 현재 서버에 기록된(?) 모든 사항을 전부 가져오게 된다.

$ nano ./tensorflow-mirror/packed-refs

# pack-refs with: peeled fully-peeled sorted

4be56f381cd000e91f79209aaf150636db6fb840 refs/heads/0.6.0

...

45e1e4598d3ebab316bf87df9160656f524af36c refs/heads/master

e1c85596366f3133c797f153dac34e01589a231f refs/pull/10000/head

c2d4f5e964503d17107123e51139aa8bbf27c57c refs/pull/10007/head

29d57e0360306de6bc9021eec4b633e96f3549f5 refs/pull/10008/head

ad9e6a95e53a4407db44e0436fc5318522e832cf refs/pull/10011/head

...

        . bare 옵션의 경우에는 "refs/heads/*" 항목만 보이지만,

        . mirror 옵션의 경우에는 "refs/pull/*" 항목도 보인다.

        . GitHub에서 Pull-Request를 할 때 사용되는 commit들이 기록되는 위치가 바로 "refs/pull/*" 이다.



위의 내용에 대해서 잘 생각해보고 용도에 맞춰서 잘 사용하기 바란다~


반응형


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

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


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



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



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

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



0. target


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


$ git clone --bare https://github.com/tensorflow/tensorflow.git


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


$ du -hs ./

455M    ./


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




1. [ git gc --aggressive ]


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


$ time git gc --aggressive

Counting objects: 769698, done.

Compressing objects: 100% (760700/760700), done.

Writing objects: 100% (769698/769698), done.

Total 769698 (delta 636704), reused 111483 (delta 0)

Checking connectivity: 769698, done.


real    41m45.048s

user    28m54.865s

sys     0m3.769s


$ du -hs ./

243M    ./







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


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

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


$ git reflog expire --expire=now --all


$ time git gc --aggressive --prune=now

Counting objects: 769698, done.

Compressing objects: 100% (760700/760700), done.

Writing objects: 100% (769698/769698), done.

Total 769698 (delta 636704), reused 111483 (delta 0)

Checking connectivity: 769698, done.


real    41m17.315s

user    28m51.873s

sys     0m3.522s


$ du -hs ./

243M    ./






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

안전한게 짱이지~!!


조금은 실망~


반응형



최근 회사에서 Credential 내역이 노출되어 보안 위협이 된 사례가 발생을 하였다.


즉, 아이디/패스워드, AWS 토큰 값들을 소스파일 안에 적어놓고

그것을 그대로 commit 하여 push 까지 해버린 것이다.



그래서, 소스코드에 이러한 Credential 정보가 들어있는지 점검하는 것을 강화하였다.

자동으로 분석하도록 한 것이다.



문제는 이러한 Credential 정보가 들어있는 파일을 발견했을 때

개발자들이 어떻게 조치를 취해야하는지에 대한 가이드가 부재하고 있다는...





1. 기본 배경


    - 개발자들이 특정 API 사용을 위한 인증 정보를 파일에 적어놓고 무심코 commit을 했을 경우를 전제 해보자

    - 즉, 아래 그림과 같이 "commit D"에 token 값이 있다는 것을 발견한 것이다!!!



2. 최악의 해결 방법


    - Credential 정보가 발견되었다는 경고를 받은 개발자는 당황한 나머지 아래와 같이 작업을 할 수 있다.


    - 설마! 라고 하지만 정말로 저렇게 할 수 있다 !!!

    - 위와 같이 하면 "commit E"에서는 Credential 정보가 안보이지만, "commit D"로 checkout을 하면 볼 수 있게 되기에 해결책이 아니다 !!!!!




3. 기본적인 해결 방법


    - 실습을 위해 아래와 같이 실제 commit들을 만들어보았다.



    - 마지막 commit인 "2651682"에서 Credential 정보가 발견되었을 경우에 대한 대처법을 알아보자.


$ git clone git@github.com:whatwant/whatwant.git

Cloning into 'whatwant'...

remote: Enumerating objects: 8, done.

remote: Counting objects: 100% (8/8), done.

remote: Compressing objects: 100% (4/4), done.

Receiving objects: 100% (11/11), done.

Resolving deltas: 100% (2/2), done.

remote: Total 11 (delta 2), reused 8 (delta 2), pack-reused 3



$ cd whatwant/



$ git log --oneline

2651682 (HEAD -> master, origin/master, origin/HEAD) write token in no002.txt

a2004f0 add no002.txt

93afc28 add no001.txt

2b73c6e Initial commit



$ git reset --hard HEAD^

HEAD is now at a2004f0 add no002.txt



$ git log --oneline

a2004f0 (HEAD -> master) add no002.txt

93afc28 add no001.txt

2b73c6e Initial commit



$ git push origin master

To github.com:whatwant/whatwant.git

 ! [rejected]        master -> master (non-fast-forward)

error: failed to push some refs to 'git@github.com:whatwant/whatwant.git'

hint: Updates were rejected because the tip of your current branch is behind

hint: its remote counterpart. Integrate the remote changes (e.g.

hint: 'git pull ...') before pushing again.

hint: See the 'Note about fast-forwards' in 'git push --help' for details.



$ git push -f origin master

Total 0 (delta 0), reused 0 (delta 0)

To github.com:whatwant/whatwant.git

 + 2651682...a2004f0 master -> master (forced update)


    - 위와 같이 진행하고 commit 현황을 보면 "2651682" commit이 사라진 것을 볼 수 있다.



    - 아래 그림과 같이 표현할 수 있을 것이다



    - "git reset"은 매우 위험한 명령이기에 그냥 push를 하고자 하면 reject을 당한다! 그래서 "-f" 옵션을 통해 force 실행해야 한다!!!



4. 특정 파일의 이력을 모두 삭제하는 방법


    - 이번 포스팅을 하게 된 이유이다 !!!



    - 위와 같이 commit들이 있다고 해보자. 그림으로 표현하면 아래와 같다.



    - 즉, 예전에 이미 Credential 정보를 넣었는데... 불행하게도 뒤늦게 (이미 commit들이 쌓이고 난 뒤에) Credential 정보를 발견하게 된것이다.

    - 문제가 된 파일과 관련된 모든 이력을 지워보자.


$ git clone git@github.com:whatwant/whatwant.git

Cloning into 'whatwant'...

remote: Enumerating objects: 9, done.

remote: Counting objects: 100% (9/9), done.

remote: Compressing objects: 100% (7/7), done.

Receiving objects: 100% (13/13), done.

Resolving deltas: 100% (3/3), done.

remote: Total 13 (delta 3), reused 7 (delta 1), pack-reused 4



$ cd whatwant/



$ git log --oneline

d81bb67 (HEAD -> master, origin/master, origin/HEAD) add no003.txt

df3c9e0 write token in no002.txt

ea11c2d add no002.txt

83bc6a8 add no001.txt

2b73c6e Initial commit


$ git filter-branch --tree-filter "rm -f no002.txt" HEAD

Rewrite d81bb67affec459cd3e25fa57b98cf64a1bf05be (3/5) (1 seconds passed, remaining 0 predicted)

Ref 'refs/heads/master' was rewritten



$ ls -al

total 9

drwxr-xr-x 1 chani 197121  0 11월  9 20:41 ./

drwxr-xr-x 1 chani 197121  0 11월  9 20:40 ../

drwxr-xr-x 1 chani 197121  0 11월  9 20:41 .git/

-rw-r--r-- 1 chani 197121  0 11월  9 20:40 no001.txt

-rw-r--r-- 1 chani 197121  0 11월  9 20:40 no003.txt

-rw-r--r-- 1 chani 197121 10 11월  9 20:40 README.md



$ git log --oneline

69c84e3 (HEAD -> master) add no003.txt

94413d9 write token in no002.txt

1a2d568 add no002.txt

83bc6a8 add no001.txt

2b73c6e Initial commit



$ git push origin master

To github.com:whatwant/whatwant.git

 ! [rejected]        master -> master (non-fast-forward)

error: failed to push some refs to 'git@github.com:whatwant/whatwant.git'

hint: Updates were rejected because the tip of your current branch is behind

hint: its remote counterpart. Integrate the remote changes (e.g.

hint: 'git pull ...') before pushing again.

hint: See the 'Note about fast-forwards' in 'git push --help' for details.



$ git push -f origin master

Counting objects: 4, done.

Delta compression using up to 4 threads.

Compressing objects: 100% (4/4), done.

Writing objects: 100% (4/4), 515 bytes | 515.00 KiB/s, done.

Total 4 (delta 1), reused 0 (delta 0)

remote: Resolving deltas: 100% (1/1), done.

To github.com:whatwant/whatwant.git

 + d81bb67...69c84e3 master -> master (forced update)


    - 실제 commit이 어떻게 되어있는지 확인해 보자.



    - 무엇이 바뀌었는지 그림으로 확인해 보자.



    - 위의 방법은 문제가 발생한 파일과 관련한 내용을 전체 히스토리에서 삭제를 하는 것이다.

      → 그렇기 때문에, 영향을 받은 commit을 보면 앞의 commit 까지 포함이 된다.





※ 주의사항


    - 문제가 발생한 정확한 위치를 찾기가 어렵기 때문에 문제가 발생한 파일을 전체 history에서 삭제를 해버리는 방식이다.

      → 해당 파일에 Credential 정보 외의 내역도 있고 이에 대한 내용도 중요하다고 하면 문제가 있을 수 있는 방법이라는 말이다.


    - 그리고, 기존 commit ID 값도 변경이 된다.

      → commit ID 이력을 관리하고 있는 상황인 경우 문제가 있을 수 있다는 말이다.




이러한 번거로움을 피하기 위해서는 애초에 Credential 정보를 파일안에 기재하는 일이 없어야 하겠다.



반응형


회사에서 repo를 사용해야할 개발팀이 Windows 환경에서 개발을 한단다. 이런...

Windows는 테스트 환경도 마땅치 않은데...


그나마 다행인 것은 친절하게도 Windows 환경에서

repo를 사용할 수 있도록 노력을 해주는 사람들이 이미 있다는 것이다 ~ !!! 쌩유 !!!


    ▷ https://github.com/esrlabs/git-repo


이하 내용은 MS Windows 7 64bit 환경에서 테스트 되었다.



1. Precondition


    ① git

        - 여러 종류의 SW가 존재하지만, 표준 제품(?)으로 설치하자 !!!

        ▷ https://git-scm.com/download/

        - 설치는 기본 설정값으로 진행하되 아래 부분은 조금만 신경쓰자





        - 특히 아래와 같이 Enable symbolic links 항목을 꼭 체크하자



    ② Python

        - repo는 python으로 작성된 스크립트이므로, 당연하게도 python이 설치되어 있어야 한다

        ▷ https://www.python.org/downloads/

        - Python 3에서도 실행이 되지만, 아직은 호환성을 고려했을 때 2.7 버전으로 설치하자


        - 가능한 기본 설정값으로 설치를 진행하자



2. Install


    ▷ Ubuntu 환경에서와 마찬가지로 2가지 방법으로 설치 진행할 수 있다.


    (방법 1) curl

        - 평범한(?) 방법이다~


$ cd ~

$ mkdir ./bin

$ curl https://raw.githubusercontent.com/esrlabs/git-repo/stable/repo > ./bin/repo

$ curl https://raw.githubusercontent.com/esrlabs/git-repo/stable/repo.cmd > ./bin/repo.cmd

$ export PATH=$PATH:~/bin


    (방법 2) git clone

        - git으로 존재하는 배포판인데, git clone을 해야지.... ^^


$ cd ~

$ git clone https://github.com/esrlabs/git-repo.git

$ cd ./git-repo

$ git checkout -b stable origin/stable

$ export PATH=$PATH:~/git-repo


    (공통) PATH

        - 영구적으로 실행 경로를 등록하기 위해서 아래와 같이 해보자


$ cd ~

$ nano ./.bashrc


        - 각자 필요한 경로로 작성하면 된다


export PATH=$PATH:~/bin

export PATH=$PATH:~/git-repo



3. How to #1


    □ precondition

        - git을 사용하기 위한 사용자 정보 입력과 작업 공간(directory)를 만들고 시작하자 (기본 경로는 필자 개인 취향이다)


$ cd /srv/workspace

$ mkdir ./whatwant

$ cd ./whatwant


$ git config --global user.name "whatwant"

$ git config --global user.email "whatwant@gmail.com"


    ① init

        - 작업 공간(directory)을 작업하기 위한 상태로 만드는 과정이다


$ repo init -u https://github.com/whatwant-school/manifest --no-clone-bundle


    ② sync

        - 실제 사용할 repository를 가져오는 과정이다


$ repo sync --no-clone-bundle




반응형

+ Recent posts