분류 전체보기

반응형

    [git] local, global config 파일의 구성과 조작

    git config 파일의 위치 global config 파일의 위치 git의 global config 파일은 ~/.gitconfig 에 있다. git의 local config 파일의 위치 git의 local config 파일은 .git/config 에 있다. git config 파일의 구성 git config 파일은 두가지 계층으로 이루어져 있다. [ ] 으로 감싸진 카테고리와 = 왼쪽에 있는 파라미터와 오른쪽에 있는 파라미터에 대응되는 값이다. 예를 들어 아래에는 core 카테고리 안에 repositoryformatversion, filemode, bare, logallrefupdates, ignorecase, precomposeunicode 파라미터가 있다. git은 조작 명령이 들어올 때 이 co..

    [Git] reflog를 활용한 삭제된 브랜치 복구 방법

    reflog란? reflog란 git에서 가리키는 referenced commit이 변경된 내역이다. reflog를 기록하는 것은 대표적으로 HEAD와 branch 두가지이다. HEAD의 reflog HEAD의 reflog 경우 새로운 커밋이 생기거나, branch가 switch 될 때마다 해당 브랜치의 가장 최신 커밋으로 reference가 바뀌게 된다. 예를 들어 master 브랜치에 test, test2란 커밋을 만들고, feature-branch 브랜치를 새로 만든다음 feature-branch에서 new commit 커밋을 새로 만들면 다음과 같이 reflog가 쌓이게 된다. $ git reflog show HEAD d42e22f (HEAD -> feature-branch) HEAD@{0}: c..

    [Git] Git의 저장 단위인 commit의 동작 원리에 대해 알아보자

    Git의 기본 저장 단위 Commit Commit은 Git의 기본 저장 단위이다. 우리는 Commit을 파일들에 대한 스냅샷이라고도 부르며, Commit은 Commit을 찍은 시간의 파일들의 상태에 대해 저장한다. Commit은은 tree, parent, author, commiter,message 5가지 구성요소로 이루어져 있다. tree : tree와 blob를 포인팅하는 구성요소이다. parent : 해당 커밋 직전에 어떤 커밋이 있었는지 포인팅한다. author : 작성자. commiter : 커밋을 만든 사람. message : 커밋을 설명하는 메세지. 예를 들어 commit이 두 개 찍힌 다음과 같은 로그를 가진 Git 폴더가 있다고 해보자 $ git log --oneline 6e3a608 ..

    [Git] Git은 어떻게 파일을 저장하고 복구하는가? git의 기본 파일 단위인 blob와 Hashing의 관계에 대해 알아보자

    변경사항을 압축해 저장하는 objects 폴더 objects 폴더 내부를 보면 두 글자 이름을 가진 폴더들이 있다. objects 폴더는 git의 모든 변경사항을 압축해서 파일들을 각 폴더 내부에 저장한다. 이 내부에는 commit, tree, blob, annotated tag들이 저장되며, git을 통해 히스토리를 확인할 수 있는 것은 바로 이 폴더 내부에 모든 스냅샷들이 저장되기 때문이다. 저장되는 방식은 hash에 해당하는 압축된 변경사항으로 저장된다. 예를 들어 위 폴더 중 02에는 7f7aa 로 시작하는 파일명인 파일이 있다. 이 파일은 Git의 저장의 기본 단위인 blob로, blob 파일 내부에는 027f7aa 해시값에 대한 변경사항이 압축되어 있다. 깃에서는 blob 파일의 압축을 풀어 ..

    [Git] .git 폴더 내부의 refs 폴더에 대해 알아보자

    HEAD, tag들의 커밋 해시값을 저장하는 refs 폴더 앞서 git의 HEAD와 tag에 대해 보았다. 이 값들은 특정 커밋들을 가리키는 포인터들로 특정 커밋의 해시 값을 가리킨다. 이 해시 값들을 저장하는 위치가 바로 refs폴더이다. 따라서 refs 폴더 내부를 보면 다음과 같이 출력된다. $ ls .git/refs heads stash tags refs 폴더 내부에는 heads 폴더와 tags 폴더가 있다. 이 중 heads 폴더 내부에는 브랜치별로 파일이 존재한다. 이 파일들 각각 내부에는 해시값이 저장되어 있다. $ ls .git/refs/heads feature-layout feature-view main 실제로 뜯어보면 다음과 같이 나오며 이 값은 main 브랜치의 HEAD 커밋 해시값..

    [Git] git config 는 어떻게 동작하는가?

    .git 폴더의 config 파일 .git 폴더의 config 파일은 git repository에 대한 설정값을 저장해놓는 파일이다. git은 config 파일을 읽어 설정값들을 사용하며, 유저들의 조회 요청이 있을 경우 출력해준다. config 파일의 역할은 다양한데 user name, email 을 설정하는 것에서부터 remote repository에 대한 정보 또한 저장한다. 추가적으로 color scheme 을 적용해 git 명령어에 대한 가독성을 높일 수도 있다. 이 글에서는 간단히 이해하기 위해 git을 사용하는 모든 사람들이 익숙한 user name과 email을 설정하고 .git/config 파일을 통해 조회하는 방법과 remote 정보를 추가하고 확인하는 방법에 대해 다룬다. User n..

    [Git] Tag를 활용한 Git Version 만들기 : git tag 추가, 삭제, 검색, 푸시 한 번에 정리하기

    Git Tag란? Git Tag란 버저닝을 위해 사용하는 포인터이다. HEAD가 특정 커밋 해시를 가리키는 것 같이 Git Tag 또한 특정 커밋 해시를 가리킨다. *만약 HEAD에 대해 익숙하지 않으면 아래 글을 살펴보자. [Git] .git 내부에서 HEAD를 인식하는 방법 .git 내부에서 HEAD를 인식하는 방법 .git 내부에는 HEAD파일이 있다. 이 파일은 HEAD를 인식하기 위한 메타 데이터를 저장하는 파일이다. 작업 중인 브랜치에 따라 변하는 HEAD파일 HEAD 파일은 현재 kotlinworld.com 이번 글에서는 다음의 순서로 Git Tag에 대해 다룰 것이다. Git Tag 만들기 Git Tag 목록 조회하기 Git Tag 필터링하기 Git Tag간 차이 확인하기 Git Tag로 ..

    [Git] interactive rebase 사용해 이전에 생성된 커밋 조작하기 : commit 메세지 수정, commit 삭제, commit 합치기

    interactive rebase 사용해 이전 커밋 조작하기 앞선글에서 git rebase를 이용해 rebase 대상 브랜치의 commit history를 새로 만드는 것을 살펴보았다. commit history를 새로 만들 수 있다는 것은 현재 시점 이전에 생긴 커밋들을 조작할 수 있다는 것이다. git rebase는 interaction 모드인 -i 옵션을 이용해 커밋 히스토리를 합칠 수 있는 기능을 제공한다. git을 사용하다 보면 이전 커밋들을 합치고 싶은 경우가 생기는데, 그 때 이 기능을 사용하면 된다. git rebase -i 를 사용해 커밋 메세지를 수정하기 위해서는 다음 명령어를 사용하면 된다. HEAD~n 은 HEAD 커밋으로부터 n 번째 까지의 커밋을 수정한다는 뜻이다. git reb..

    [Git] git rebase 사용해 git commit history 다시 작성하기. 언제 git merge 또는 git rebase를 사용해야 하는가?

    Git Merge와 Git Rebase의 차이 git merge와 rebase는 모두 두 브랜치를 합치기 위한 명령어이다. 우리는 이곳에서 이 두 브랜치를 기준 브랜치와 대상 브랜치로 나눈다. 기준 브랜치는 master과 같이 기준이 되는 브랜치이고, 대상 브랜치는 feature 브랜치들과 같이 master에 합쳐져야 하는 브랜치이다. git merge와 git rebase가 다른 점은 두 브랜치의 커밋들을 합치기 위해 어떤 전략을 취하는지이다. 만약 기준 브랜치를 대상 브랜치에 merge한다고 하면(feature 브랜치에 master 브랜치를 merge), git merge는 기본적으로 merge를 하기 위해 대상 브랜치를 그대로 두고 기준 브랜치의 변경 사항(커밋)을 대상 브랜치에 얹으면서 합친다. ..

    [GitHub] Branch Protection Rule 적용해 브랜치 보호하기

    Branch를 보호하는 것이 중요한 이유 협업을 할 때 Rule이 없으면 각자 자신의 방식으로 일을 하게 되기 때문에 뒤죽박죽이 된다. 만약 인원이 적다면 별 문제가 되지 않지만, 실무에서는 적게는 3명 많게는 수십 수백명이 하나의 저장소를 관리하기 때문에 저장소를 관리하기 위한 Rule이 중요하다. 특히 Git의 Branch는 협업을 위한 기본 토대이기 때문에 최소한의 규칙을 정해야 협업 시의 혼란을 방지할 수 있다. GitHub의 Branch Protection Rules GitHub에서는 GitHub에 올라간 Branch들에 대한 Rule을 지정할 수 있게 해준다. 이 Rule을 이용하면 특정 브랜치가 실수로 지워지는 것을 방지하거나 PR(Pull Request)가 아닌 다른 방식으로 커밋을 추가하..

반응형