[git] 내맘대로 명령어 정리

버전 관리 프로그램중 가장 유명한 git!! 정리를 안할래야 안할 수 가 없다.

 

일단 git은 커멘드 창에서 명령어를 통해 제어할 수 있는데 명령어를 알고 싶다면

 

커멘드 창에 'git'이라고 치면 된다

git

그럼 위와 같이 사용할 수 있는 명령어들이 나온다!

위의 명령어 순서대로 정리를 해보자! 커멘드 창에서 파일의 생성 및 제어를 위한 커멘드 용어는 따로 정리를 하자!

 

 

1. 저장소 생성

 가장 먼저 정리할 것은 저장소 생성 방법이다.

내 디렉토리에 저장소를 생성 하는 방법은 크게 2가지로 새로운 저장소를 만들거나

기존에 존재하던 repository에서 새로운 디렉토리와 연결하는 방법이 있다.

 

첫 번째로 새로운 저장소를 만드는 방법이다.

git init

만들려는 저장소 경로로 이동하여 해당 명령어를 입력하면 master 브렌치가 생성되며

해당 경로에 .git이라는 디렉토리가 생성되는데 해당 디렉토리에 버전 관리에 대한 정보들이 저장된다.

 

두 번째로 clone은 이미 만들어져 있는 git 브랜치를 가져오는 명령어로

git clone [디렉토리 경로]

만들려는 저정소 경로로 이동하여 해당 명령어를 실행해주면 된다.

 

 

2. 프로젝트 파일 제어

2.1 add

git에서 파일 관리를 하기 위해 add라는 명령어가 있는데

이 명령어는 commit하기 전 이전 버전과 다른 파일이 있는 경우 해당 파일의 상태를 추적하겠다는 명령어이다.

해당 명령어로 add 해놓지 않은 파일은 commit 과정에서 커밋되지 않는다.

git add [파일 경로 및 파일 이름]

 

2.2 mv

파일 명을 바꾸는 명령어다. 자주 안쓸듯...?

git mv [원본이름] [변경이름]

위와 같이 사용하면 이름이 변경된다.

 

2.3 restore

파일을 워킹 트리의 원본으로 바꿔주는 명령어

작업을 잘못하거나 필요없는 작업을 수행했을 때 원본으로 되돌릴 수 있는 명령어이다.

git restore [파일이름]

위와 같이 사용하면 원본으로 복구해준다.

예전에 사용했던 svn의 revert 기능과 비슷한 기능으로 보인다. restore는 넣을 수 있는 조건들이 많아서 필요할 때 다시 찾아봐야 할 것 같다.

ujuc.github.io/2020/07/04/git-switch-n-restore-hurt-eo-bo-gi/#git-restore

 

2.4 rm

파일을 삭제하는 명령어로 파일 제거 후 커밋을 해줘야 한다.

git rm [파일이름]
git commit -m "파일이름 삭제했습니다."

추가로 커밋하지 말아야 할 파일들을 커밋한 경우 --cashed 명령어를 사용하여 저장소에서만 삭제가 가능하다.

git rm --cached [파일 이름]

 

2.5 sparse checkout

특정 파일 및 폴더의 정보만 checkout하는 기능이다.

해당 기능은 다른 명령어와 다르게 on/off하는 기능인데

git config core.sparsecheckout true

위와 같은 명령어를 저장소 폴더에서 실행해야 한다.

default는 꺼져 있는 상태다.

 

해당 기능을 사용하기 위해서는 .git/info/sparse-checkout라는 파일을 만들고 해당 파일에

현재 저장소에서 필요한 파일이나 디렉토리를 적어준 후

git read-tree -m -u HEAD

위의 명령어를 실행해주면 저장소에서 원하는 폴더나 파일만 남길 수 있다.

근데 잘 안쓸듯...? 써야 될 경우나 이유를 잘 모르겠다

 

3. 프로젝트 상태 파악

3.1 bisect

버그가 발생한 커밋 기록을 찾기 위한 명령어로

커밋의 hash 값을 이용하여 찾는 방식이다.

git bisect start
git bisect bad [문제가 발생한 commit의 해쉬]
git bisect good [문제가 발생하지 않는 commit의 해쉬]

위와 같이 실행하면

Bisecting: 7 revisions left to test after this (roughly 3 steps)
[1c0b7a04ea7802037ec1b1ed0d98ecbfc5f5747d] Commit Message~

출처: https://simsi6.tistory.com/97 [곰돌푸우❤️]

버그가 발생한 커밋 찾기 (git bisect)

저런 문구가 출력 된다고 하는데 두 개의 커밋 사이에 7개의 커밋이 있고

bisect를 3번만 더 실행하면 찾을 수 있다는 뜻이라고 한다.

필요할 때 위의 블로그로 가서 다시 공부하자! 지금은 굳이 필요가 없어보인다.

 

3.2 diff

현재 브랜치의 마지막 커밋과 차이점을 비교할 때 사용하는 명령어로

git diff

위와 같이 사용하면 되고 명령어 뒤에 commit id를 넣어주면 해당 커밋과의 차이점을 비교해서 보여준다.

커밋하기 전에 diff를 사용하여 브랜치에 이전에 수정한 내용이 있는지 미리 파악하여 충돌을 최소화 할 수 있을 것 같다.

 

3.3 grep

검색 기능이다. 개발을 진행하다 보면 함수나 데이터가 정의된 위치를 찾아야 하는데 이 때 grep 기능을 사용하면 된다.

