[GIT] git 실습

Coastby·2022년 10월 4일
0

LIKELION Back-End School

목록 보기
31/61
post-custom-banner

Git

버전 관리 시스템 (형상 관리 도구, configuration management tool) 중 하나이다.

소스코드를 효과적으로 관리할 수 있게 해주는 무료 공개 소프트웨어이다.

○ 용어

  • Repository : 저장소를 의미하며, 히스토리, 태그, 소스의 브랜치 혹은 브랜치에 따라 버전을 저장한다. 저장소를 통해 작업자가 변경한 모든 히스토리를 확인할 수 있다.
  • git 디렉토리 : 깃 저장소.
    • git init : 명령으로 .git이라는 이름으로 생성된다.
    • git 프로젝트의 모든 메타데이터와 객체 데이터베이스가 저장된다.
    • git clone : 원격 저장소를 복사해서 가져올 때, 생성된 폴더 안에 .git 디렉토리를 만들고, 원격 저장소의 모든 데이터를 복사해서 가져온다.
  • Working Tree : git 디렉토리에서 특정 버전을 checkout 해온 것이며, 이곳에서 프로젝트 작업을 진행하게 된다.
  • Staging Area (Index): 저장소에 커밋하기 전에 커밋을 준비하는 위치
  • Commit : 현재 변경된 작업 상태를 점검을 마치면 확정하고 저장소에 저장하는 작업
  • Head : 현재 작업중인 branch
  • Branch : 가지 또는 분기점을 의미하며, 작업을 할 때에 현재 상태를 복사하여 branch에서 작업을 한 후에 완전하다 싶을 때 merge를 하여 작업을 한다.
  • Merge : 다른 branch의 내용을 현재 branch로 가져와 합치는 작업

git clone

  • git repository에서 주소 복사하기 (HTTPS형식, SSH 형식으로 받을 수 있다)아래 코드를 터미널에서 입력한다.
  • DIR : 저장소를 로컬에 복제할 위치이며 생략가능하다. 폴더이름을 입력하면 새폴더가 생성되고 그 안에 코드가 다운로드된다. 생략하면 깃허브 프로젝트 이름으로 폴더가 자동으로 생기고 그 안에 코드가 다운로드된다.
git clone (복사한주소) (DIR)

git clone vs git pull

  • git clone : 로컬 저장소의 내용이 원격 저장소의 내용과 일치해진다.
    • 기존에 작업 중이었다면, 작업 내용은 직접 복구해야 한다.
    • 프로젝트에 처음 투입될 때 사용된다.
  • git pull : 원격 저장소의 내용을 가져와서 현재 브랜치와 병합 (merge)까지 진행한다.
    • git fetch (다운로드는 받지만 로컬 리포지토리는 바꾸지 않음)+ git merge
    • 기존 작업 내용은 유지하면서 최신 코드로 업데이트할 수 있다.
    • pull을 하기 전에 commit을 하지 않으면 덮어쓰기 에러가 발생할 수 있다.
    • 코드 내용이 두 브랜치 간에 다르다면 충돌이 발생할 것이며, 이는 직접 충돌 처리를 해야 한다.

git status

워킹 디렉토리의 파일의 상태

  • Untracked : 1) 파일을 저장소에 저장할 필요가 없어 git이 신경쓰지 않아도 되는 상태 또는 2) 파일을 새로 만든 경우
  • Tracked : 파일에 수정이 일어나면 git이 파일의 변경을 감지하여 사용자에게 알려주는 것과 같이 파일을 추적하는 상태
    • Staged : git add를 이용하여 staging area에 올린 파일들
    • Unmodified : Staging area에 있던 파일을 commit하게되면 Unmodified로 내려온다.
    • Modified : Unmodified 상태의 파일들을 수정한 경우, 수정했지만 commit하지 않은 상태.

💡 Commit 하게 되면 로컬 리포지토리 에 저장된다.

git add 후 수정

파일이 Staged 상태에도 있고 Modified 상태에도 있는 것을 확인할 수 있다.

Staging Area에 있는 파일은 워킹 디렉토리의 파일이 옮겨지는 것이 아니라 복사되는 것이다. 그렇기 때문에 `git add`를 한 후 그 파일을 수정하게 되면 Staging Area에 있는 파일에는 수정내용이 반영되지 않는다. 따라서 하나의 파일이 위와 같은 두 개의 상태를 가질 수 있다. 

또한 이대로 commit하게 된다면 수정사항은 반영되지 않고 리포지토리로 올라간다.

git checkout — 파일이름

워킹 디렉토리의 modified 특정 파일을 가장 최근 커밋 버전으로 되돌릴 수 있다. 즉, 워킹 디렉토리에서의 수정 사항을 제거한다. 하지만 이 기능은 되돌릴 수 없으니 주의해야 한다. 

git rm —cached 파일이름

한 번 `git add` 를 해주시면 직접 `git rm --cached 파일이름`  명령어를 이용하지 않는 이상 Untracked 상태가 되지 않는다.

참고 : https://github.com/yeoseon/tip-archive/issues/85

https://seonkyukim.github.io/git-tutorial/git-status/

