Post

GitHub 정리

GitHub

버전 관리 시스템으로 버전, 백업, 협업을 위한 툴!
버전 관리의 본질은 원본을 수정하지 않고 원본의 복제본을 만들어 수정하는 것이다.

  • git version check
    1
    2
    3
    
    git --version
    git -v
    git version
    
  • git config list
    1
    2
    3
    
    git config --list
    git config user.name
    # 등등
    
  • 로컬저장소 생성
    • 여기서 생성되는 .git 파일이 저장소
    1
    2
    3
    
      git init
      # 로컬 저장소에 원격저장소를 알려줌
      git remote add origin <url>
    
    • 주소 url를 다 기억할수없어서 origin이라고 불러줌(별명)
    • 지역저장소에 여러개 원격저장소를 연결할수있음
  • remote tracking branch이라고 어디까지 서버로 했는지 확인할 수 있다.
  • HEAD -> main -> file
    origin/main -> file

git 구조

  • HEAD는 현재버전
  • main은 마지막 버전
    • 이전엔 master 였는데 사회적 논란으로 main이 됨…
  • 지금 만든 버전의 부모는 HEAD다
  • HEAD는 새로운 버전을 가르키는데
    • HEAD → main(head의 대리) → a
      b가 추가될 경우
    • HEAD → main → a
      b → a
    • HEAD → main → b → a
    • c 추가 ⇒ c → b → a
    • HEAD → main → c → b → a
  • 부모는 자식이 누군지 모르지만 자식은 부모가 누군지 안다
  • 각각의 commit은 commit을 한 시점에 stage area의 스냅샷이다
    • 각각의 버전은 과겨의 상태를 포함한다
  • main을 b로 보내면 영원히 이전 버전으로 감. HEAD를 b로 보내면 잠깐 이전 버전으로 감.
  • checkout은 head를 바꾼다
    1
    2
    
    git checkout b
    git checkout main
    
  • reset은 branch를 바꾼다
    • 일반적으로 hard를 사용
    1
    
      git reset --hard commit_id
    
  • git reflog를 통해서 commit_id와 commit 메세지를 확인할 수 있음

git 관리

  • 팀원끼리 rule을 정해서 진행
    • branch를 사람마다, task마다 생성할 것인지 등등
  • commit 방법
    • commit 메세지를 수정할 때도 새로운 복제본을 만들어 수정하는 구조이다
    1
    2
    3
    4
    
      git add <file/folder>
      git commit -m <commit_message>
      # commit message를 수정하고 싶을때
      git commit --amend -m <commit_message>
    
  • pull
    • pull = fetch + merge
    • fetch의 경우 절대 conflict 발생안함

conflict - git merge hell

  • 보통 다른 branch끼리 merge하는 과정에서 같은 파일에 있는 같은 부분을 동시에 수정했을 때 발생
  • 병합편집기를 통해 사용자가 직접 최종 결과를 수정해 merge 한다.
  • rebase, revert, cherry-pick의 경우 3 way merge에 의해 conflict날 수 있다.
    merge
  • merge의 경우, 하나의 새로운 파일을 생성하여 현재버전으로 설정한다
  • conflict가 발생한 부분을 사용자가 직접 수정 merge

rebase

  • rebase의 경우, 타임라인을 간단하게 하고 싶을 때 사용한다
    • 보기는 좋지만 지식이 필요하고 섣불리 시도하면 큰 고생을 할 지도?!
  • conflict가 연속적으로 계속 발생할 수 있고 심도가 깊어지면 상황이 복잡해질 수 있으므로 비추
  • 서로다른 group화에 불리하다
  • conflict가 발생한 부분을 사용자가 직접 수정
  • 더이상 가르키지 않는 부분은 마치 삭제된 것처럼 처리된다. rebase

cherry-pick

  • 특정 버전 하나만 가져온다
  • 다른 브랜치에 있는 commit을 선택해 내 브랜치에 적용시킬때 사용 cherry-pick

reject

  • 원격저장소의 내용을 갖고 있지 않을 채로 push하려고 할 때 발생한다
  • pull(/fetch)을 통해 원격저장소의 내용을 받아옴
This post is licensed under CC BY 4.0 by the author.