티스토리 뷰

728x90
반응형

git init 

👉🏻 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성

git init

 

git config user.name '이름'

👉🏻 현재 사용자의 아이디를 '이름'으로 설정(커밋할 때 필요한 정보)

git config user.name 'Zoe'

 

git config user.email '이메일주소' 

👉🏻 현재 사용자의 이메일 주소를 '이메일주소'로 설정(커밋할 때 필요한 정보)

git config user.email 'zoe@email.com'

 

git add [파일 이름] 

👉🏻 수정사항이 있는 특정 파일을 staging area에 올리기

git add test.txt

 

git add [디렉토리명] 

👉🏻 해당 디렉토리 내에서 수정사항이 있는 모든 파일들을 staging area에 올리기 

git add directory/

 

git add . 

👉🏻 working directory 내의 수정사항이 있는 모든 파일들을 staging area에 올리기

git add .

 

git reset [옵션] [파일 이름] 

👉🏻 staging area에 올렸던 파일 다시 내리기

👉🏻 커밋 아이디 대신 HEAD의 위치를 기준으로 한 표기법(예 : HEAD^, HEAD~3)을 사용해도 됨

👉🏻 옵션에 따라 하는 작업이 달라짐(옵션을 생략하면 --mixed 옵션이 적용됨)

👉🏻 옵션 종류 : --soft, --mixed, --hard

     (1) HEAD가 특정 커밋을 가리키도록 이동시킴(--soft는 여기까지 수행)

     (2) staging area도 특정 커밋처럼 리셋(--mixed는 여기까지 수행

     (3) working directory도 특정 커밋처럼 리셋(--hard는 여기까지 수행)

👉🏻 hard를 해서 과거의 커밋으로 돌아갔다고 해도 그 이후의 커밋이 삭제되는 것은 아님

👉🏻 아이디만 알고 있으면 다시 이후의 커밋으로 돌아갈 수 있음

더보기

< 쓸데없는 커밋 삭제하기 >

커밋한 것을 수정한 후에 다시 커밋할 때, 처음 커밋한 내용이 필요없다면 

git reset을 사용해보자!

 

1. git reset --soft xxxx  

ㄴ 워킹디렉토리는 남겨두고 히스토리만 없애기

2. git add . 

ㄴ 워킹디렉토리 내역 반영하기

3. git commit - m "필요없는 커밋을 삭제해 히스토리가 깔끔해지지롱~" 

 

git status 

👉🏻 Git이 현재 인식하고 있는 프로젝트 관련 내용들 출력(문제 상황이 발생했을 때 현재 상태를 파악하기 위해 활용하면 좋음) 

git status

 

git commit -m "커밋 메시지" 

👉🏻 현재 staging area에 있는 것들 커밋으로 남기기

👉🏻 커밋 메세지를 길게 작성하고 싶을 경우 접은글 확인

git commit -m "first commit"
더보기

< m 옵션 없이도 커밋 메세지 남기는 법 - mac의 vim 기준>

1. git commit 만 입력하면 커밋 메세지를 입력할 수 있는 창이 뜸

2. i를 눌러 글쓰기

3. 커밋 메세지 작성

4. esc 눌러 글쓰기 종료

5. :wq 입력 후 엔터

 

 

< 커밋 메세지 작성 가이드라인 >

1. 첫번째 줄에 짧게 한줄로 커밋 메세지 제목을 적어준다.

ㄴ 제목 뒤에 . 붙이지 말기

ㄴ 제목의 첫번째 알파벳을 대문자로

ㄴ 제목은 명령조로 작성

2. 한 줄을 비운 뒤, 상세 설명을 입력한다.

ㄴ상세 내용에는 왜 커밋을 했고, 어떤 문제가 있었고, 적용한 해결책이 어떤 효과를 가는지 등을 적어주면 좋음

 

 

< 커밋할 때 알아야할 가이드라인 >

1. 하나의 커밋에는 하나의 수정사항(이슈)를 해결한 내용만 남기도록 하기

ㄴ 너무 많은 작업을 하고 커밋하지 말기!

2. 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하도록 하기

ㄴ 과거 버전의 프로그램을 사용하거나, 과거의 커맷으로 리셋할 경우가 생김!

3. 커밋 메세지는 잘 작성하기

ㄴ 나중에 다시 봐도 이해할 수 있도록

ㄴ 협업하는 개발자가 봐도 이해할 수 있도록

 

git help [커맨드 이름] 

👉🏻 사용법이 궁금한 Git 커맨드의 공식 메뉴얼 내용 출력

👉🏻 'man git-[알고싶은 커맨드 이름]' 이렇게 입력해도 됨  

git help add
man git-add

 

git push -u(또는 --set-upstream) origin master 

👉🏻 로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용

git push -u origin master

 

git push 

👉🏻 위의 커맨드를 한번 실행하고 난 후에는 git push라고만 쳐도 로컬 레포지토리의 내용을 리모트 레포지토리에 올릴 수 있음

git push

 

git pull 

👉🏻 바로 위의 위에 있는 커맨드를 한번 실행하고 난 후에는 git pull이라고만 쳐도 리모트 레포지토리의 내용을 로컬 레포지토리로 가져옴

git pull

 

 

git fetch

👉🏻 로컬 레포지토리에서 현재 HEAD가 가리키는 브랜치의 업스트림(upstream) 브랜치로부터 최신 커밋들을 가져옴

👉🏻 가져오기만 한다는 점에서, 가져와서 머지까지 하는 git pull과는 차이가 있음

더보기

머지하기 전에 한번 점검하고 싶을 때 사용하거나,

리모트 레포지토리에 있는 브랜치의 내용과 내가 작성한 코드를 비교해서 검토하고 싶을 때 사용

(이때 diff랑 같이 사용하면 좋음!)

 

 

< 검토할 때 : 브랜치명은 premium >

1. git fetch

2. git diff premium origin/premium 

 

 

※ 리모트 레포지토리의 브랜치에 문제가 있을 때 해결 방법

1. 잘못된 코드를 추가한 개발자에게 함수를 지우고 다시 리모트 레포지토리에 올려달라고 하기

2. 잘못된 부분을 알아서 해결하고 다시 git push 하기

 

git clone [프로젝트의 GitHub 상 주소] 

👉🏻 GitHub에 있는 프로젝트를 내 컴퓨터로 가져오기

git clone https://github.com/zzzzoe2/-

 

git log 

👉🏻 커밋 히스토리를 출력

👉🏻 가장 오래된 커밋이 제일 밑에 출력 되고, 위로 올라갈수록 더 최근에 한 커밋을 나타냄 

👉🏻 커밋 아이디, 커밋을 한 사람, 커밋한 시간, 커밋 메세지 확인 가능

👉🏻 커밋 아이디는 해시로 표현이 되어 커밋해시라고도 함

git log

 

git log --pretty=oneline 

👉🏻 --pretty 옵션을 사용하면 커밋 히스토리를 다양한 방식으로 출력할 수 있음

👉🏻 --pretty 옵션에 oneline이라는 값을 주면 커밋 하나당 한 줄씩 출력해줌(커밋아이디와 커밋메세지만 출력됨)

👉🏻 --pretty 옵션에 대해 더 자세히 알고싶으면 이 링크를 참고 

git log --pretty=oneline

 

git show [커밋 아이디] 

👉🏻 특정 커밋에서 어떤 변경사항이 있었는지 확인

👉🏻 커밋 아이디는 앞에 네자리만 써도 됨 (단, 네자리가 중복되면 안됨)

👉🏻 빨간 부분은 이전 커밋, 초록 부분은 해당 커밋을 나타냄

git show xxxx

 

git commit --amend 

👉🏻 최신 커밋을 다시 수정해서 새로운 커밋으로 만듦

👉🏻 이 명령어 사용시 커밋 메세지를 입력할 수 있는 창이 뜸

👉🏻 이렇게 하면 커밋 히스토리를 줄일 수 있음

git commit --amend

 

git config alias.[별명] [커맨드] 

👉🏻 길이가 긴 커맨드에 별명을 붙여서 이후로는 별명으로도 해당 커맨드를 실행할 수 있게 설정

git config alias.history 'log --pretty=oneline'
더보기

로그를 알록달록하게 꾸며보자!

git config --global alias.l "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%C(bold blue)<%an>%Creset' --abbrev-commit"

 

참고문서 : https://johngrib.github.io/wiki/git-alias/

 

git diff [커밋 A의 아이디] [커밋 B의 아이디] 

👉🏻 두 커밋 간의 차이 비교

👉🏻 A에 더 과거 커밋 아이디를 적어주기

git diff aaaa bbbb

 

git tag [태그 이름] [커밋 아이디] 

👉🏻 특정 커밋에 태그를 붙임 (show 명령어를 실행할 때 아이디대신 태그이름을 적어주면 됨)

👉🏻 태그 조회 시, git tag만 입력하면 됨

👉🏻 특히 그 의미가 중요한 커밋들은 태그 달아주면 나중에 프로젝트 파악할 때 도움됨!

git tag version_1 xxxx

 

git branch [새 브랜치 이름] 

👉🏻 새로운 브랜치를 생성

git branch premium

 

 

git checkout [기존 브랜치 이름] 

👉🏻 그 브랜치로 이동

git checkout premium
더보기

git checkout [커밋아이디] 를 하게 되면,

master를 가리키고 있던 HEAD가 checkout한 커밋아이디를 가리킴. (Detached HEAD)

 

과거의 커밋에서 브런치를 생성하고 싶을 때 주로 사용

 

 

< git reset vs git checkout >

-git reset

👉🏻 HEAD가 가리키던 브랜치가 다른 커밋을 가리키도록 한다.

👉🏻 HEAD도 결국 간접적으로 다른 커밋을 가리키게되는 효과가 생긴다.

 

- git checkout

👉🏻 HEAD 자체가 다른 커밋이나 브랜치를 가리키도록 한다.

👉🏻 브랜치를 통하지 않고, 커밋을 직접적으로 가리키는 HEAD를 Detached HEAD라고 한다.

 

 

 

 

git checkout -b [새 브랜치 이름] 

👉🏻 새로운 브랜치를 생성하고 그 브랜치로 바로 이동

git checkout -b test

 

git branch -d [기존 브랜치 이름] 

👉🏻 브랜치 삭제

git branch -d test

 

git merge [기존 브랜치 이름] 

👉🏻 현재 브랜치에 다른 브랜치를 머지

git merge master
더보기

< merge 종류 >

👉🏻 Fast-forward 머지

👉🏻 3-way 머지

 

git merge --abort 

👉🏻 머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아감

git merge --abort

 

git blame 

👉🏻  특정 파일의 내용 한줄한줄이 어떤 커밋에 의해 생긴 것인지 출력 

👉🏻  어떤 파일의 특정 코드를 누가 작성했는지 찾아낼 때 쓰기도 함 (git show 사용해도 됨)

git blame

 

git revert 

👉🏻 특정 커밋에서 이루어진 작업을 되돌리는(취소하는) 커밋을 새로 생성

git revert aaaa..bbbb

(aaaa 커밋은 포함되지 않음)

 

git reflog 

👉🏻 HEAD가 그동안 가리켜왔던 커밋들의 기록을 출력

git reflog
더보기

git reset --hard를 사용해서 과거로 돌아온 상태에서,
다시 이후 커밋으로 이동하고 싶은데 아이디를 모를 때 사용

 

git log --all --graph 

👉🏻 모든 브랜치의 커밋 히스토리를, 커밋 간의 관계가 잘 드러나도록 그래프 형식으로 출력

👉🏻 'git log --all'만 치면 그래프없이 모든 히스토리가 나타남

git log --all --graph

 

git rebase [브랜치 이름] 

👉🏻 A, B 브랜치가 있는 상태에서 지금 HEAD가 A 브랜치를 가리킬 때, 'git rebase B'를 실행하면 A, B 브랜치가 분기하는 시작점이 된 공통 커밋 이후로부터 존재하는 A 브랜치 상의 커밋들이 그대로 B 브랜치의 최신 커밋 이후로 이어붙여짐(git merge와 같은 효과를 가지지만 커밋 히스토리가 한 줄로 깔끔하게 된다는 차이점이 있음)

git rebase test       
git rebase --continue (conflict가 발생해서 제대로 진행되지 못할 때 사용)
더보기

< merge vs rebase >

- merge : 두 브랜치를 합쳤다는 정보가 커밋 히스토리에 꼭 남아야 하는 경우 사용

 

 

- rebase : 커밋 히스토리를 깔끔하게 유지하는게 더 중요한 경우 사용

 

git stash 

👉🏻 현재 작업 내용을 스택 영역에 저장

👉🏻 git stash 쓰는 상황은 접은글 참고

git stash
더보기

git stash 쓰는 상황은?

- 어떤 브랜치에서 하던 작업을 아직 커밋하지 않았는데, 다른 브랜치로 가야하는 상황에서 작업 중이던 내용을 잠깐 저장하고 싶을 때 사용

- 잘못된 브랜치에서 작업하고 있을 때 사용

 

 

git stash list

👉🏻 스택 영역에 저장된 것들을 모두 보여줌

👉🏻 작업 내용의 아이디 확인 가능

git stash list

 

git stash apply [작업 내용의 아이디] 

👉🏻 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용

👉🏻 아이디를 적지 않으면 가장 위에 있는 내용을 가져옴 

git stash apply stash@{0}

 

git stash drop [작업 내용의 아이디] 

👉🏻 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 스택에서 삭제

👉🏻 아이디를 적지 않으면 가장 위에 있는 내용을 가져옴

git stash drop stash@{0}

 

git stash pop [작업 내용의 아이디] 

👉🏻 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용하면서 스택에서 삭제

👉🏻 아이디를 적지 않으면 가장 위에 있는 내용을 가져옴

git stash pop stash@{0}

 

git cherry-pick [커밋 아이디] 

👉🏻 특정 커밋의 내용을 현재 커밋에 반영

git cherry-pick xxxx

 

728x90
반응형
댓글