어느날 git 의 레포지토리의 파일이 모두 changed 상태로 보여 당황했다. 한 파일을 diff 로 보니 줄의 마지막에 ^M 이 보였다. 에디터가 OS에 따라서 LF 를 CRLF 로 바꿔서 보여주는 것이었다.

CRLF 상황

Linux 를 20.04 LTS 를 사용하다 os-release-upgrade 를 사용해서 22.04 LTS 로 업그레이드 했다.

그리고 한동안 다른 작업을 하다 소스를 다루게 되어서 윈도우 11에서 VS code 로 WSL의 우분투 폴더를 열어 보니 git 의 staging area 에 커밋할 파일이 엄청 들어와 있는 것이다. 찾다 보니 아래 그림 같이 줄바꿈 코드로 CRLR 로 인식을 한 것이다.

소스 파일을 수정할 일이 아니라서 검색을 좀 해보니 git 의 전역 설정에서 가능할 것 같았다. 다음 링크를 참조했다.

1. https://stackoverflow.com/questions/28076760/git-add-adds-m-to-the-end-of-every-line
2. https://github.com/Microsoft/WSL/issues/2318

git 전역 설정으로 autocrlf 를 활성화 한다. git 전역 설정에 다음 같이 autocrlf 를 true 지정하면 해결이 된다.

1

$ git config --global core.autocrlf true

Swallow Clone 은 git 저장소에 커밋된 기록중 일부만 사용하는 기술 있다. 그런데 브랜치를 추가하면 원격지와 클론한 저장소에서 탐색이 안되는 단점이 있다. 여기서 swallow clone 에서 branch를 사용하는 방법을 요약한다.

Swallow Clone 에서 branch를 사용하자.

기본적으로 swallow clone 을 사용하면 원격 저장소의 branch 를 모두 볼 수 없다. 이것은 .git/config 를 보면 refs/remotes/origin/master 로 구성되어 있어서이다. 그래서 swallow clone 한 저장소는 원격 저장소의 master 브랜치만 보게 된다.

다음은 .git/config 의 일부이다.

1
2
3