git add

  • git add : 작업 디렉토리(working directory) 상의 변경 내용을 스테이징 영역(staging area)에 추가하기 위해서 사용하는 Git 명령어입니다.
  • git add . : 현재 디렉토리의 추적되는 파일 모두 add
  • git add 파일명 파일명 ... 파일명 : 파일 여러개 add
  • git add -A : 저장소 내 모든 파일 add
  • git add -p : 변경 사항을 터미널으로 확인하면서 스테이징으로 넘기거나 제외시킴
    • 명령어
      git add -p를 사용하면 파일들의 변경점을 hunk 단위로 보여주고, 해당 hunk에 대해 Stage, Skip 등의 action을 취할 수 있습니다. (hunk는 Stage될 수 있는 파일 조각 단위입니다.) 사용할 수 있는 명령어는 다음과 같습니다.
      y - stage this hunk
      n - do not stage this hunk
      q - quit; do not stage this hunk or any of the remaining ones
      a - stage this hunk and all later hunks in the file
      d - do not stage this hunk or any of the later hunks in the file
      g - select a hunk to go to
      / - search for a hunk matching the given regex
      j - leave this hunk undecided, see next undecided hunk
      J - leave this hunk undecided, see next hunk
      k - leave this hunk undecided, see previous undecided hunk
      K - leave this hunk undecided, see previous hunk
      s - split the current hunk into smaller hunks
      e - manually edit the current hunk
      ? - print help
      자주 사용되는 명령어는 y, n, q, s, e입니다.
      • y : 이 hunk를 stage 시킵니다.
      • n : 이 hunk를 stage하지 않습니다.
      • q : add 과정을 종료합니다.
      • s : 이 hunk를 더 작은 단위의 hunk로 나눕니다. 한 hunk에 대해서 1번만 실행할 수 있습니다.
      • e : 현재 hunk 내용을 직접 편집합니다.
  • git add —update : 현재 git이 추적하고 있는 파일만 add (새로 만든 파일은 올라가지 ㅇ낳음)
  • git rm —cached : add 된 파일 취소

○ .gitignore

하나씩 git repository에 넣는 것은 번거로워 보통 git add . 를 이용해 변경된 전체 파일을 추가하고 커밋한다.

그러나

  • 보안상으로 위험성이 있는 파일
  • 프로젝트와 관계없는 파일
  • 용량이 너무 커서 제외해야되는 파일
  • 자바의 경우 .class 파일
  • 로그 파일이나 빌드 시스템이 자동으로 생성한 파일
  • .iml, .idea/

등등은 git add에 포함시키지 않는다.

이때 .gitignore 파일을 만들고 그 안에 무시할 파일 패턴을 적는다.

$ cat .gitignore
*.[oa]
*~

첫번째 라인은 확장자가 “.o” 나 “.a” 인 파일을 Git이 무시하라는 것이고 둘째 라인은 ~ 로 끝나는 모든 파일을 무시하라는 것이다. 보통 대부분의 텍스트 편집기에서 임시파일로 사용하는 파일 이름이기 때문이다. “.o” 와 “.a” 는 각각 빌드 시스템이 만들어내는 오브젝트와 아카이브 파일이고 ~ 로 끝나는 파일은 Emacs나 VI 같은 텍스트 편집기가 임시로 만들어내는 파일이다. 또 log, tmp, pid 같은 디렉토리나, 자동으로 생성하는 문서 같은 것들도 추가할 수 있다..gitignore 파일은 보통 처음에 만들어 두는 것이 편리하다. 그래서 Git 저장소에 커밋하고 싶지 않은 파일을 실수로 커밋하는 일을 방지할 수 있다.

.gitignore 파일에 입력하는 패턴은 아래 규칙을 따른다.

  • 아무것도 없는 라인이나, #로 시작하는 라인은 무시한다.
  • 표준 Glob 패턴을 사용한다. 이는 프로젝트 전체에 적용된다.
  • 슬래시(/)로 시작하면 하위 디렉토리에 적용되지(Recursivity) 않는다.
  • 디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다.
  • 느낌표(!)로 시작하는 패턴의 파일은 무시하지 않는다.

Glob 패턴은 정규표현식을 단순하게 만든 것으로 생각하면 되고 보통 쉘에서 많이 사용한다. 애스터리스크(*)는 문자가 하나도 없거나 하나 이상을 의미하고, [abc] 는 중괄호 안에 있는 문자 중 하나를 의미한다(그러니까 이 경우에는 a, b, c). 물음표(?)는 문자 하나를 말하고, [0-9] 처럼 중괄호 안의 캐릭터 사이에 하이픈(-)을 사용하면 그 캐릭터 사이에 있는 문자 하나를 말한다. 애스터리스크 2개를 사용하여 디렉토리 안의 디렉토리 까지 지정할 수 있다. a/**/z 패턴은 a/za/b/za/b/c/z 디렉토리에 사용할 수 있다.

아래는 .gitignore 파일의 예이다.

# 확장자가 .a인 파일 무시
*.a

# 윗 라인에서 확장자가 .a인 파일은 무시하게 했지만 lib.a는 무시하지 않음
!lib.a

# 현재 디렉토리에 있는 TODO파일은 무시하고 subdir/TODO처럼 하위디렉토리에 있는 파일은 무시하지 않음
/TODO

# build/ 디렉토리에 있는 모든 파일은 무시
build/

# doc/notes.txt 파일은 무시하고 doc/server/arch.txt 파일은 무시하지 않음
doc/*.txt

# doc 디렉토리 아래의 모든 .pdf 파일을 무시
doc/**/*.pdf

# 수업 중 작성
*.iml
java-project/.idea
java-project/out

수동으로 올라간 파일 삭제하기

gitignore 파일 수정 후 이미 원격 저장소에 올라간 파일들을 삭제하는 방법

git rm -r --cached . (현재 레포지토리의 캐시를 모두 삭제한다.)
git add .
git status
git commit -m "커밋메세지"

참고:https://devlog-wjdrbs96.tistory.com/237

.gitignore 관련 Git 공식 문서

https://github.com/github/gitignore

.gitignore 파일 생성 사이트

www.toptal.com/developers/gitignore

profile
훈이야 화이팅
post-custom-banner

0개의 댓글