Git
git-scm.com
Git - Book
git-scm.com
* Git 저장소를 Saas 형태로 service : GitHub / Gitlab / Gitbucket
사용자 정보 등록
$ git config --global user.name "Jisoo"
$ git config --global user.email Jisoo@example.com
저장소 만들기
- 빈 로컬 저장소 생성
- 원격 저장소를 가져오기
1. 버전관리를 하지 않는 로컬 디렉토리
mkdir mygit
cd mygit
local 저장소로 지정
git init
2. 기존 Git 저장소 클론 (Remote Repository를 가져옴)
git clone <URL>
3. Remote 저장소
git remote
git remote -v
git remote add <NAME> <url>git - 간편 안내서 - 어렵지 않아요!
rogerdudler.github.io
git init
git add .
git commit -m 'Message'
git branch -M main #사용중인 (master) branch를 main으로 이름변경 (M:강제로)
git remote add origin
git remote add origin <url>
git remote -v
git push -u origin main
git fetch <BRANCH_NAME>git pull
git branch <BRANCH_NAME>git checkout master해당 branch가 없으면 만들고 이동
git checkout -b <BRANCH_NAME>git branch -d <BRANCH_NAME>⭐ Git 프로젝트의 세 가지 상태
⭐ 파일의 생명주기
상태 확인
git status
스테이징 (<FILE>을 추적할 수 있게 stage에 등록)
git add <FILE>
git add .
.gitignore 파일
- 아무것도 없는 라인이나, #로 시작하는 라인은 무시한다.
- 표준 Glob 패턴을 사용한다. 이는 프로젝트 전체에 적용된다.
- 슬래시(/)로 시작하면 하위 디렉토리에 적용되지(Recursivity) 않는다.
- 디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다.
- 느낌표(!)로 시작하는 패턴의 파일은 무시하지 않는다.
# 확장자가 .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/**/*.pdfStaged와 Unstaged 상태 변경 내용 보기
staged 상태가 아닌 파일 비교
git diff
커밋과 staged 상태 비교
git diff --staged
변경사항 커밋(버저닝, 스냅샷) : .git 에 등록 (git-log)
git commit
* 의미있는 단위로 쪼개서 commit 하기 (atomic)
태그 붙이기
git tag -a <TAG_NAME> -m "Message"git config --global core.editor <EDITOR>인라인 메시지 (비추/더 자세히 쓰도록)
git commit -m <MESSAGE>
스테이징 및 인라인 메시지
git commit -a -m <MESSAGE>
- 좋은 Commit 메시지를 쓰는 방법
https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53
Commit message guidelines
Commit message guidelines. GitHub Gist: instantly share code, notes, and snippets.
gist.github.com
#제목(동사 - 현재형 & 명령형 & 마침표 사용x)
Short (72 chars or less) summary
#본문(72자 넘어가면 새로운 문장으로 작성)
More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).
Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
generated by commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too.
- Typically a hyphen or asterisk is used for the bullet, followed by a
single space. Use a hanging indent.- Describe why a change is being made.
- How does it address the issue?
- What effects does the patch have?
- Do not assume the reviewer understands what the original problem was.
- Do not assume the code is self-evident/self-documenting.
- Read the commit message to see if it hints at improved code structure.
- The first commit line is the most important.
- Describe any limitations of the current code.
- Do not include patch set-specific comments.
파일 삭제
rm <FILE>
삭제한 파일 Staged 상태
git rm <FILE>
파일명 변경
git mv <ORGION> <NEWFILE>
커밋 히스토리/로그
git log
git log --onelinegit config --global core.pager 'less'
git config --global core.pager ''
되돌아가기
최근 commit 상태로 되돌아가기 (너무 일찍 커밋했거나 어떤 파일을 빼먹었을 때 또는 커밋 메시지를 잘못 적었을 때)
다시 커밋하고 싶으면 파일 수정 작업을 하고 Staging Area에 추가한 다음 --amend 옵션을 사용하여 커밋을 재작성
git commit --amend
특정 시점으로 돌아가기 ( branch name 시점)
git checkout <BRANCH_NAME>* checkout은 restore,revert 등의 다양한 기능을 포함하고 있음 (checkout의 주 기능 : branch/commit 이동 시 사용)
(checkout이 먼저 있었고 그 이후에 기능을 세분화하기 위해 restore 등의 명령어가 생김)
merge
git checkout master #merge 하고자 하는 branch로 이동 후
git merge <BRANCH_NAME>
