04. Git 명령어

[git커맨드의 사용법]
  > git help [알고 싶은 커맨드의 이름]
  > man git-[알고 싶은 커맨드]
  > 공식 메뉴얼 화면에서 나가고 싶으면 영어 단어 quit의 줄임말 q 입력 !

 

1. 기본 명령어

명령어	내용
git init	> 버전관리를 위한 초기 명령어 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성
git config user.name 'git'	> Commit 하기 전 필수 명령어 현재 사용자의 아이디를 'git'으로 설정(커밋할 때 필요한 정보)
git config user.email 'git@gmail.com'	> Commit 하기 전 필수 명령어 현재 사용자의 이메일 주소를 'git@gmail.com'로 설정(커밋할 때 필요한 정보)
git add [파일 이름]	수정사항이 있는 특정 파일을 staging area에 올리기
git add [디렉토리명]	해당 디렉토리 내에서 수정사항이 있는 모든 파일들을 staging area에 올리기
git add .	working directory 내의 수정사항이 있는 모든 파일들을 staging area에 올리기
git reset [파일 이름]	staging area에 올렸던 파일 다시 내리기
git status	Git이 현재 인식하고 있는 프로젝트 관련 내용들 출력(문제 상황이 발생했을 때 현재 상태를 파악하기 위해 활용하면 좋음)
git commit -m "커밋 메시지"	현재 staging area에 있는 것들 커밋으로 남기기

[주의사항]
  1) 처음으로 커밋을 하기 전 사용자의 이름과 이메일 주소 설정 필요
  2) 커밋 메시지 남기기 (옵션 -m)
  3) 커밋할 파일을 git add로 지정해주기

 

2. GitHub

  > 원격 레포지토리 or 리모트 레포지토리

명령어	내용
git remote add origin https://github.com/XX-dev/Sample.git git push -u(또는 --set-upstream) origin master	로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용 > --set-upstream > tracking 정보 설정   (tracking : 로컬 레포지토리의 한 브랜치가 리모트 레포지토리의 한 브랜치와 연결되어 그것을 계속 바라보는 상태가 되는 것, 이렇게 맺어진 연결 상태를 tracking connection이라고 함) > Git에서는 리모트 레포지토리를 최초로 추가할 때 origin이라는 이름으로 가리키는 것이 관례화 > --set-upstream(-u) 옵션을 주지 않으면 tracking connection이 없기 때문에 나중에 git push를 하고 싶을 때   git push origin master:master (origin은 리모트 레포지토리, master:master에서 더 먼저 나오는 master는 로컬 레포지토리의 master 브랜치(~에서) 더 뒤에 나오는 master는 리모트 레포지토리의 master 브랜치(~으로)를 나타냄)
git push	[로컬 레포지토리 > GitHub의 리모트 레포지토리] 위의 커맨드를 한번 실행하고 난 후에는 git push라고만 쳐도 로컬 레포지토리의 내용을 리모트 레포지토리에 올릴 수 있습니다.
git pull	[리모트 레포지토리 > 로컬 레포지토리] 바로 위의 위에 있는 커맨드를 한번 실행하고 난 후에는 git pull이라고만 쳐도 리모트 레포지토리의 내용을 로컬 레포지토리로 가져옵니다.
git clone [프로젝트의 GitHub 상 주소]	GitHub에 있는 프로젝트를 내 컴퓨터로 가져오기

tip) GitHub에서는 파일 이름이 README일 경우 내용을 바로 보여줌

     리모트 레포지토리를 만드는 이유 ? 1) 안정성(백업), 2) 협업 가능

      git push와 git pull은 작업 단위가 branch, 모든 branch 내용 전송 시 --all 옵션 사용 가능

 

3. Commit