[remote "origin"]
        url = git@github.com:repository/YOUR_REPO.git
        fetch = +refs/heads/*:refs/remotes/origin/master

master 브랜치 대신 브랜치 트리 모두를 보려면 아래 같은 단계로 처리해 준다.

1. 다음 같이 원격 저장소의 모든 브랜치를 대상으로 처리해 준다.

1

git remote set-branches origin '*'

origin 의 브랜치를 master에서 * 로 지정하면 .git/config가 아래 같이 수정된다.

1
2
3

[remote "origin"]
        url = git@github.com:repository/YOUR_REPO.git
        fetch = +refs/heads/*:refs/remotes/origin/*

2. 이어서 원격 레포지토리를 업데이트 하면 관련한 브랜치 정보를 갱신한다.

1
2
3
4
5
6
7
8
9
10
11

$ git remote update
Fetching origin
remote: Enumerating objects: 306, done.
remote: Counting objects: 100% (306/306), done.
remote: Compressing objects: 100% (283/283), done.
remote: Total 285 (delta 161), reused 6 (delta 0), pack-reused 0
Receiving objects: 100% (285/285), 8.59 MiB | 4.35 MiB/s, done.
Resolving deltas: 100% (161/161), completed with 16 local objects.
From git@github.com:repository/YOUR_REPO.git
 * [new branch]      1024_dev   -> origin/1024_dev
 * [new branch]      gt_master  -> origin/gt_master

3. 업데이트 한 후에 원격 브랜치만 검색해도 잘 나타난다.

1
2
3
4
5

$ git branch -r
  origin/1024_dev
  origin/HEAD -> origin/master
  origin/gt_master
  origin/master

4. 원격지 브랜치를 체크아웃해서 사용하면 된다.

1

$ git checkout -b t origin/1024_dev

함께 보면 유용한 git 명령

간단하게 빌드/테스트 를 하기위함 이라면 `Sparse-checkout`` 과 함께 이용하면 좋다.

1. [git] Sparse Checkout
2. Swallow Clone

shallow clone 은 git저장소의 일부 이력만 받아오는 방법이다. 즉 git 커밋등의 이력이 많아지고, 저장소 용량이 커지면 clone을 받는데, 시간도 많이 걸리고 저장소 크기도 용량이 커져서 clone, push, pull 시 시간 손해가 있을 수 있고, 어떤 경우 중단되는 경우도 있을 수 있다.

그래서 git저장소의 일부 이력만 선택적으로 받아 올 수 있다.

1. 보통 swallow clone 은 저장소를 build & deployment 를 수행 할 때 유용하다.
2. 저장소 소스를 수정하고 push 하는 경우에는 불리하다.

swallow clone

swallow clone을 위해서 git clone에 depth 인자에 주어진 개수만큼의 history 를 가져온다.

1

git clone [repo_url] --depth [개수]

최종 commit 부분만 swallow clone 하기

최종 history (git commit log) 만을 대상으로 clone 한다면 depth 1 로 주면 된다.

1

git clone --depth 1 abcd@git.com/abc/big_repository

git log를 보면 1개의 로그만 나타납니다. 기록이 하나밖에 안남는다.

1

git log 

100개의 기록 더가져오기

swallow clone한 저장소에서 fetch 를 사용해서 추가적인 log 기록을 더 가져올 수 있다.

1
2

git fetch --depth 50
git fetch --depth 50

주의!!!

현재 개발된 코드를 확인하고, 빌드하고 그리고 실행하고 테스트하는데는 shallow clone은 가볍게 수행할 수 있는 장점이 있다. 그런데 . 저장소에서 소스를 수정하고 push 하려고 하려면 저장소의 모든 Git 이력을 이용해 이 수정된 내용이 적용되야 한다. 그런데 swallow clone 상태에서는 어떤 기록에서 편집되었는지에 대한 것을 확인할 수 없어서 push가 거부될 수 있다.

이런 경우에는 unswallow 를 통해서 모든 history 를 복구한 후에 작업을 수행해야 한다.

unswallow 하기

기존 –depth 로 swallow clone 이 된 레포지토레애서 Un-swallow 를 하기 위해서 fetch 명령을 이용한다.

1

$ git fetch --unshallow # 저장소의 남은 history 를 읽어온다

함께 보면 유용한 git 명령

간단하게 빌드/테스트 를 하기위함 이라면 `Sparse-checkout`` 과 함께 이용하면 좋다.

[git] Sparse Checkout

- 참고

• swallow clone 하기
• Git clone –depth=1 이후에 히스토리 복원하기.

git checkout 은 보통 브랜치의 모든 구조를 가져온다. checkout 은 다음 링크 설명을 보고 이해해 보자,

• visual-git-guide:checkout

Sparse checkout 은 checkout 전체 대상중 일부 만을 checkout 할 수 있다.

git sparse checkout 기능은 Git 2.25.0 이상부터 사용이 가능하다.

Sparse checkout 이해

git 블로그 글 Bring your monorepo down to size with sparse-checkout 의 그림 설명을 빌려오자.

다음 원격 레포지토리가 있다고 가정하자

전체 디렉토리 중에서 client/android 부분만 checkout 을 하고 싶다.

다음 같이 클론을 하고 sparse-checkout 을 초기화 한 후에 대상인 client/android 디렉토리를 sparse-checkout 하면 해당 디렉토리만 다운로드한다.

1
2
3
4

git clone https://github.com/tensorflow/examples.git
cd examples
git sparse-checkout init --cone
git sparse-checkout set client/android

sparse-checkout 을 수행하면 해당 디렉토리 컨텐츠만 남게 된다.

사용 방법

사용시 몇가지 사례가 있다.

방법1

첫번째 방법으로 git 레포지토리를 pull로 clone 한 후에 sparse-checkout 대상 파일/폴더를 지정하고 sparse-checkout 을 수행한다.

1

git clone https://github.com/tensorflow/examples.git

spase-checkout 을 수행하기 위해서 초기화 하고 대상이 되는 파일/폴더를 지정한다.

1
2
3
4

cd examples
git config core.sparseCheckout true
git sparse-checkout set lite/examples/object_detection/android_play_services
git pull origin master

희소 체크아웃을 사용하도록 git 인스턴스를 구성하면 지정한 파일/폴더만 남게 된다.

저장소에서 config core.sparseCheckout true 대신 git sparse-checkout init --cone 를 이용해도 된다.

방법2

레포지토리를 클론하지 않고 클라이언트에서 초기화 후 sparse-checkout 으로 대상 디렉토리를 지정한 후에 pull 을 수행한다.

원격 레포지토리를 지정한다.

1
2
3
4

mkdir <repo>
cd <repo>
git init
git remote add -f origin <url>

spase-checkout 을 수행하기 위해서 초기화 하고 대상이 되는 파일/폴더를 set 으로 지정한다. 여러 파일/디렉토리를 추가할 수 있다.

1
2

git config core.sparseCheckout true
git sparse-checkout set lite/examples/object_detection/android

pull 을 수행한다.

1
2
3
4

git pull origin master
From https://github.com/tensorflow/examples
 * branch              master     -> FETCH_HEAD
Updating files: 100% (61/61), done.

저장소에서 config core.sparseCheckout true 대신 git sparse-checkout init --cone 를 이용해도 된다.

방법3

방법2와 동일하지만 설정 파일을 통해서 수행하는 점만 다르다.

1
2
3
4

mkdir <repo>
cd <repo>
git init
git remote add -f origin <url>

원격 레포지토리를 지정하고 git 설정에 추가한다.

1

git config core.sparseCheckout true

checkout 하려는 파일과 폴더를 sparse-checkout 파일에 추가한다. 여러 파일/디렉토리를 추가할 수 있다.

1
2

echo "lite/examples/object_detection/android" >> .git/info/sparse-checkout
echo "lite/examples/bert_qa/android" >> .git/info/sparse-checkout

pull 을 수행한다.

1

git pull origin master

함께 보면 유용한 git 명령

간단하게 빌드/테스트 를 하기위해 저장소의 특정 폴더만 clone 할 때 Swallow Clone 을 함께 이용해도 좋을 것 이다.

[git] Swallow clone

- 참고

• visual-git-guide: checkout
• Bring your monorepo down to size with sparse-checkout
• git-sparse-checkout
• git 사용, qkboo
• git 입문
• git 발전

프로젝트를 위해서 레포지토리에 새 참여자를 추가하고, 브랜치를 생성해서 관리하는 과정.

참여자 관리

레포지토리 Settings 에서 Collaborators 페이지에서 참여자를 관리할 수 있다.

Collaborator 에 추가할 github 사용자를 검색

Collaborators 추가 사용자 목록

사용자는 알림에 Collaborator 에 추가되어 허용할지를 등록

요청받은 collaborator 을 받아들인다

Collaborator 사용자가 새로운 파일을 추가한다.

<img src=’https://i.imgur.com/2i1UOyD.png>

레포지토리 브랜치의 새로운 변경/추가/삭제가 발생하면 Pull request 를 요청해야 한다.

Collaborator로 참가한 사용자는 pull request 하고 merge도 할 수 있지만 정책으로 main 관리자가 하도록 하자.

새 브랜치 사용

pull request 와 merge 를 위한 정책 구성. Collaborator도 merge 할 수 있지만 팀장/관리자가 merge 하도록 정책을 정한다.

Pull request 와 merge

새 브랜치를 생성한다

새 브랜치에서 작업을 수행한다.

새 브랜치에 변경된 내용을 pull request 할 수 있다.

새 브랜치에 변경된 내용을 pull request 할 수 있다.

사용자/관리자는 새 브랜치에 변경된 내용을 pull request 할 수 있다.

관리자/팀장은 새 브랜치에 변경된 내용을 merge 한다.

관리자/팀장은 새 브랜치에 변경된 내용을 merge 한다.

관리자/팀장은 사용한 브랜치는 제거해 레포지토리를 정리한다.