인간다운 Git

인간다운 Git

개발 인턴십 당시, 멘토님의 추천을 받아 읽은 책

Git을 왜 써야하는지, 어떤 장점이 있는지, Git의 기본 작동 매커니즘 등에 대한 기본적인 내용을 다루고 있다.
상당히 이해하기 쉽게 책이 쓰여있어, 나와 같이 Git을 쓰긴 쓰는데 쓰는 이유를 잘 모른다거나, Git에 대한 기본적인 숙지가 되어있지 않은 사람에게 추천하고 싶다.

내용 정리는 다음과 같다.

• Git은 버전관리 시스템 중 하나.
  --> 어떤 작업물의 최종본만 갖고 있는 것이 아니라 그 이전 각 수정본을 모두 보유함으로써, 필요할 때 이전 버전을 참고하거나 그 버전으로 되돌릴 수 있게 하자는 것.
  
  
• 저장소(repository)라는 곳에 각 버전 사본을 유지
  
  
• 커밋
   해당하는 버전을 저장소에 저장하는 것. 모든 커밋에는 작업자의 이름과 이메일 주소같은 메타데이터가 포함됨.
  
  
• 브랜치
   커밋들이 모여 구조화된것. 브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념
  
  
• 작업 사본
  안전하게 변경할 수 있는 프로젝트 버전. 어떤 변경도 원하는 대로 할 수 있으며, 특정 변경 사항을 저장소에 커밋하면 그것이 공식적으로 저장되는 버전이 된다. 커밋이라는 것이 작업 중 수시로 저장하는 사소한 수정이 아닌, 중요한 변경 사항에 대한 행위라는 인식.
  
  
• 스테이징 영역
   커밋하기 전까지 새 버전이 대기하는 장소. 새 버전을 커밋하려면 git add명령을 통해 새 버전이 git 데이터베이스에 추가돼야 한다. 이것이 스테이징. 스테이징 영역은 다른 사람과 공유되거나 동기화되지 않으며 오직 로컬 컴퓨터에만 존재한다.
  
  
• 브랜치 체크아웃
  • 작업 사본을 그 브랜치의 헤드 커밋의 상태에 맞춘다.
  • 그 브랜치를 현재 브랜치로 설정함으로써 이후의 모든 새로운 커밋들이 그 브랜치에 추가되도록 한다.
    
    
• 브랜치
  • 브랜치는 논리적으로 별개. 서로 다른 논리적인 사본
    
    
• 패스트 포워드
  • 한쪽 브랜치에서만 변경사항이 일어남.
  • 현재 브랜치의 북마크를 현재 커밋에서 다른 브랜치의 헤드 커밋으로 이동시킴.
    
    
• 병합 커밋
  • 병합(merge) : 서로 다른 브랜치를 양쪽 특성을 모두 갖는 하나의 통합된 버전으로 합치는 것.
  • 각 브랜치의 직전 커밋 모두를 부모로서 참조하는 병합 커밋을 만듬.
    
    
• 병합 충돌
  • 병합할 두 라인이 겹칠 때 발생. 즉, 두 개의 다른 버전이 같은 파일의 같은 라인을 변경.
  • 충돌 마커, 꺾쇠괄호 사이의 모든 내용은 병합 가능하도록 우리가 원하는 코드로 대체해야 한다. 충돌하는 두 라인 가운데 하나를 반드시 사용할 의무는 없다.
  • 이후 이 버전을 스테이징 영역에 추가하고 커밋함으로써 병합을 완성
    
    
• GitHub
  • 대표적인 git 웹호스팅 서비스. 프로젝트 리모트 저장소 (리모트 저장소: 내 로컬 컴퓨터가 아닌 원격에 있는 Git 프로젝트 사본).
    - 한 컴퓨터의 브랜치로부터 커밋을 다른 컴퓨터의 브랜치로 푸시하는 대신, 이러한 허브 모델을 이용해 Git사이의 코드를 공유. 허브 모델은 진보된 중앙집중방식으로, 팀이 원격 서버(허브)에 프로젝트 사본을 관리하고 공유하며 팀원이면 누구나 접근할 수 있게 해줌. git push, git pull 명령을 사용해 서버의 저장소와 자신의 저장소를 동기화한다.
    
    
  • 장점
    • 백업 시스템 역할
    • 코드의 공유가 쉬워짐.
      -> 한 컴퓨터의 브랜치로부터 커밋을 다른 컴퓨터의 브랜치로 푸시하는 대신, 팀이 원격 서버(허브)에 프로젝트 사본을 관리하고 공유하며 팀원이면 누구나 접근할 수 있게 해줌.
      
      

