티스토리 뷰

사용자 이름/메일 주소 설정


$ git config --global user.name "Firstname Lastname"

$ git config --global user.email "your_email@example.com"


위의 명령어를 입력하면 ~/.gitconfig에서 확인이 가능함.(해당 파일을 직접 편집해도 무관)



출력되는 명령어를 쉽게 읽을 수 있게 하는법


$ git config --global color.ui auto





git 기본 사용


  • git init: repository 초기화
  • git status: repository 상태 확인
  • git add: staging area에 파일 추가
    • ex) git add README.md
    • ex) git add *
  • git commit: repository 변경 내용 기록
    • 한줄의 커밋 메시지를 기록: ex) git commit -m "First commit"
    • 상세한 메시지를 입력하려면: ex) git commit       후에 에디터에서 수정 저장?
      • vim 에러뜰 때: git config --global core.editor /usr/bin/vim
  • git log: commit 확인 (현재 브랜치의 로그만 확인가능)
    • 자주 사용하는 log 옵션 예: git log --graph --pretty=oneline --all --decorate
    • 선택한 폴더나 파일의 로그만 출력: git log README.md
    • 파일의 변경된 내용을 출력: git log -p
    • 특정 파일의 로그와 변경 내용을 출력: git log -p README.md
  • git diff: 변경 내역 확인 (working tree, staging area, latest commit 사이의 변경을 확인할때)
    • working tree와 staing area의 차이 확인: git diff
      • + 기호가 붙은 부분이 추가된 줄
      • - 기호가 붙은 부분이 제거된 줄
    • working tree에서 최근에 변경된 부분을 확인(working tree와 최신 커밋사이의 차이)
      • git diff HEAD
        • git commit 커맨드 실행 전에 git diff HEAD 명령어를 실행하는 습관을 기르자. 이를 통해 현재 커밋과 이전 커밋의 차이를 한눈에 확인 가능.
          • HEAD: 현재 작업하고있는 브랜치의 최신 커밋을 참조하는 포인터

  • git branch: 브랜치를 보는 방법
    • 브랜치의 목록을 표시, 현재 어떤 브랜치를 사용하는지 확인 가능
  • git checkout -b: 브랜치 생성 및 변경
    • git checkout -b feature-A
      • 이는
        • git branch feature-A
        • git checkout feature-A
      • 와 같음
    • git checkout - : 한단계 전의 브랜치로 돌아가기

토픽 브랜치: 
하나의 토픽(주제)에만 집중하는 브랜치(다른 작업은 절대 하지않음). 
일반적으로 개발할 때에 여러 토픽 브랜치를 만들어 사용.

