Git

Jnnsu·2023년 12월 3일
1
post-thumbnail

Git이란?

Git은 리누스 토발즈(Linus Torvalds)가 만든 코드 버전 관리 프로그램이다.

버전 관리를 하는 이유

  • 지난 과정 확인 가능
  • 이전 버전으로 돌아갈 수 있음

Git 기본 사용 방법

✅1. Working Directory 설정

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

✅2. GIT 초기 설정(작성자, 이메일)

  • git config user.name 'codeit' : 현재 사용자의 아이디를 'codeit'으로 설정(커밋할 때 필요한 정보)
  • git config user.email 'teacher@codeit.kr' : 현재 사용자의 이메일 주소를 'teacher@codeit.kr'로 설정(커밋할 때 필요한 정보)
  • git config alias.[이름] ‘[명령어]’ : 명령어 단축키 만들기

✅3. Branch 설정

  • branch 생성, 삭제

    • git branch [새 브랜치 이름]: 새로운 브랜치를 생성
    • git branch -d [기존 브랜치 이름]: 브랜치 삭제
  • HEAD 이동
    Detached HEAD

    • git checkout [기존 브랜치 이름]: 그 브랜치로 이동
    • git checkout -b [새 브랜치 이름]: 새로운 브랜치를 생성하고 그 브랜치로 바로 이동
  • 병합

    • merge

      • git merge [기존 브랜치 이름]: 현재 브랜치에 다른 브랜치를 병합
      • git merge --abort: 머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아감

        merge 중 Conflict가 발생했다면?

        1. 파일 하나씩 conflict를 해결하고 git add [파일 이름] 커맨드로 하나씩 staging area에 올리거나(중간중간에 git status 커맨드로 현재 상태 확인하면서) 모든 파일들의 Conflict를 다 해결하고, git add . 커맨드로 한번에 staging area에 올리고 커밋을 하면 된다.
        2. git merge —abort : merge 취소하기
          -> 언제 사용?
          Conflict가 발생한 파일들이 너무 많아서 Conflict를 최소화할 수 있는 방식으로 파일들을 다시 수정하고 커밋한 다음에 머지를 하고 싶다거나 그냥 좀더 나중에 머지하고 싶을 때
    • rebase

      • git rebase : 두 브랜치가 있을 때, 그 두 브랜치가 갈라진 지점 이후부터 한 브랜치에서 했던 커밋들을 다른 브랜치의 최신 커밋 이후로 그대로 이어붙이는 모양의 커밋 히스토리를 만들어준다.
    • merge vs rebase

      • merge : 두 브랜치를 합쳤다는 정보가 커밋 히스토리에 꼭 남아야 하는 경우
      • rebase : 커밋 히스토리를 깔끔하게 유지하는 게 더 중요한 경우

✅4. Untracked → Tracked → Staging area

  • Staging Area에 올리기
    • git add [파일 이름] : 수정사항이 있는 특정 파일을 staging area에 올리기
    • git add [디렉토리명] : 해당 디렉토리 내에서 수정사항이 있는 모든 파일들을 staging area에 올리기
    • git add . : working directory 내의 수정사항이 있는 모든 파일들을 staging area에 올리기
  • Staging Area에서 내리기
    • git reset [파일 이름] : staging area에 올렸던 파일 다시 내리기

✅5. 어떤 파일이 staging area에 있는지 확인

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

    staging area에 있던 것들은 커밋하고 나면 어떻게 될까?

    그냥 그 상태 그대로 남아있다. 커밋을 했다고 staging area가 초기화되거나 하지는 않는다. 계속 git add를 할 때마다 staging area에서는 새로운 파일이 추가되거나 원래 있던 파일이 더 새로운 버전의 것으로 교체되거나 할 뿐이다.

✅6. 커밋하기

  • git commit -m "커밋 메시지" : 현재 staging area에 있는 것들 커밋으로 남기기
  • git commit

✅7. 작업 내용 관리하기

  • git stash : 작업 내용 저장
  • git stash list : 작업 내용 조회(=스택 살펴보기)
  • git stash apply [작업 내용의 아이디] : 작업 내용 적용 - 작업 내용의 아이디를 생략하면 가장 최근의 작업 내용이 적용됨
  • git stash drop [작업 내용의 아이디] : 작업 내용 제거 - 작업 내용의 아이디를 생략하면 가장 최근의 작업 내용이 제거됨
  • git stash pop [작업 내용의 아이디] : 작업내용 적용 + 적용한 내용 스택에서 제거
    • [작업 내용의 아이디]를 인자로 주지 않으면, 가장 최근에 한 작업 내용을 적용하면서 스택에서 제거합니다.

git stash apply + git stash drop = git stash pop

그 작업 내용을 나중에 또 쓸 필요가 있다면 git stash apply를
나중에 또 쓸 필요가 없다면 git stash pop을 쓰면 된다.
일반적으로는 후자의 경우가 더 자주 사용한다.

✅커맨드가 궁금할 땐?

  • git help [커맨드 이름] : 사용법이 궁금한 Git 커맨드의 공식 메뉴얼 내용 출력

전체 모아보기

