git 개념정리(ing)

Hyunsuki·2022년 4월 6일
2

git

목록 보기
1/1
post-thumbnail

프로젝트 간 협업을 하기 위해서는 형상 관리라는 것을 해야한다. 이 형상관리를 위해 많은 개발자들이 사용하는 tool에는 git이 있다.

index == stage

버전 관리 시스템 => 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템

파일을 이전 상태로 되돌릴 수 있고, 프로젝트를 통째로 이전 상태로 되돌릴 수 있고, 시간에 따라 수정 내용을 비교해 볼 수 있고, 누가 문제를 일으켰는지도 추적할 수 있고, 누가 언제 만들어낸 이슈인지도 알 수 있다.

버전 관리 시스템(VCS) -> 중앙집중식 버전 관리(CVCS) -> 분산 버전 관리 시스템(DVCS)

vcs

CVCS

DVCS

대표적인 CVCS와 DVCS인 SVN과 GIT의 가장 중요한 차이점
네이밍에서도 알 수 있듯이, Server Repository만 있냐, Local Repository도 존재하냐의 차이

DVCS에서의 클라이언트는 단순히 파일의 마지막 스냅샷을 Checkout 하지 않는다. 그냥 저장소를 히스토리와 더불어 전부 복제한다. 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다. 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다. Clone은 모든 데이터를 가진 진정한 백업이다.
-Pro Git book 1.1장 중-

게다가 대부분의 DVCS 환경에서는 리모트 저장소가 존재한다. remote repository가 많을 수도 있다. 그래서 사람들은 동시에 다양한 그룹과 다양한 방법으로 협업할 수 있다. 계층 모델 같은 중앙집중식 시스템으로는 할 수 없는 workflow를 다양하게 사용할 수 있다.


워킹 디렉토리의 모든 파일은 크게 Tracked(관리대상임)와 Untracked(관리대상이 아님)로 나눈다. Tracked는 Unmodified(수정하지 않음)와 Modified(수정함) 그리고 Staged(커밋으로 저장소에 기록할) 이렇게 세 가지 상태로 관리한다.

처음 저장소를 Clone 하면 모든 파일은 Tracked이면서 Unmodified 상태이다. Git은 Untracked 파일을 아직 snapshot(commit)에 넣어지지 않은 파일이라고 본다. 파일이 Tracked 상태가 되기 전까지는 절대 그 파일을 커밋하지 않는다.

git add 명령은 파일을 새로 추적할 때도 사용하고 수정한 파일을 Staged 상태로 만들 때도 사용한다. Merge 할 때 충돌난 상태의 파일을 Resolve 상태로 만들때도 사용한다. add의 의미는 프로젝트에 파일을 추가한다기 보다는 다음 커밋에 추가한다고 받아들이는게 좋다.

파일 상태를 확인하기

git status -> full
git status -s 또는 git status --short -> 짧게 보고 싶을 때

정리하면

= unmodified

M = modified

T = file type changed (regular file, symbolic link or submodule)

A = added

D= deleted

R = renamed

C = copied (if config option status.renames is set to "copies")

U = updated but unmerged

?? = untracked

!!= ignored

이고 각각 X는 Staging Area에서의 상태를, Y에는 Working Tree의 상태를 나타낸다고 했으니, 잘 조합해서 이해하면 될 것 같다.

위 명령의 결과에서 상태정보 컬럼에는 두 가지 정보를 보여준다. 왼쪽에는 Staging Area에서의 상태를, 오른쪽에는 Working Tree에서의 상태를 표시된다.

$ git status -s
M README
MM Rakefile
A lib/git.rb
M lib/simplegit.rb
?? LICENSE.txt

README는 변경하고 Staged 상태로 추가하지 않은 상태, Rakefile는 변경하고 Staged 상태로 추가한 후 또 내용을 변경해서 Staged 이면서 Unstaged 상태,
Staging Area에서의 상태를 표시하는 단축어로 새로 생성한 파일이면서 staged된 상태는 A , 변경하고 Staged 상태로 추가까지 한 상태는 M , 아직 추적하지 않는 새 파일 앞에는 ??, ignore된 상태는 !!, 삭제한 파일은 D ,

