• Clone

    • 리모트 서버의 repository클라이언트로 파일을 복붙하는 행위
  • Pull

    • 사용자가 서버의 소스를 자신의 클라이언트로 가져오는 행위
    • 리모트 서버의 최신 소스를 가져와서 로컬 소스에 병합(Merge)해주는 명령어
  • Fetch

    • 리모트 서버의 최신 이력을 내 클라이언트로 가져오지만 병합은 하지 않는다.
  • Add

    • 변경된 사항을 스테이지에 올리는 행위
  • Commit

    • 변경된 사항을 확정하는 행위이다.
    • 하나의 커밋은 하나의 버전으로 정의된다.
    • 커밋의 기능을 제대로 활용하기 위해 커밋은 반드시 실행 가능한 단위로 이뤄지도록 한다.
      • 특정 커밋으로 버전을 변경했을 때 어플리케이션이 비정상적으로 동작하면 안 된다는 것
    • 좋은 커밋 메세지를 작성하기 위한 고민은 필수
      • 변경 사항이 무엇인지 직접적으로 표현해주는 유일한 수단이다.
  • Push

    • 확정된 변경 사항을 원격 저장소에 적용하는 행위
  • Cherry Pick

    • 다른 브랜치에서 어떤 하나의 커밋만 내 브랜치로 가져오는 기능
    • 대상 브랜치의 커밋 하나를 가져와서 현재 브랜치에 병합 행위라고 느껴질 수 있으나, 히스토리를 보면 병합되는 그림이 아니라 그냥 해당 커밋을 그대로 복사해와서 내 브랜치에 커밋되는 형태로 기록된다.
    • 현재 배포를 해야하는 상황에서, 다른 브랜치의 특정 기능만을 가져와 배포를 하고 싶을 경우에 유용하다.
  • Stash

    • 현재 작업 중인 변경 사항들을 잠시 스택에 저장할 수 있는 명령어
    • 아직 마무리되지 않은 작업이 있는데 다른 브랜치로 체크아웃 해야하는 경우에 유용하게 사용할 수 있다.
    • 스태쉬의 이름을 지정하지 않으면 스택에 들어간 순서(First In Last out)대로만 스태쉬를 가져올 수 있으므로 왠만하면 이름을 지정하는 것을 추천.
    • 사용 의의
      • 긴급한 버그 픽스 건이 들어온다거나 아니면 PO들이 이슈의 우선 순위를 다시 정리하면서 기존에 작업을 하고 있던 브랜치에서 다른 브랜치로 건너가야하는 경우는 꽤나 빈번하게 발생한다.
      • 이때 다른 브랜치로 넘어가기위해 작업하던 것을 그대로 커밋하게 되면 해당 브랜치에서 함께 개발하고 있는 다른 팀원들에게 피해가 갈 수 있으니 반드시 변경 사항을 스태쉬하도록 하는 것이 좋다.
  • Reset

    • 지정한 커밋 당시로 돌아가는 것.
    • 리셋을 할 경우, 지정한 커밋 이후의 히스토리는 모두 사라지게 된다.
      • reset 명령어를 사용할 때 3개의 옵션을 사용 가능한 옵션:
        • hard: 지정한 커밋 이후의 히스토리가 삭제되고 삭제된 내용들은 그대로 사라진다.
        • soft: 지정한 커밋 이후의 히스토리가 삭제되고 삭제된 내용들은 스테이지로 이동한다. (add한 상태로 변경)
        • mixed: 지정한 커밋 이후의 히스토리가 삭제되고 삭제된 내용들은 스테이지에 올라가지 않은 상태가 된다. (다시 add 해줘야 함)
      • 만약 이미 되돌리고자 하는 히스토리가 리모트 저장소에 푸쉬까지 된 상태라면 리셋 후 히스토리를 푸쉬할 때 --force 옵션을 사용해야한다.
        • Commit 과 push 를 헷갈리지 말자.
        • "푸쉬까지 된 상태"는 로컬에서의 commit 이 된 상태가 아닌, 서버에 변경사항이 모두 적용이 완료된 상태임을 의미한다.
  • Revert

    • 히스토리를 다시 되돌리고 싶을 때 사용하는 명령어.
    • 리셋이 지정한 커밋 이후의 모든 히스토리를 없애버렸다면 리벗은 특정 커밋의 변경 사항을 되돌리는 기능을 한다.
    • 이때 해당 커밋을 되돌린다고 해서 히스토리에서 그 커밋을 삭제하는 것이 아니라, 되돌리고자 하는 커밋의 내용을 반전시킨다.
    • 리벗은 리셋과 다르게 히스토리를 삭제하지 않고 하나의 커밋이 추가되는 형태로 히스토리가 남는다.
  • Rebase

    • 커밋 히스토리를 재구성(rewrite)하도록 한다.
      • 히스토리를 깔끔하게 정리하거나, 브랜치를 통합하는 과정에서 주로 사용한다.
      • rebase 모드로 진입하여, 현재 작업 디렉토리가 리베이스 작업을 완료하거나 중단하기 전까지 "리베이스 중"인 상태가 된다.
    • git rebase -i 명령어를 주로 사용한다.
      • i는 --interactive의 약자로 interactive 모드를 활성화한다.
      • rebase 과정에서 커밋에 대하여 선택적으로 수정, 삭제, 병합, 순서 변경이 가능해진다.
    • 범위 지정은 다음과 같이 할 수 있다.
      • 최근 3개의 커밋을 대상으로 rebase 수행
        • git rebase -i HEAD~3
      • 최근 커밋부터 지정한 커밋(exclusive임에 주의)까지 rebase 수행
        • git rebase -i m0n1o2p
    • interactive 모드 활성화 시 다음의 작업이 가능하며, vi 텍스트 편집기로 명령어를 입력한다.
      • pick
        • 기본값으로 해당 커밋을 그대로 유지한다.
      • reword
        • 해당 커밋의 메시지만 수정
      • edit
        • 해당 커밋의 메시지와 내용 수정
        • 작성자 수정하는 예시
          • edit a1b2c3d message1
          • git commit --amend --author="Jisu Kim [email protected]"
      • squash
        • 해당 커밋을 이전 커밋과 병합하고 커밋 메시지 수정
        • 첫 번째 커밋으로 병합하는 예시
          • pick a1b2c3d message1 -> 첫 번째 커밋인 a1b2c3d을 (rebase 후에도 남아있는) 최종 커밋으로 간주
          • squash d4e5f6g message2 -> d4e5f6g 커밋의 변경 사항을 a1b2c3d 커밋에 병합
          • squash h7i8j9k message3 -> h7i8j9k 커밋의 변경 사항을 a1b2c3d 커밋에 병합
      • fixup
        • 해당 커밋을 이전 커밋과 병합하되, 커밋 메시지는 버림
      • drop
        • 해당 커밋 삭제
      • exec
        • 리베이스 도중에 특정 스크립트 실행
    • rebase 결과물이 푸시와 상충할 경우, 강제 옵션을 적용하도록 한다.