ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [Git] 처음부터 제대로 알아보기
    기타/깃(Git) 2022. 2. 2. 05:02

    오늘은 Git에 대해 정리해보려고 한다.

    Git은 정글에서 공부하면서 자주 썼지만 매일 쓰던 add, commit, push 등 뿐이였고 마지막 최종 프로젝트 할 때에는 git을 잘 다루지 못해서 잘못된 경우가 발생하면 디렉토리를 삭제하고 새로 clone을 한 경우가 종종있었다.

     

    아마 회사에 가면 버전관리시스템으로 git을 쓸 것이고 많은 것들을 새로 접하겠지만 git만큼은 어느정도 쓸 줄 알아야 할 것같아 프로 Git 2판이라는 책을 빌려 읽기 시작했다.

     

    유튜브에 있는 git에 대한 동영상들은 내가 아는 수준인 기본적인 것들만 담고 있어 원리와 조금 더 심화된 내용을 알고 싶어 책을 선정하게 되었다.

     

     

     

    1. Git의 핵심

    1) 데이터를 파일 시스템 스냅샷으로 취급

    더보기

    스냅샷(snapshot)은 과거의 한 때 존재하고 유지시킨 컴퓨터 파일과 디렉터리의 모임

    Git은 커밋하거나 프로젝트의 상태를 저장할 때마다 파일이 존재하는 그 순간을 중요하게 여기고 파일이 달라지지 않았으면 단지 이전 상태의 파일에 대한 링크만 저장한다.

     

     

    2) 거의 모든 명령을 로컬에서 실행

    Git은 거의 모든 명령이 로컬 파일과 데이터만 사용하기 대문에 네트워크에 있는 다른 컴퓨터는 필요 없다.

    프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령을 빠른 시간 내에 실행할 수 있다는 장점을 가지고 있다.

    이러한 장점은 오프라인 상태이거나 VPN으로 연결할 수 없는 상태여도 개발을 할 수 있게 해준다.

     

     

    3) Git의 무결성

    Git은 데이터를 저장하기 전에 체크섬을 구하고 그 체크섬으로 데이터를 관리한다.

    SHA-1 해시를 사용하여 체크섬을 만들고 파일의 내용이나 디렉터리 구조를 이용하여 체크섬을 구한다.

    Git은 모든 것을 해시로 식별하기 때문에 파일을 이름으로 저장하지 않고 해당 파일의 해시로 저장한다.

    (git log를 찍어 commit history를 봤을 때 암호같은 문자들이 해시였나보다...)

     

     

    4) 세 가지 상태

    Git은 파일을 commited, modified, staged 세 가지 상태로 관리한다.

    - commited: 데이터가 로컬 데이터베이스에 안전하게 저장

    - modified: 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 상태

    - staged: 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태

     

     

     

     

    2. 파일의 상태

    Working Directory(프로젝트의 특정 버전을 checkout한 것)의 모든 파일은 Tracked(관리대상)와 Untracked(관리대상아님)으로 나뉜다.

    Tracked 파일은 이미 스냅샷에 포함돼 있던 파일로 Unmodified, Modified, Staged 상태 중 하나이다.

    Untracked 파일은 워킹 디렉터리에 있는 파일 중 스냅샷에도 staging area에도 포함되지 않은 파일이다.

     

    파일의 상태를 확인하는 명령어는 git status이다.

    $ git status
    On branch master
    notihing to commit, working directory clean

    위 내용은 파일을 하나도 수정하지 않았다는 것을 말해주고 현재 작업 중인 브랜치를 알려주며 서버의 같은 브랜치로부터 진행된 작업이 없는 것을 알려준다.

     

    $ git status
    On branch master
    Changes to be committed:
        (use "git reset HEAD <file>..." to unstage)
        new file :
        
    Changes not staged for commit:
        (use "git add <file>..." to update what will be committed)
        (use "git checkout -- <file>..." to discard changes in working directory)
        
        modified:

    changes to be commited에 들어 있는 파일은 staged 상태라는 것을 의미한다.

    changes not staged for commit에 있는 파일은 Tracked 파일이지만 Staged 상태는 아닌 것이다.

     

     

    파일의 어떠한 내용이 변경됐는지를 살펴보려면 git diff 명령어를 사용하면 된다.

    git diff를 실행하면 수정을했지만 아직 staged 상태가 아닌 파일을 비교해볼 수 있다.

    (working directory에 있는 것과 staging area에 있는 것을 비교)

     

    커밋하려고 staging area에 넣은 파일의 변경 부분을 보고 싶으면 git diff --staged 옵션을 사용하면 된다.

    (저장소에 커밋한 것과 staging area에 있는 것을 비교)

    --staged와 같은 기능을 하는 옵션으로 --cached가 있다.

     

     

    커밋 히스토리를 조회하는 데에는 git log 명령어를 사용한다.

    git log를 사용하면 가장 최근 커밋에 대한 정보부터 시간순으로 정보가 제공되고 정보에는 SHA-1 체크섬, 저자 이름, 저자 이메일, 커밋한 날짜, 커밋 메시지가 있다.

    git log 명령어에서는 아래와 같은 옵션을 제공한다.

    -p: 각 커밋의 diff 결과를 보여줌

    --stat: 각 커밋의 통계정보를 조회 (어떤 파일이 수정됐는지, 얼마나 많은 파일이 변경됐는지, 얼마나 많은 라인을 추가하거나 삭제했는지 등)

    --shortstat: --stat 명령의 결과 중에서 수정한 파일, 추가된 라인, 삭제된 라인만 보여줌

    --pretty: 지정한 형식으로 보여주는 옵션으로 oneline, short, full, fuller, format이 있음

    -(n): n은 자연수로 최근 n개의 커밋만 조회

    --since, --after: 명시한 날짜 이후의 커밋만 검색

    --until, --before: 명시한 날짜 이전의 커밋만 검색

    --author: 입력한 저자의 커밋만 보여줌

    --committer: 입력한 커미터의 커밋만 보여줌

    --grep: 커밋 메시지 안의 텍스트를 검색

    -S: 커밋 변경 내용 안의 텍스트를 검색

     

     

    Git에서는 되돌리는 기능을 제공하는데 한 번 되돌리면 복구는 불가능하다.

    완료한 커밋을 수정해야할 때에는 git commit --amend를 사용한다.

    너무 일찍 커밋했거나 어떠한 파일을 빼먹었을 때 혹은 커밋 메시지를 잘못 적었을 때 사용할 수 있다.

     

    staged상태인 파일을 unstaged상태로 바꾸려고 한다면 git reset HEAD <파일명>을 사용하면 된다.

    (add한 파일을 다시 add하기 전으로 돌리고 싶을 때)

     

    git checkout -- <파일명>을 modified상태인 파일을 최근 커된 버전인 unmodified상태로 돌려주는 역할을 하는 명령어이다.

    (원본 파일을 덮어쓰는 명령어이므로 수정한 내용이 전부 사라져도 괜찮을 경우에만 사용하자!!)

     

     

    이외에도 fetch와 pull의 차이, alias를 사용하여 명령어를 나만의 명령어로 만들기를 알 수 있었다.

    남은 부분들을 읽어보고 추가적으로 정리해야겠다.


    [오랜만의 간단한 회고]

    취업 후, java를 공부하며 TIL을 쓰려고 했지만 조금 쉬엄쉬엄 공부하고 싶은 마음이 더 컸다.

    그 동안 못봤던 친구들도 만나고 내 취미 중 하나인 드라마 정주행하기도 하고...

    (엄청 보고 싶었던 '오징어 게임'부터 요즘 핫한 '지금 우리 학교는'까지 하루만에 정주행...)

    그리고 이제 진짜 개발자로서 첫 스타트를 하면 다시 몰입을 즐길 준비를 위해 잠도 많이 자고 싶었다.

    즉, 이렇게 오늘처럼 TIL을 쓰는 것보다 지금까지는 우선순위가 휴식이 더 높았다.

    하지만 개발자 커리어를 시작하고 나서는 TIL을 매일 쓰자는 목표가 있기에 다시 어느 정도 적응을 해야했고 그래서 오늘 다시 키보드를 두들기기 시작했다.

    오랜만이여서 어색했지만 정리하고 싶은 내용들이 많았기에 시간을 투자했다.

     

    이제 첫 출근이 일주일이 채 남지 않았다.

    합격 소식을 전달 받고 약 3주간의 시간이 있었고 최대한 회사에서 사용하는 기술스택을 많이 접해보고 가고 싶었는데 시간이 거의 다 지나고 나니 아쉬운 마음이 조금 있다.

    그래도 이제는 회고를 하며 알았으니 남은 기간동안에는 계획적으로 행동해보자.

     

    Java, dropwizard, dynamoDB, docker, AWS, Test Code, OOP, design pattern, vi editer, CLI 등,,,

    '기타 > 깃(Git)' 카테고리의 다른 글

    [오류 해결] git push 멈춤 현상(무반응)  (1) 2021.07.23

    댓글

Designed by Tistory.