[Git] 기초학습

Git Workflow

• working directory
  • 사용자의 작업공간으로써, 로컬 저장소에 접근가능하며 실제 파일을 수정/생성하는 공간
  • 작업폴더 내 .git을 제외한 나머지 부분
  • 파일들을 tracked/untracted 상태로 구분
• staging area
  • working directory에서 제출된 tracked 상태의 파일을 관리/임시저장하는 공간
  • 파일의 내용을 직접 가지고 있는게 아니라 커밋하려는 파일의 추적상태 정보들만 기록
  • staging area는 working directory와 .git directory 사이의 임시저장공간이며 커밋을 빠르게 처리하기 위해 존재
• .git directory
  • commit이 일어나면 staging area에 있는 파일들이 하나의 버전으로 git directory에 저장
  • commit 후에는 파일상태가 staged에서 unmodified가 된다.

• untracked/tracked?
  • untracked
    저장소 내에 새로만들어진 모든 파일들(git이 추적X)
  • tracked
    tracked 상태의 파일은 git에 의해 변경이력이 추적됨
• modified/unmodified?
  Git이 코드의 변화를 기록하기 위해선, 파일의 최종 상태가 stage 상태가 되어야 한다. 하지만, 워킹 디렉토리 내의 파일을 수정하게 되는 경우, 스테이지와 워킹 디렉토리의 파일 내용이 일치하지 않는다. 따라서, 스테이지에서는 modified와 unmodified 상태로 파일의 원본과 수정본을 구분한다. 변경 발생 기준은 '파일이 Stage에 등록되거나 또는 Commit된 시점 이후에 변경 되었는가'이다.
  • modified
    워킹 디렉토리 내의 tracked 상태의 파일을 수정하게 되는 경우, Git의 스테이지는 파일의 상태를 modified 상태로 변경한다.
    modified 상태의 파일은 스테이지 영역에서 제외되며 스테이지 영역으로 재등록하기 위해선, $git add 명령어를 다시 사용해야한다.
  • unmodified
    -tracked 상태이면서 스테이지에서 한번도 수정을 하지 않은 원본을 의미

Git 기본 명령어

• 기본 명령어 모음
  https://git-scm.com/docs
• git help : 도움말 기능(가장 많이 사용하는 21개의 깃 명령어 출력). 사용법이 궁금한 명령어에 대해 'git help [궁금한 명령어]'를 타이핑시, 해당 깃 명령어의 설정과 사용에 대한 도움말 출력.
• git config --h : --h를 통해 명령어 속성값 확인가능
• git init : 깃 저장소를 초기화. 저장소나 디렉토리 안에서 이 명령을 실행하기 전까지는 그냥 일반 폴더이다. 이 명령어를 입력한 후에야 추가적인 깃 명령어 입력 가능.
• git status : 저장소 상태 체크. 어떤 파일이 저장소 안에 있는지, 커밋이 필요한 변경사항이 있는지, 현재 저장소의 어떤 브랜치에서 작업하고 있는지 등의 상태정보 출력.
• git add : 'staging 영역'에 변경내용 추가. 다음 commit명령 전까지 변경분을 staging 영역에 보관하여 변동내역을 저장.
• git diff : working directory 내 파일의 변경내용 확인.(~ difftool 사용시 사전설정한 difftool에서 확인가능)
• git diff --staged(cached) : staging area 내 파일의 변경내용 확인.(~ difftool~ 사용시 사전설정한 difftool에서 확인가능)
• git commit : staging area에 있는 변경 내용 커밋. 깃의 가장 중요한 명령어.
  • cf) git commit -m [커밋 메시지] : staging area에 있는 내용을 "커밋 메시지"를 메모로 커밋을 진행함(간단).
  • cf) git commit -am(-a -m) "all commit" : working directory 내용도 stage를 거치지 않고 바로 커밋
• git log : 커밋 히스토리 확인(--reverse 붙이면 역순정렬)
• rm ~.~ : ~.~파일을 working directory에서 삭제
• git rm ~.~ : ~.~파일을 삭제하고, staging area에 즉시반영
• git mv ~ ~ : ~파일의 이름을 ~로 변경하고, staging area에 즉시반영
  -git -p : 커밋된 파일들의 수정/업데이트 내용을 확인
