git 로컬과 원격저장소 업데이트, 떙겨오는방식 (방식?)
git lab은 뭐지 (
브랜치 업데이트방식등등
commit 되돌리기? 브랜치 merge
pull request
_____________________________________________________
Git은 분산형 버전관리 시스템으로팀으로 작업을 할때 서로 소스코드를 주고 받을필요도 없이
여러명이 브랜치를 나눠서 동시에 작업하는 병렬 개발이 가능하다
분산 개발을 한뒤, 브랜치를 간단하게 병합(merge)할 수 있다.
헷갈리는 용어정리 (Repository와 Branch 용어 구분하기)
HEAD: 현재 활성화한 브랜치의 마지막 commit
origin: origin이라는 이름의 원격저장소이다. 우리가 repo를 만들면 생성되는 위치이고 github의 repository를 들어가면 보이는 repo들이 다 origin이다. 내 컴퓨터가 local이고 그걸 git으로 저장해둔 내 컴퓨터밖 저장소가 원격저장소(origin)
git remote -v이 명령어를 쳐보면 알수 있다.
origin 뒤에 github 링크가 바로 origin의 주소다
origin/master: origin 원격저장소의 master 브랜치라는 뜻 보통 repo를 처음만들면 초기 원격저장소이름은 origin으로 초기 상태 브랜치는 master라는 이름으로 만들어 진다.
origin/HEAD: origin 원격저장소에 현재 코드상태를 의미한다 (local에서 한 마지막 push 반영상태)
HEAD->master:
HEAD-> 로컬저장소의 현재 상태가
master 로컬저장소의 master브랜치와 상태가 같다.
Master와 main의차이
사실 똑같다
그냥 git에서는 master란 이름을 그대로 쓰는데
github에서 master 라는 어감.. 뭔가 (slave가 연상되기도 하고) 뉘앙스가 좀 그렇다 하면서 main으로 바꿔버림
그래서 로컬은 master인데 github(원격)은 main브랜치라는 이름으로 운영되는것이다.
같은 의미에 실제로 같은브랜치인데 헷갈릴수도 있으니
프로젝트 시작시 한쪽으로 이름을 통일하는게 좋다.
나는 main쪽이 의미랑 더 맞는다 생각해서
main으로 통일한다
git repo 처음생성부터 첫커밋에 main으로 변경하기
git init
git branch -m main
git remote add origin "github.com/repoName.git"
git add .
git commit -m "first commit"
git push -u origin main
- working directory:소스코드 수정 등의 작업
git add: staging area
git commit local repository: .git폴더에 저장
git push remote repository: github - 다른 사람의 작업물 내 컴퓨터에 다운받기 : git fetch + git merge
- git fetch와 gir merge를 한 번에 사용하는 명령어 : git pull
- git fetch와 gir merge를 한 번에 사용하는 명령어 : git pull
Git Lab이란
GitLab은 깃 저장소 및 CI/CD, 이슈 추적, 보안성 테스트 등의 기능을 갖춘 웹 기반의 데브옵스 플랫폼으로 개인 또는 조직이 Git repository 의 내부 관리를 제공하는데 상용할 수 있는 Github 으로 즉 비공개된 Github라고 할 수 있다.
무료티어 버전에서도 보안쪽 기능을 제외하곤 사용가능하니 나중에 사용해 봐야겠다
Git add / commit 내부원리
Git은 작업중인 파일의 변경사항을 인식하고 이를 간단하게 add, commit 해준다.
또한 원격저장소와의 다른점을 git status나 git diff로 비교할 수 있는데
과연 어떠한 원리로 파일의 다른점을 비교하고 분류하는걸까?
모든 파일을 비교한다면 물론 정확하겠지만.
프로젝트 크기가 엄청 큰 몇십만, 몇백만줄의 코드가 있는 프로젝트에선 그것도 쉽지 않을것이다.
그래서 Git은 프로젝트의 메타데이터를 Git Directory에 저장한다.
(해당위치엔 메타데이터 외에도 객체 데이터베이스가 저장됨)
메타 데이터 내부에는 파일을 식별하는데 가장 중요한 해시 값이 들어있다.
파일 자체를 SHA-256 방식으로 해시값을 생성해 메타데이터에 저장하고
값이 조금이라도 바뀌면 해시값이 아예 바뀌는 특성을 사용해 파일의 변경을 감지
파일이 아무리 크고 코드가 길어도 해시값은 짧고 간결해서
파일 변경사항을 스캔하는데 많은 자원을 소모하지 않음
그 외에도 사용자이름, 이메일, origin URL, 브랜치설정 등 Git 동작 방식을 제어하는 설정 값이나
Git의 구조와 흐름 정보가 담겨있는 브랜치, 태그, origin 등의 포인터 정보들
브랜치 이동, 체크아웃등의 이력 정보, 시간 정보, 이전/ 새로운 commit 해시값이 담겨있는 로그 정보나
파일 경로, 권한, 크기, 수정시간 등 Working directory의 상태를 빠르게 파악하기위한 캐시정보
Staging Area에 추가된 파일 목록, 각 파일의 모드, 해당 파일의 객체 저장소 내 해시 값등이 담겨있는 인덱스 정보 등
Git을 구성하고 사용하기 위한 모든 정보들이 담겨있다.
그럼 메타데이터만 믿어도 되나?
물론 이런 메타데이터가 변경사항들을 빠르게 감지하는데는 도움이 되지만
코드가 너무 길고 방대해지면 이 마저도 너무 느려지게 될 수 있다.
그럴땐 얕은 복제(Shallow Clone)을 하는걸 추천한다.
얕은 복제란? (Shallow Clone)
엄청나게 큰 데이터를 Clone하거나 pull, push등 Git 작업을 하는데는
전송할 데이터가 너무 많아서 오래걸리거나, 심지어 실패 할때도 있다
해당 프로젝트의 history가 전부 필요한게 아니라면 Shallow Clone을 사용해
얕은 깊이로 clone 해오면 된다
예를들어
git clone --depth=1 [REPO_URL]
이란 명령으로 1이라는 깊이 (얕음)으로 데이터를 당겨온다면
제일 최근의 단 1개의 커밋 이력만을 가져온다
테스트로 tensorflow라는 커다란 프로젝트를 가져올때 그냥 clone해온다면 몇분 이상이 걸리지만
git clone --depth=1 git@github.com:tensorflow/tensorflow.git tensorflow-shallow
깊이를 1로 지정하고 가져온다면 몇 초 내로 받아올 수 있습니다.
만약 그 이상의 깊이가 필요하다면
처음에 --depth= 10
그 다음에 --depth = 30
다음에 --depth = 50 이런식으로 깊이를 점점 늘려가면서 clone을 하면 됩니다.
Git Sparse Checkout
git checkout은 그 커밋의 모든 상태를 내가 작업중인 working Directory로 가져오지만
git sparse checkout을 사용하면
내가 원하는 파일과 폴더만 내 working Directory로 가져와 작업할 수 있습니다.
Sparse Checkout은 Git 1.70 버전부터 사용가능하며 Git 2.25.0 버전부터는 사용방법이 달라집니다.
[Git 2.25 기준]
$ git sparse-checkout init
$ git sparse-checkout set "원하는 폴더경로" //.git/info/sparse-checkout 파일에 기록하는 기능
$ git sparse-checkout list
$ git remote add origin [Repo url]
$ git pull origin master
하고 pull 이력을 보면 원하는 파일, 폴더만 pull 한걸 확인할 수 있다.
이 외에는 프로젝트의 큰 파일들을
git LFS로 저장하는게 좋다.
다른 저장소에 저장하고 저장소를 가르키는 포인터를 프로젝트에 저장하는 방식
(관련 글: https://akku-dev.tistory.com/59)
'기타' 카테고리의 다른 글
| 공부 해야할것 메모장 (0) | 2025.04.08 |
|---|