파일 무시하기

어떤 파일은 Git이 관리할 필요가 없다. 그런 파일을 무시하려면 .gitignore 파일을 만들고 그 안에 무시할 파일 패턴을 적는다.

.gitignore 파일에 작성 패턴

•아무것도 없는 라인이나, #로 시작하는 라인은 무시한다.

•표준 Glob 패턴을 사용한다. 이는 프로젝트 전체에 적용된다.

•슬래시(/)로 시작하면 하위 디렉토리에 적용되지(Recursivity) 않는다.

•디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다.

•느낌표(!)로 시작하는 패턴의 파일은 무시하지 않는다.

Staged와 Unstaged 상태의 변경 내용을 보기

단순히 파일이 변경됐다는 사실이 아니라 어떤 내용이 변경됐는지 살펴보려면 git status 명령이 아니라 git diff 명령을 사용해야 한다. 이는 제목에서 나와있듯이, working directory에 있는 것과 Staging Area에 있는 것을 비교하는 것을 의미한다. 때문에 수정한 파일을 모두 Staging Area에 넣었다면 git diff 명령은 아무것도 출력하지 않는다.

Staged 상태인 파일은 git diff --cached 또는 git diff --staged 옵션으로 확인하면 된다.

변경사항 커밋하기

수정한 것을 커밋하기 위해 Staging Area에 파일을 정리했다. Unstaged 상태의 파일은 커밋되지 않는다는 것을 기억해야 한다. Git은 생성하거나 수정하고 나서 git add 명령으로 추가하지 않은 파일은 커밋하지 않는다. 그 파일은 여전히 Modified 상태로 남아 있다. 커밋하기 전에 git status 명령으로 모든 것이 Staged 상태인지 확인할 수 있다. 그 후에 git commit 을 실행하여 커밋한다.
$ git commit

Staging Area 생략하기

$ git commit -a -> Tracked 상태의 파일을 자동으로 Staging Area에 넣겠다는 옵션으로 add 명령을 실행하는 수고를 덜 수 있다.

파일 삭제하기

Git에서 파일을 제거하려면 git rm 명령으로 Tracked 상태의 파일을 삭제한 후에(정확하게는 Staging Area에서 삭제하는 것) 커밋해야 한다. 이 명령은 워킹 디렉토리에 있는 파일도 삭제하기 때문에 실제로 파일도 지워진다.

git 명령을 사용하지 않고 단순히 워킹 디렉터리에서 파일을 삭제하고 git status 명령으로 상태를 확인하면 git은 현재 “Changes not staged for commit” (즉, Unstaged 상태)라고 표시해준다.

커밋하면 파일은 삭제되고, git은 이 파일을 더는 추적하지 않는다. 이미 파일을 수정했거나 Staging Area에(Git Index라고도 부른다) 추가했다면 -f 옵션을 주어 강제로 삭제해야 한다. 이 점은 실수로 데이터를 삭제하지 못하도록 하는 안전장치다. 커밋 하지 않고 수정한 데이터는 Git으로 복구할 수 없기 때문이다.

또 Staging Area에서만 제거하고 워킹 디렉토리에 있는 파일은 지우지 않고 남겨둘 수 있다. 다시 말해서 하드디스크에 있는 파일은 그대로 두고 git만 추적하지 않게 한다. 이것은 .gitignore 파일에 추가하는 것을 빼먹었거나, 대용량 로그 파일이나 컴파일된 파일인 .a 파일 같은 것을 실수로 추가했을 때 쓴다. --cached 옵션을 사용하여 명령을 실행한다.(git)

$ git rm --cached [파일명]
$ git rm -r --cached [디렉토리명]

여러 개의 파일이나 디렉토리를 한꺼번에 삭제할 수도 있다. 아래와 같이 git rm 명령에 file-glob 패턴을 사용한다.

$ git rm log/\*.log

  • 앞에 \ 을 사용한 것을 기억하자. 파일명 확장 기능은 쉘에만 있는 것이 아니라 Git 자체에도 있기 때문에 필요하다. 이 명령은 log/ 디렉토리에 있는 .log 파일을 모두 삭제한다. 아래의 예제처럼 할 수도 있다.