Git 써보기

  • git init : 현재 디렉토리를 Git이 관리하는 프로젝트 디렉토리(=working directory)로 설정하고 그 안에 레포지토리(.git 디렉토리) 생성
  • git config user.name 'codeit' : 현재 사용자의 아이디를 'codeit'으로 설정(커밋할 때 필요한 정보)
  • git config user.email 'teacher@codeit.kr' : 현재 사용자의 이메일 주소를 'teacher@codeit.kr'로 설정(커밋할 때 필요한 정보)
  • 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에 있는 것들 커밋으로 남기기
  • git help [커맨드 이름] : 사용법이 궁금한 Git 커맨드의 공식 메뉴얼 내용 출력

GitHub 시작하기

  • git push -u(또는 --set-upstream) origin master : 로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용합니다.
  • git push : 위의 커맨드를 한번 실행하고 난 후에는 git push라고만 쳐도 로컬 레포지토리의 내용을 리모트 레포지토리에 올릴 수 있습니다.
  • git pull : 바로 위의 위에 있는 커맨드를 한번 실행하고 난 후에는 git pull이라고만 쳐도 리모트 레포지토리의 내용을 로컬 레포지토리로 가져옵니다.
  • git clone [프로젝트의 GitHub 상 주소] : GitHub에 있는 프로젝트를 내 컴퓨터로 가져오기

Git에서 커밋 다루기

  • git log : 커밋 히스토리를 출력
  • git log --pretty=oneline : --pretty 옵션을 사용하면 커밋 히스토리를 다양한 방식으로 출력할 수 있습니다. --pretty 옵션에 oneline이라는 값을 주면 커밋 하나당 한 줄씩 출력해줍니다. --pretty 옵션에 대해 더 자세히 알고싶으면 이 링크를 참고하세요.
  • git show [커밋 아이디] : 특정 커밋에서 어떤 변경사항이 있었는지 확인
  • git commit --amend : 최신 커밋을 다시 수정해서 새로운 커밋으로 만듦
  • git config alias.[별명][커맨드] : 길이가 긴 커맨드에 별명을 붙여서 이후로는 별명으로도 해당 커맨드를 실행할 수 있게 설정
  • git diff [커밋 A의 아이디][커밋 B의 아이디] : 두 커밋 간의 차이 비교
  • git reset [옵션][커밋 아이디] : 옵션에 따라 하는 작업이 달라짐(옵션을 생략하면 --mixed 옵션이 적용됨) (1) HEAD가 특정 커밋을 가리키도록 이동시킴(--soft는 여기까지 수행) (2) staging area도 특정 커밋처럼 리셋(--mixed는 여기까지 수행) (3) working directory도 특정 커밋처럼 리셋(--hard는 여기까지 수행) 그리고 이때 커밋 아이디 대신 HEAD의 위치를 기준으로 한 표기법(예 : HEAD^, HEAD~3)을 사용해도 됨
  • git tag [태그 이름][커밋 아이디] : 특정 커밋에 태그를 붙임

Git에서 브랜치 사용하기

  • git branch [새 브랜치 이름] : 새로운 브랜치를 생성
  • git checkout -b [새 브랜치 이름] : 새로운 브랜치를 생성하고 그 브랜치로 바로 이동
  • git branch -d [기존 브랜치 이름] : 브랜치 삭제
  • git checkout [기존 브랜치 이름] : 그 브랜치로 이동
  • git merge [기존 브랜치 이름] : 현재 브랜치에 다른 브랜치를 머지
  • git merge --abort : 머지를 하다가 conflict가 발생했을 때, 일단은 머지 작업을 취소하고 이전 상태로 돌아감

Git 실전 I

  • git fetch : 로컬 레포지토리에서 현재 HEAD가 가리키는 브랜치의 업스트림(upstream) 브랜치로부터 최신 커밋들을 가져옴(가져오기만 한다는 점에서, 가져와서 머지까지 하는 git pull과는 차이가 있음)
  • git blame : 특정 파일의 내용 한줄한줄이 어떤 커밋에 의해 생긴 것인지 출력
  • git revert : 특정 커밋에서 이루어진 작업을 되돌리는(취소하는) 커밋을 새로 생성

Git 실전 Ⅱ

  • git reflog : HEAD가 그동안 가리켜왔던 커밋들의 기록을 출력
  • git log --all --graph : 모든 브랜치의 커밋 히스토리를, 커밋 간의 관계가 잘 드러나도록 그래프 형식으로 출력
  • git rebase [브랜치 이름] : A, B 브랜치가 있는 상태에서 지금 HEAD가 A 브랜치를 가리킬 때, git rebase B를 실행하면 A, B 브랜치가 분기하는 시작점이 된 공통 커밋 이후로부터 존재하는 A 브랜치 상의 커밋들이 그대로 B 브랜치의 최신 커밋 이후로 이어붙여짐(git merge와 같은 효과를 가지지만 커밋 히스토리가 한 줄로 깔끔하게 된다는 차이점이 있음)
  • git stash : 현재 작업 내용을 스택 영역에 저장
  • git stash apply [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용
  • git stash drop [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 스택에서 삭제
  • git stash pop [커밋 아이디] : 스택 영역에 저장된 가장 최근의(혹은 특정) 작업 내용을 working directory에 적용하면서 스택에서 삭제
  • git cherry-pick [커밋 아이디] : 특정 커밋의 내용을 현재 커밋에 반영

0개의 댓글