git grep [제어명령어] [찾을내용]

위와 같이 실행하면 되고 해당 내용은 엄청 유용해 보여서 따로 자세히 공부해서 정리해야겠다.

git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-%EA%B2%80%EC%83%89

위의 링크에서 정보를 찾을 수 있다.

 

3.4 log

프로젝트 디렉토리에서 커밋 기록을 확인하기 위한 명령어로

git log

위와 같이 입력하면 결과가 나온다.

git log도 추가적인 명령어를 입력하면 다양한 형태로 로그를 가공할 수 있는데

git diff -p -2

위와 같이 사용하면 최근 2개의 커밋을 diff한 결과를 보여준다.

추가 명령어는 아래와 같다.

-p	각 커밋에 적용된 패치를 보여준다.
--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 두 옵션을 함께 사용한 것과 같다.

이거 표 크기 수정을 어케 해야되는지 모르겠네....

 

3.5 show

log가 모든 커밋의 정보를 보는 것이라면 show는 특정 커밋의 정보를 볼 수 있다.

git show [해쉬 또는 HEAD]

위와 같이 입력하면 해당 커밋을 확인할 수 있고 특정 커밋을 지정하지 않으면 최신 커밋 정보를 확인할 수 있다.

 

 

3.6 status

파일의 상태를 확인할 수 있는 명령어로

git status

위와 같이 입력하면 상태를 확인할 수 있다.

파일들의 상태는 Untracked, staged, modified 상태가 있는데

Untracked는 파일이 변경되었지만 staged에 올라가지 않은 상태로 파일 명이 빨간색으로 표시된다.

staged는 커밋이 가능하게 staged에 올라간 상태의 파일들을 초록색으로 표시해준다.

modified는 staged에 올라간 파일이 수정된 경우 빨간색과 더불어 modified : 파일명으로 표시해준다.

4. 프로젝트 관리

4.1 branch

브랜치를 생성 및 조회하는 명령어로

git branch [브랜치명]

위와 같이 입력하면 브랜치를 생성할 수 있다.

그냥 git branch만 입력하게 될 경우 브랜치 목록 전체를 확인할 수 있다.

브랜치를 생성하는 또 다른 방법으로는 checkout 기능을 사용하는 방법이 있는데

git checkout -b [브랜치명]

위와 같이 입력하면 브랜치를 생성하고 해당 브랜치로 이동한다. 즉 브랜치를 생성하고 checkout해서 해당 브랜치로 이동하지 않아도 된다는 뜻이다!

 

4.2 commit

모든 add된 파일들을 명령어와 함께 Tracked 하는 명령어로

git commit -m "커밋 문구"

위와 같이 사용한다. 커밋하게 될 경우 git에 커밋 기록과 함께 add 했던 파일들이 commit 되며

이 커밋된 로그들은 git log를 이용하여 확인 가능하다!

 

4.3 merge

브랜치를 병합하는 작업을 merge라 하며

git merge [브랜치명]

위와 같이 사용한다.

병합하고자 하는 위치로 checkout을 통해 이동하여 명령어와 함께 병합할 브랜치명을 입력하면 병합된다.

브랜치를 병합할 때 파일이 충돌되는 경우가 있는데 보통 서로 같은 파일을 수정하고 같은 코드줄을 수정할 경우 발생한다. 이 때 conflict가 발생되었다고 하며 정보들을 노출하고 충돌된 파일들을 수정하며 다시 commit 하면 merge가 완료된다.

 

4.4 rebase

개념이 조금 어려운것 같은데 간단하게 생각하면 master 브랜치를 새로운 브랜치로... 즉 왕위를 계승하는 느낌이다.

checkout을 통해 rebase 하려는 브랜치로 이동하고

git rebase master

위와 같이 명령어를 입력하면 된다고 이해는 했는데

더 자세히 알아보면 master 브랜치를 이동하는게 아니라 기준점을 이동한다고 생각하는게 맞을 것 같다.

요거는 다음에 따로 다시 공부를 해봐야 할듯... 머리속으로는 이해가 되는데 왜 하는지 모르겠다.

 

4.5 reset

원하는 커밋으로 다시 되돌아가는 명령어다.

git reset [커밋정보]

위와 같이 사용하며 실수로 커밋을 잘못하거나 커밋을 못한 파일이 있는경우 되돌려서 다시 커밋을 하기 위한 방법으로 사용한다.

 

4.6 switch

기존 checkout 기능에서 브랜치를 변경하는 기능이 파생된 기능으로

2.23.0 버전 이후 restore와 함께 생긴 기능이다.

git switch [브랜치명]

위와 같이 사용하며 git switch --help 명령어를 통해 다양한 기능을 확인할 수 있다.

 

4.7 tag

저장소의 소스 버전을 표시하기 위한 태그를 추가하는 기능으로

git tag [버전이름]

위와 같이 사용한다. 브랜치에 버전을 정하는 기능으로

태그를 확인할 땐 git show [버전이름] 으로 확인할 수 있다.

 

 

 

 

이상으로 기본적인 git 명령어를 요약해봤다. 사실 그냥 개념만 이해한 내용들이 많아서 정확하지 않은 정보가 있을 수도 있고, 잘못 이해한 내용이 있을 수도 있어서 실제로 사용해보면서 필요한 내용은 계속 수정해 나갈 예정이다.
full이나 push 같은 명령어는 git의 개념 정리를 따로 해서 올릴 예정이므로 오늘의 기록은 여기까지!