파일 이름 변경하기

$ git mv file_from file_to를 통해 파일의 이름을 변경할 수 있다. 이는 사실 아래의 3가지 명령을 순차적으로 실행한 것과 동일하다.
$ mv file_from file_to
$ git rm file_from
$ git add file_to
이를 반대로 말하면 워킹 디렉토리에서 파일명을 바꾼다면, stage에서 기존 파일명을 파일을 삭제하고, 새로운 이름의 파일을 add해줘야한다.

커밋 히스토리 조회하기

특별한 argument 없이 git log 명령을 실행하면 저장소의 커밋 히스토리를 시간순으로 보여준다. 즉, 가장 최근의 커밋이 가장 먼저 나온다. 각 커밋의 SHA-1 체크섬, 저자 이름, 저자 이메일, 커밋한 날짜, 커밋 메시지를 보여준다.
git log -n -> 최근순으로 n만큼의 log를 보여준다.

git log -p 또는 git log --patch 각 커밋들의 diff 결과까지 보여준다. 추가적인 옵션으로 -n를 입력하면 n만큼 최근 commit에 대해서만 보여준다.

git log --stat 옵션은 어떤 파일이 수정됐는지, 얼마나 많은 파일이 변경됐는지, 또 얼마나 많은 라인을 추가하거나 삭제했는지 보여준다. 요약정보는 가장 뒤쪽에 보여준다.

git log --pretty
option에는 한줄 표현 옵션 oneline 표현되는 정보를 가감해서 보여주는 옵션들로는 short full fuller 가 있다.

Author != Committer
저자는 원래 작업을 수행한 원작자이고, Committer는 마지막으로 이 작업을 저장소에 적용시킨 사람이다.

git log --pretty=format 에 쓸 몇가지 유용한 옵션에는 아래의 참고하자.

format option

구분기능
%HCommit hash
%hAbbreviated commit hash
%TTree hash
%tAbbreviated tree hash
%PParent hashes
%pAbbreviated parent hashes
%anAuthor name
%aeAuthor email
%adAuthor date (format respects the --date=option)
%arAuthor date, relative
%cnCommitter name
%ceCommitter email
%cdCommitter date
%crCommitter date, relative
%sSubject, summary

oneline 옵션과 format 옵션은 --graph 옵션과 함께 사용할 때 더 빛난다. 이 명령은 브랜치와 머지 히스토리를 보여주는 아스키 그래프를 출력한다.

-p or --patch

각 커밋에 적용된 패치를 보여준다.

--stat

각 커밋에서 수정된 파일의 통계정보를 보여준다.

--shortstat

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

--name-only

커밋 정보중에서 수정된 파일의 목록만 보여준다.

--name-status

수정된 파일의 목록을 보여줄 뿐만 아니라 파일을 추가한 것인지, 수정한 것인지, 삭제한 것인지도 보여준다.

--abbrev-commit

40자 짜리 SHA-1 체크섬을 전부 보여주는 것이 아니라 처음 몇 자만 보여준다.

--relative-date

정확한 시간을 보여주는 것이 아니라 “2 weeks ago” 처럼 상대적인 형식으로 보여준다.

--graph

브랜치와 머지 히스토리 정보까지 아스키 그래프로 보여준다.

--pretty

지정한 형식으로 보여준다. 이 옵션에는 oneline, short, full, fuller, format이 있다. format은 원하는 형식으로 출력하고자 할 때 사용한다.

--oneline
--pretty=oneline --abbrev-commit 두 옵션을 함께 사용한 것과 같다.

git log 조회 범위를 제한하는 옵션

구분기능
-n최근 n 개의 commit만 조회한다.
--since, --after명시한 날짜 이후의 commit만 검색한다.
--until, --before명시한 날짜 이전의 commit만 조회한다.
--author입력한 Author의 commit만 보여준다.
--committer입력한 Committer의 커밋만 보여준다.
--grepcommit message 안의 텍스트를 검색한다.
-Scommit 변경(추가/삭제) 내용 안의 텍스트를 검색한다.
profile
뒤늦게 시작된 데이터 분석가 생활

0개의 댓글