init
프로젝트 폴더, 즉 앞으로 프로젝트에 사용될 파일을 모아 둔 폴더를 깃 프로젝트로 만들어야 한다. 그래야 폴더 내부 파일의 변경 사항들을 깃이 추적 할 수 있다.
git init | 현재 폴더를 깃 프로젝트로 만든다(.git이라는 repository(저장소)를 생성한다).
git clone [깃헙 프로젝트 url] [프로젝트를 복사할 폴더 이름] | 깃헙 repository(내 repo 뿐만 아니라, 다른 사람들이 공개한 repo도 가능)를 내 컴퓨터의 폴더로 복사해 올 수 있다.
Status
git status | 현재 branch의 내부 상태 확인
- trancked/ untracked files... | 깃이 변경 사항을 추적하고 있는 파일(tracked files), 아닌 파일(untracked files)
- modified | 이전 버전(커밋)과 내용이 달라진 파일
Add & Remove
깃 프로젝트로 init 한 뒤에, 폴더에 새로운 파일을 추가하고 "git status" 명령어를 입력하면, master branch에 untracked files가 있다는 도움말이 나온다. 즉, 프로젝트 파일에 새로운 파일이 추가되었지만 git에서 변경 사항을 감시하고 추적할 수 없는 파일이라는 뜻이다. "git add 파일명"을 명령한 뒤에, 다시 "git status"를 확인하면, git이 파일은 tracked file, 즉 추적되고 있는 파일이고, 언제든지 commit 될 수 있다고 안내한다. commit의 예비 단계라고 할 수 있다. 왜 바로 commit하지 않고 add라는 중간 단계를 두고 있는 걸까?
이 상태에서 다시 파일을 수정하면, 이미 staging area에 add한 파일이기 때문에 수정한 내용을 추적하고 있을 것 같지만, 다시 한 번 add라는 명령어를 입력해야 변화된 내용을 추적할 수 있다. 같은 파일이라도 내가 add하지 않은 변화 사항은 commit하지 않게 만들기 위해 이런 방법으로 동작한다. 여러 개의 파일을 수정했더라도, 내가 add한 파일만 commit 대기(staged) 상태로 만들 수 있는 것도 이 중간단계 덕분이다.
그래도 add 단계가 번거롭다고 느끼는 사람들을 위해 commit -a라는 옵션이 있다.
git add 파일명 | git에게 파일의 현재 상태를 추적하라고 지시
git add -p | p 옵션을 이용하면, 파일 단위가 아니라 코드 단락(paragraph) 단위로 변화 상태를 staging area로 옮길 수 있다. 한 파일 내부에서도 특정 라인만 add 하고 싶을 때 유용하다.
git rm --cached 파일명 또는 git restore --staged | staging area에 있는 파일을 다시 working directory로 이동
Ignore
tracking 하고 싶지 않은 파일들이 여러개 쌓이면 git status를 확인할 때 마다 그 파일들이 주욱 나열되는 게 보기 싫을 수 있다. 그럴 때는 여러 개의 파일을 gitignore라는 곳에 보관하면 된다.
echo *.log >> .gitignore | 모든 log 파일을 gitignore에 집어넣고, git이 트래킹하지 않도록한다.
- echo | .gitignore 라는 파일을 만들고, 그 내용으로 *.log를 입력한다.
Commit
staging area로 옮겨진 파일들, 즉 add 명령어를 이용해 commit 대기 상태에 놓여있는 파일의 상태는, commit을 통해 git repository에 저장될 수 있다. 즉 하나의 버전으로 등록할 수 있다. 이렇게 버전으로 등록되면 언제든지 그 상태로 되돌아 갈 수 있다.
만약 staging area로 옮겨지지 않은, 즉 working directory에서 작업 중인 내용도 모두(all) commit하고 싶을 때에는 "git commit -a"을 이용한다. 메세지 옵션과 함께 "git commit -am" 으로 작성할 수 있다.
git commit | 현재 staging area에 추가되어있는 모든 파일의 상태를 버전으로 등록
git commit -m | 원하는 메세지와 함께 커밋
git commit -a | working directory에서 작업 중인 내용까지 모두(all) commit, 즉 staging area에 추가하지 않은 변경 사항도 commit한다. 단, 한번도 add 하지 않은 파일은 포함하지 않는다.
git show [원하는 커밋의 해쉬태그] | 하나의 커밋에 어떤 내용이 있는지 살펴본다
+) 커밋은 애플리케이션의 기능 단위로 묶어서 한다. Init, Add, Fix 등의 동사를 쓴다.
Log | version history & difference between versions
git log | 현재 branch의 모든 commit에 대한 히스토리를 최신순으로 확인할 수 있다.
git log -p | commit과 commit 사이의 차이점(diff)을 확인할 수 있다, patch.
+) git diff vs. git log -p
HEAD
- 새롭게 만들어지는 commit은 각각 자신의 이전 commit을 가리킨다(pointer). 서로를 가리키면서 이어진 commit의 줄기를 "branch"라고 한다.
- "HEAD" => current branch를 가리키고 있고, 다시 current branch => 가장 최근에 한 커밋, 또는 가장 최근에 working directory로 불러온 커밋을 가리킨다.
git log 파일명 | 파일이 포함되어 있는 commit만 확인
git log -s | short
git log -n | 최근 n개의 commit만 확인
git log -S "something" | 컨텐츠에 something이 포함된 commit만 확인, -p 옵션과 함께 쓰면 확인 용이
git log --author="someone" | someone이 작성한 commit만 확인
git log --before="yyyy-mm-dd" | 해당 날짜 이전의 commit만 확인
git log --grep="something" | 커밋 타이틀에 somethig이 포함되어있는 commit만 확인
git log --oneline | 해쉬코드와 메세지만 간단하게 확인, --reverse 옵션을 이용하면 커밋을 오래된 순으로 확인
git log --oneline --graph --all | 현재 branch가 어디에서 갈라져 나왔는지 쉽게 확인 가능
git log --pretty= format: "customization" | log의 format을 원하는 대로 수정 가능
- git config --global alias.hist " log --graph --all --pretty "를 이용해서 hist라는 명령어에 커스텀한 포맷으로 log를 볼 수 있도록 설정한다
git log 해쉬코드 | 코드에 해당하는 커밋과, 그 커밋 이전의 커밋들만 확인
git show 해쉬코드 | 코드에 해당하는 커밋의 내용을 확인, 해쉬코드:파일명이라고 작성하면 파일에 해당하는 내용만 확인 가능
Tag | semantic versioning
commit이 많아지면 git log 명령어를 이용해 모든 commit을 확인할 때, 가독성이 떨어진다. 이럴 때 semantic versioning을 이용해서 몇몇 커밋에 태그를 남길 수 있다.
v major.minor.fix | ex) v2.0.0
- major: 특정한 기능이 추가되었을 때
- minor: 새롭게 추가한 기능 중에서 일부가 업데이트, 개선되었을 때
- fix: 기존에 존재하는 기능의 오류를 수정했을 때, 성능이 개선되었을 때
git tag | 모든 태그 확인
git tag-l "v1.*" | list, v1.이 포함된 모든 태그 확인
git tag-d 태그이름| delete, 태그 삭제
git tag 태그이름 | current branch에 태그를 달 수 있다
git tag 태그이름 해쉬코드 | 코드에 해당하는 커밋에 태그를 달 수 있다
git tag 태그이름 해쉬코드 -am "버전에 관련된 정보" | annotate(추가)
- ex) git tag v.1.0.1 328708d -am "version information blablabla"
- git show 태그이름 | 해당 commit에 관련된 정보를 확인해 볼 수 있다
git checkout 태그이름 | 해당 태그로 체크아웃할 수 있다.
- "git checkout 해쉬코드"와 "git checkout branch"를 이용하면 각각 현재 branch가 가리키고 있는 커밋 또는 head가 가리키고 있는 current branch를 설정할 수 있다.
- 만약 어떤 커밋에서 갈라지는 새로운 branch를 만들어야 한다면, "git checkout -b branch이름 커밋의 태그"을 이용한다.
- ex) git checkout -b testing v2.0.0
git push origin 태그이름 | 서버에 태그를 연동(sync)
- git push origin tags | 모든 태그를 연동
git push origin --delete 태그이름 | 태그 삭제
Diff
working directory
git diff | Diffing is a function that takes two input data sets, and outputs the changes between them. These data sources can be commits, branches, files and more.
- git diff 해쉬코드1..해쉬코드2 | 두 커밋 사이의 모든 변경사항을 확인
- 만약 아무런 input 없이 git diff를 입력하면, 지금 내가 한 작업과, 그 작업 이전의 내용을 비교한다.
- 즉, working directory에서 수정 중인 파일(unstaged)을 이전 내용(staged or committed)과 비교해서 확인하고 싶다면 "git diff"를 이용할 수 있다. 이것은 내가 어떤 내용을 stage하기 전에, 현재 stage에 있는 이전의 버전과 비교하기 위한 최종 확인 용도로 사용된다.
- a.txt를 add한 뒤에(staged), diff 명령어를 이용하면, 아무 output도 없을 것이다.
+) "cat 파일명"을 이용하면 파일 안에 작성된 내용을 확인할 수 있다.
staging area
git diff --staged | staging area에 있는 모든 파일의 변경사항을 확인할 수 있다.
Difftool | vscode
"git config --global -e" 에서 변경 사항을 vscode에서 확인할 수 있도록 툴을 연결한다. 이제 "git difftool" 또는 "git difftool --staged"을 이용하면 연결된 툴에서 변경 사항을 확인할 수 있다. 참고로 변경된 내용이 없으면 아무 일도 안일어난다.
rm vs. git rm
만약 어떤 파일을 rm을 이용해서 삭제하면, 그 파일의 변경 사항을 add를 이용해 staging area로 옮겨야 변경 사항(파일 삭제)이 커밋에 포함될 수 있다.
git rm을 이용하면 따로 add를 이용하지 않더라도, 변경사항이 바로 staging area로 옮겨진다.
"mv style.css f.css"를 이용해서 파일의 이름을 변경하는 경우(style -> f)에도 동일하다.
Source tree | git UI
+) source tree를 이용하면 커밋을 line 단위로 쉽게, 직관적으로 할 수 있다.
'Study > Git & Github' 카테고리의 다른 글
| Stash (0) | 2022.04.13 |
|---|---|
| Branch & Merge (0) | 2022.04.11 |
| over view (0) | 2022.04.11 |
| What is Git & VCS? (0) | 2022.04.09 |
| Terminal & Command (0) | 2022.04.08 |