명령어	내용
git log	commit history
git log --pretty=oneline	--pretty 옵션을 사용하면 커밋 히스토리를 다양한 방식으로 출력할 수 있습니다. --pretty 옵션에 oneline이라는 값을 주면 커밋 하나당 한 줄씩 출력해줍니다. > 모든 브랜치의 히스토리 보기   git log --pretty=oneline --all > 커밋 히스토리가 각 브랜치와의 관계가 잘 드러나도록 그래프 형식으로 출력   git log --pretty=oneline --all --graph
git show [커밋 아이디(커밋해시), 4자리 이상]	특정 커밋에서 어떤 변경사항이 있었는지 확인
git commit --amend	최신 커밋을 다시 수정해서 새로운 커밋으로 만듦
git config alias.[별명] [커맨드]	> git config alias.history 'log --pretty=oneline' 길이가 긴 커맨드에 별명을 붙여서 이후로는 별명으로도 해당 커맨드를 실행할 수 있게 설정
git diff [커밋 A(이전)의 아이디] [커밋 B(이후)의 아이디]	두 커밋 간의 차이 비교, 두 브랜치 간의 차이 보기 > 예) git diff master origin/master
git reset [옵션] [커밋 아이디]	옵션에 따라 하는 작업이 달라짐(옵션을 생략하면 --mixed 옵션이 적용됨) (1) HEAD가 특정 커밋을 가리키도록 이동시킴(--soft는 여기까지 수행) (2) staging area도 특정 커밋처럼 리셋(--mixed는 여기까지 수행) (3) working directory도 특정 커밋처럼 리셋(--hard는 여기까지 수행) 커밋 아이디 대신 HEAD의 위치를 기준으로 한 표기법(예 : HEAD^ - 바로 이전 커밋, HEAD~3 - 3단계 전 커밋)을 사용해도 됨 > HEAD : 어떤 커밋 하나를 가리킴 (보통 가장 최근에 한 커밋을 가리킴, 매번 더 새로운 커밋을 가리킴) > HEAD가 가리키는 커밋에 따라 working directory 구성 > HEAD~x : 현재 HEAD가 가리키는 커밋보다 x단계 전에 있는 커밋
git tag [태그 이름] [커밋 아이디]	> 예) git tag Version_1 abcd 특정 커밋에 태그를 붙임
git tag	프로젝트 디렉토리에 있는 모든 태그 조회 > 태그와 연결된 커밋이 보고 싶으면   git show [태그이름]

tip) -m 옵션 없이 git commit만으로 텍스트 에디터에 커밋 메시지 남기기 : 복잡하고 긴 커밋 메시지를 쉽게 남길 수 있다.

 

[커밋 메시지 작성 가이드라인]
  (1) 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두세요.
  ex ) Add one function

  test.py supports 2 functions now
  (2) 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 마세요.
  (3) 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성하세요.
  (4) 커밋 메시지의 제목은 명령조로 작성하세요.(Fix it / Fixed it / Fixes it)
  (5) 커밋의 상세 내용에는 이런 걸 적으면 좋습니다.
    > 왜 커밋을 했는지
    > 어떤 문제가 있었고
    > 적용한 해결책이 어떤 효과를 가지는지
  (6) 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성하세요. 

 

[커밋할 때 알아야할 가이드라인]
  (1) 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 하세요. 다양하게 수정을 하고나서 하나의 커밋으로 남기는 것은 좋지 않습니다. 하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽습니다. 
  (2) 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하도록 하세요. 나중에 동료 개발자가 특정 커밋의 코드로 실행했을 때 에러가 발생한다면 혼란을 줄 수 있습니다.

 

4. Branch

  > 하나의 코드 관리 흐름

  > branch는 commit을 가리키는 pointer, HEAD는 이런 branch를 통해 commit을 간접적으로 가리키는 pointer

     (HEAD > branch > Working directory)

명령어	내용
git branch	현재 모든 브랜치 보기
git branch [새 브랜치 이름]	새로운 브랜치를 생성
git checkout -b [새 브랜치 이름]	새로운 브랜치를 생성하고 그 브랜치로 바로 이동
git branch -d [기존 브랜치 이름]	브랜치 삭제
git checkout [기존 브랜치 이름]	그 브랜치로 이동
git merge [기존 브랜치 이름]	현재 브랜치에 다른 브랜치를 머지 예) test branch에서 git merge master > 커밋 메시지
git merge --abort	머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아감