• 리모트 URL
  Git은 네트워크를 통해 커밋이나 그 외 데이터를 전송하기 위한 서로 다른 세 가지 프로토콜을 지원한다.
  git 프로토콜, ssh 프로토콜, http 프로토콜.
  
  
  
• git pull
  • git pull을 사용해 서버 측 브랜치를 로컬 브랜치로 병합하라고 할 때에도 git은 모든 병합 과정을 로컬에서 진행한다. 이 말은 병합 작업을 하기 전 먼저 서버의 브랜치를 로컬 컴퓨터 어딘가에 복사해 놓는다는 의미다. 그 어딘가가 바로 FETCH_HEAD다. FETCH_HEAD는 새롭게 가져온 변경 사항의 병합 작업을 위한 버퍼로서 GIT이 만든 임시 브랜치. 병합은 풀링 작업에 포함돼 있다!
    
    
• 리모트 병합 충돌
  • git pull origin master -> 충돌(conflict)
     git merge 했을 때와 병합 충돌 해결 방안 같음
  • 푸시 거부 에러
     pull하고 다시 push
  • 일반적으로 서버 측 git 저장소에는 작업 사본과 스테이징 영역이 없으며, 병합 충돌을 해결해줄 사람도 없다. → 패스트 포워드 병합만 가능.
    
    
• git fetch
  • 다른 사람의 브랜치에 커밋 추가하기.
    
    • git fetch: 현재 서버에 있는 모든 브랜치를 내려받음.
    • git branch: 기본적으로 로컬 사본에 존재하는 브랜치 목록을 보여주지만, —remote 옵션을 추가하면 git이 알고 있는 모든 리모트 브랜치를 보여줌
    • git fetch 이후 git merge origin/master 을 하면 이는 곧 git pull origin master를 실행한 것과 같다.
    • 같은 이름으로 origin/ 앞에 붙일 필요 없이 checkout (예시)make-logo-bigger하면 알아서 origin/make-logo-bigger를 트랙해서 브랜치를 새로 만든다.
    • 이후 커밋 추가
      
      
• git pull은 하나의 브랜치에서 변경 사항을 가져오는 반면, git fetch는 한번에 리모트 저장소를 몽땅 가져온다. 리모트 저장소의 모든 브랜치를 내려받는다. 서버 데이터 사본. 읽기 전용
  
  
• git log
  • 프로젝트 히스토리 확인
  • 현재의 헤드 커밋부터 최초의 커밋까지 시간의 역순으로 모든 커밋 목록 보여줌
    
    
• git tag
  • 태그란, 커밋을 참조하기 쉽도록 알기 쉬운 이름을 붙이는 것을 말합니다.
    
    
    
• (추가) git revert reset rebase
  • git reset 명령어는 특정 커밋으로 되돌아갈 수 있는데, 되돌린 버전 이후의 버전들은 히스토리에서 삭제됩니다. -soft (Staging area(Index), Working directory는 그대로), -mixed(Index 지워짐, 워킹 디렉토리는 그대로) -hard(Index, 워킹 디렉토리 모두 다 지워짐)
    https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Reset-%EB%AA%85%ED%99%95%ED%9E%88-%EC%95%8C%EA%B3%A0-%EA%B0%80%EA%B8%B0
  • git rebase : git merge와 같이 두 브랜치의 코드를 병합하는 기능을 가지고 있다. git merge와다른 점은 git merge의 경우 두 개의 부모 커밋을 가지고 있는 커밋을 추가함으로써 코드 병합이 이루어지는 방면, git rebase의 경우 마치 fast-forward방식으로 코드 병합이 이루어진것 처럼 커밋을 추가하는 것. 장점: 커밋 로그 내역을 깔끔하게 정리 가능 단점: 충돌상황에서 다소 복잡. 다른 사람과 공유하는 브랜치에서 rebase를 하면 오류가 생길 일이 많다
  • git revert 이전 커밋 내역을 그대로 남겨둔 채 새로운 커밋을 생성한다.
    
    
• git checkout
  • (커밋 체크아웃) 과거 커밋을 조회할 수 있다.
  • (브랜치 체크아웃) 해당 브랜치의 가장 최신 커밋으로 이동 가능.
  • 커밋의 체크아웃은 그 후의 새로운 커밋을 추가하려는 의도가 없는 경우라는 점에서 브랜치의 체크아웃과 다르다.
    
    
• (추가) git stash
  아직 마무리하지 않은 작업을 스택에 잠시 저장할 수 있도록 하는 명령어이다. 이를 통해 아직 완료하지 않은 일을 commit하지 않고 나중에 다시 꺼내와 마무리할 수 있다.
  참조) https://gmlwjd9405.github.io/2018/05/18/git-stash.html