• git checkout : 작업하기 원하는 브랜치로 이동.
  • cf1) git checkout 태그명 : 태그명 브랜치로 이동.
  • cf2) git checkout -b lafa : 'lafa' 라는 브랜지를 생성 후 해당 브렌치로 이동(생성과 이동 동시에)
  • cf3) git checkout (해쉬코드) : log로 확인한 해쉬코드의 version으로 이동
• git switch : 작업하기 원하는 브랜치로 이동. checkout과 같은 수행을 하지만, 한정된 기능을 가지고 있음.
  • cf1) git checkout 태그명 : 태그명 브랜치로 이동.
  • cf2) gitswitch -C lafa : 'lafa' 라는 브랜지를 생성 후 해당 브렌치로 이동(생성과 이동 동시에)
    -git tag 문자열 : 현재 커밋에 tag를 달 수 있음
  • cf) git tag 문자열 해쉬코드 : 해당 해쉬코드의 커밋에 태그를 달 수 있음
  • cf) git tag 문자열 해쉬코드 -am "Release note..." : 추가 메모 작성가능(~show~ 명령어로 추가 메모 확인가능)
  • cf) git tag -d 문자열 : 문자열 해당 태그명 삭제
• git tag : 만들어진 모든 태그 확인가능
  • git tag -l "v1.0.*" : 원하는 문자열을 포함한 태그를 검색
• git branch : 새로운 브랜치 생성. 여러 협업자와 작업할 시, 이 명령어로 새로운 브랜치를 만들고, 자신만의 변경사항과 파일 추가 등의 커밋 타임라인을 생성, 완성 후 협업자의 branch 혹은 main과 merge.
• git push : 로컬 컴퓨터에서 서버로 변경사항을 “push”
• git pull : 서버 저장소로부터 최신 버전을 "pull" (서버 저장소의 데이터를 가져와, 현재 브랜치와 merge)
  • cf) 작업 도중 기존 작업 내용은 유지하면서, 최신 코드로 업테이트 할 때 사용.
• git clone : 서버 저장소의 데이터를 로컬 컴퓨터로 복사. (서버 저장소의 데이터를 그대로 가져옴. 작업중이던 내역 있을시 덮어쓰기 됨)
  • cf) 프로젝트에 처음 투입 될 때 사용
• git merge : 개별 branch에서 마친 작업을 master branch로 병합.

로그관련 추가 명령어

• git log --oneline : 커밋된 파일들의 수정/업데이트 내용을 간단히 확인
• git log --pretty=format:"%h %an":로그 포맷을 원하는 형태로 변경가능
• git log -3 : 최근 3개 내역만 확인 가능
• git log -S "문자열" : 원하는 문자열의 변경사항을 가지고 있는 커밋을 찾을 수 있음
• git log 파일명 : 해당하는 파일의 로그만 확인가능
• 이 외에도 작성장, 날짜 등등 분류해서 로그확인가능

git add * vs git add . 차이점

• git aad .
  .gitignore에 기재된 것 고려하여 모두 추가
• git add *
  .gitignore에 기재된 것 상관없이 모두 추가
  gitignore 사용시 . 커맨드 사용
• .gitignore
  .gitignore 파일안에 무시할 파일명 입력시 tracking하지 않음. log파일이나 bulid 파일 등에 사용

깃 사용시 팁

• 레파지토리는 기능별로 의미있는 이름을 부여해서 분류해서 관리
• 오류 수정시 하나씩만 수정해서 커밋해야함
  • 한번에 많은 오류를 수정하면 히스토리관리의 의미가 퇴색됨

Commit message 7가지 규칙

• 제목과 본문을 한 줄 띄어 구분
• 제목은 50자 이내로 작성
• 제목 첫 글자는 대문자
• 제목 끝에 마침표 X
• 제목은 명령문으로, 과거형 X
• 본문의 각 행은 72자 이내 (줄바꿈 사용)
• 본문은 어떻게 보다 무엇을, 왜에 대하여 설명

Commit Type

• feat : 새로운 기능 추가
• fix : 기능에 대한 버그 수정
• build : 빌드 관련 수정
• chore : 패키지 매니저 수정, 그 외 기타 수정
• ci : CI 관련 설정 수정
• docs : 문서(주석) 수정
• style : 코드 스타일, 포맷팅에 대한 수정(코드 자체의 변경은 X)
• refactor : 코드 리팩터링
• test : 테스트 코드 추가/수정
• release : 버전 릴리즈

semantic versioning?

ex. v1.0.0
첫번째 자리 major ver
두번째 자리 minor ver
세번째 자리 fix ver