토픽 브랜치와는 별개로 언제라도 배포가능한 안정된 브랜치는 항상 준비해둠.(이것이 master)
feature같은 토픽 브랜치에서 관련된 개발이 완성되면 master와 다시 합쳐줌.


  • git merge: 브랜치 merge
    • ex) (현재 master branch인 상태에서) git merge --no-ff feature-A
      • 이렇게 브랜치로부터 merge하는 것을 기록으로 명확히 남기기위해 merge commit을 작성해야하고 옵션을 --no-ff를 주자.
      • 이는 feature-A 브랜치에서 merge된다는 것임.(master 브랜치ㅇㅔ feature-A 브랜치의 내용이 merge됨)

  • git reset: 과거 상태로 복원
    • git reset --hard: repository의 head, stage, working tree를 지정한 상태까지 복원
      • 모든 것이 이전 상태로 되돌아감.
      • ex) git reset --hard 4e2c17
  • git reflog: 현재 리포지토리에서 수행된 모든 commit로그를 확인 가능 (git log는 현재 브랜치의 로그만 확인가능)
    • 특정 커밋 시점의 해시를 찾을때 유용함.
    • 해시를 찾은 후에 git reset --hard 명령어로 찾은 해시를 입력하기만 하면 됨.
    • git을 실수로 잘못 사용하였을때  git reflog를 사용해서 원상태로 복원가능함!
      • 특정 해시를 찾아서, 이전에 reset으로 브랜치를 과거로 갔더라도 여기서 hash값을 찾으면 git reset --hard [hash값] 으로 상태를 복원이 가능하다.
    • 중요한 명령어이므로 기억할것

  • merge를 할 때 conflict가 난다면 파일을 열면 충돌 부분이 표시되있을 것임
    • =======  위의 부분이 현재 HEAD의 내용
    • 아래 부분이 이번에 merge 하려는 내용
    • 충돌 해결 후 add, commit을 한다

  • git commit --amend: 커밋 메시지 수정
    • 직전에 작성한 커밋의 메시지 수정을 원할 때
    • ex) git commit --amend
      • 라고 치면 에디터 뜨면서 커멘드 수정가능함
  • git commit -am: 짧은 변경의 경우 git add와 git commit을 실행할 필요없이 한번에 git commit -am 명령어 사용하는 것이 편리
    • ex) git commit -am "Add feature-C"

  • git rebase -i: 변경 내용 조작
    • 브랜치를 머지하기전에 이미 커밋된 내용에 철자 오류같은 것들이 있을 수 있다. 이런 경우 코드를 수정하고 커밋한뒤에 바로 앞의 commit에 합쳐버린다.
    • 철자 오류 같은 경우는 그렇게 중요한 변경이 아니기에 뭉개 버리는 것이다. 이는 자주 사용하는 기술이므로 알아두는게 좋다
    1. 첫번쨰 커밋을 한다.
    2.  그다음에 오타 수정후 두번쨰 커밋을 한다.
    3. 그후 rebase를 하는데, 
      • ex) git rebase -i HEAD~2       (이는 현재 브랜치의 HEAD(최신 cmommit)을 포함한 2개의 변경 내역과 관련된 내용이 에디터에 출력)
      • 이때 에디터에는  ex)
           pick 7a34294 Add feature-C
           pick 6fba227 Fix Typo
      • 와 같은 두개의 변경내역에 관련된 내용이 에디터에 표시된다.
    • 여기서 6fba227 'Fix typo'가 오타를 수정한 두번째 커밋인데, 이 변경 기록을 뭉개서 7a34294의 add feature-C에 넣어주도록 한다.
      • 에디터의 내용을 아래처럼 바꾼다. (뭉갤 커밋의 pick을 fixup으로)
           pick 7a34294 Add feature-C
           fixup 6fba227 Fix Typo
    • 이렇게 저장을하면 두개의 커밋이 하나로 합쳐진다.


  • git remote add: remote repository 등록
    • 로컬 리포를 리모트 리포에 등록할때 사용
    • ex) git remote add origin git@github.com:EminentStar/git-tutorial.git
      • 이렇게 git remote add를 하면 origin 이라는 식별자가 git@github.com:EmientStar/git-tutorijal.git을 가리키게됨
  • git push: remote repository 전송
    • 로컬 리포의 내용을 원격 리포에 전송하고자 할때 사용
    • ex) git push -u origin master
    • -u 옵션은 로컬 리포에 있는 현재 브랜치의 upstream(작업하고 잇는 현재 브랜치의 원래 상태를 의미)이 origin 리포지토리의 master 브랜치로 설정
      • 이 옵션을 사용하면 git pull을 사용할때 추가적인 옵션을 사용하지 않아도 로컬 리포지토리의 브랜치를 origin 리포지토리의 master 브랜치에서 받아올 수 있음.
  • master 브랜치 이외의 브랜치에 전송하고자 할 때?
    • git push -u origin feature-D
  • git clone: remote repository 가져오기
    • ex) git clone git@github.com:EminentStar/git-tutorial.git
      • (이렇게 하면 ssh 키 비밀번호를 물음)
      • 명령어가 수행된 후에는 master 브랜치가 해당 시점의 상태로 복사됨
      • 그리고 remote repository를 쉽게 참조할 수 있도록 origin 브랜치도 자동으로 설정됨 (origin 브랜치는 무엇일까?)
    • git branch -a : 현재 브랜치와 관련된 정보 확인 (로컬 리포 뿐만아니라 remote 리포틔 정보도 함께 표시됨)
    • remote repository의 브랜치를 체크아웃 하는 방법
      • ex) (현재 로컬엔 master가 있고, 원격에는 feature-D라는 브랜치가 있을때)
        • git checkout -b feature-D origin/feature-D
        • (-b 옵션 뒤에 입력하는 단어가 새로 작성하는 브랜치 이름)
        • (그 뒤에 또 원본이 되는 브랜치를 입력. origin이라는 식별자는 GitHub의 remote repository를 나타냄.)
  • git pull: latest remote repository를 가져오기
    • 로컬 리포에는 없는 리모트 리포의 새로운 내용을 로컬에 받아올때 사용
    • (현재 로컬 리포에서 feature-D 브랜치인 상태)git pull origin feature-D
      • 이렇게 되면 리모트 리포의 feature-D 브랜치가 로컬 브랜치 feature-D 브랜치에 업데이트 됨
    • 팀단위로 개발을 하면서 충돌이 자주 발생할 수 있으므로 수시로 push, pull해서 충돌을 줄이는게 좋음

----
그외 추가적인 참고자료
책: Pro Git
사이트: LearnGitBranching, tryGit


'형상관리' 카테고리의 다른 글

Bitbucket Private Repository를 ssh key를 이용하여 git clone 해오기  (0) 2016.10.13
기능변경과 외관변경을 분리하자  (0) 2016.10.12
GitHub Flow  (0) 2016.10.06
Pull Request  (0) 2016.10.04
git 기본 설정 및 기본 사용  (0) 2016.10.01
댓글
댓글쓰기 폼
공지사항
Total
67,089
Today
36
Yesterday
129
TAG more
«   2018/06   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
글 보관함