[Conflict]

  > Base 내용과 비교 시 달라진 부분이 우선시 되고, 두 브랜치에서 둘다 변화가 일어난 경우 Conflict 발생

  > Merge를 하다가 충돌일 발생한 경우

    1) Conflict가 발생한 파일 열기

    2) Merge의 결과가 되었으면 하는 모습으로 코드 수정

    3) Commit

 

(용어)

  > merge commit : 머지를 통해서 생겨난 커밋

  > Fast-forward Merge : 새로운 커밋이 생기는 게 아니라 단지 브랜치가 이동하게 되는 머지

                                 (커밋 히스토리에서 같은 선(line) 상에 있는 브랜치를 머지할 때)

  > 3-way Merge

    (1) 두 갈래로 갈라지기 전 공통 조상이 되는 커밋

    (2) 한 브랜치가 가리키는 커밋

    (3) 다른 브랜치가 가리키는 커밋

 

5. git reset VS git checkout

git reset [커밋아이디]	git checkout [커밋아이디
HEAD가 가리키던 브랜치가 다른 커밋을 가리키도록 한다. HEAD 자체가 다른 커밋이나 브랜치를 가리키도록 한다	HEAD도 결국 간접적으로 다른 커밋을 가리키게되는 효과가 생긴다. 브랜치를 통하지 않고, 커밋을 직접적으로 가리키는 HEAD를 Detached HEAD라고 한다.

 

6. other command

명령어	내용
git fetch	로컬 레포지토리에서 현재 HEAD가 가리키는 브랜치의 업스트림(upstream) 브랜치로부터 최신 커밋들을 가져옴(가져오기만 한다는 점에서, 가져와서 머지까지 하는 git pull과는 차이가 있음)
git blame git show [커밋아이디]	특정 파일의 내용 한줄한줄이 어떤 커밋에 의해 생긴 것인지 출력
git revert [커밋 아이디]	특정 커밋에서 이루어진 작업을 되돌리는(취소하는) 커밋을 새로 생성 (이미 리모트 레포지토리에 올라간 커밋을 취소해야 할 때) > 여러 커밋 취소하기   git revert abcd..aaa1 (abcd 커밋은 포함되지 않음)   git push로 반영
git reflog	HEAD가 그동안 가리켜왔던 커밋들의 기록을 출력 (git reset을 잘못한 경우 참고)
git log --all --graph	모든 브랜치의 커밋 히스토리를, 커밋 간의 관계가 잘 드러나도록 그래프 형식으로 출력
git rebase [브랜치 이름]	A, B 브랜치가 있는 상태에서 지금 HEAD가 A 브랜치를 가리킬 때, git rebase B를 실행하면 A, B 브랜치가 분기하는 시작점이 된 공통 커밋 이후로부터 존재하는 A 브랜치 상의 커밋들이 그대로 B 브랜치의 최신 커밋 이후로 이어붙여짐(git merge와 같은 효과를 가지지만 커밋 히스토리가 한 줄로 깔끔하게 된다는 차이점이 있음) > git rebase --continue : Conflict가 발생해서 제대로 진행되지 못한 rebase를 계속 진행해라
git stash	현재 작업 내용을 스택 영역에 저장 > 최근 커밋 이후로 작업했던 내용은 모두 스택에 옮겨지고 working directory 내부는 최근 커밋 상태로 초기화
git stash list	작업 내용 조회(스택 목록 확인)
git stash apply [커밋 아이디]	스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용
git stash drop [커밋 아이디]	스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 스택에서 삭제
git stash pop [커밋 아이디]	스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용하면서 스택에서 삭제
git cherry-pick [커밋 아이디]	특정 커밋의 내용을 현재 브랜치에 추가

예) 잘못된 브랜치에서 작업을 한 경우

  > test 브랜치에서 해야할 작업을 master 에서 했다면?

  > master에서 git stash (Stack 저장)

  > git checkout test (이동)

  > git stash list (Stack 확인)

  > git stash apply stash@{0}

  > conflict 해결 후 git add.

  > git commit -m "Modify xx function"

  > git stash drop stash@{0}