DVCS git!!

Learn DVCS

• 이 글은 우아한 형제들에서 Programmer로 활동하시고 계신 김민태 님의 SlideShare의 게시글을 보고 정리한 내용입니다

DVCS =Distributed Version Control System

텍스트 파일 하나 있고, 수정한 내용을 기록해두고 싶다

• “컵라면 1박스 구입”이라는 수정이 발생

“수정”의 단계를 어느 정도까지 기록해야 하는지 궁굼

• 컵(save)라(save)면(save) 이런식으로 저장했다면 모두 기록해야할까??

규칙 1

• “수정”의 단계는 “의미”를 기준으로

의미의 기준??

• SW가 의미를 인식할 수 없으니 정할 수 있는 사람 즉, 사용자가 의미를 정해야 한다

commit

• 파일의 수정이 끝났으면 commit를 한다

  • “이 파일의 의미있는 수준의 수정 작업이 끝났음”이라고 git에게 알려주는 일

• 예를들어 세 번의 commit이 있다고 하자
  • commit 1. 맥주 구매 할 일 추가 (14년 07월 06일 12:42)
  • commit 2. 쓰레기 봉투 구매 할 일 추가 (14년 07월 09일 10:03)
  • commit 3. 컵라면 구매 할 일 추가 (14년 07월 10일 17:00)

• 이 commit들은 “수정 내용을 설명하는 것이다”

• 이 commit을 두번만 하는 방향으로 가보자
  • commit의 기준을 정하는건 사용자이다. commit의 단위를 작게 할 수록 변경 내용의 기록 수준은 정밀해지며 파악할 수 있는 정보도 많아진다
  • commit 1. 맥주 구매 할 일 추가 (14년 07월 06일 12:42)
  • commit 2. 쓰레기봉투, 컵라면 구매 할 일 추가 (14년 07월 10일 17:00)

규칙 2

• 하나의 Commit은 여러개의 파일이 포함될 수 있다

“수정의 의미”를 확장하자

• 하나의 파일을 수정하는 것, 하나의 수정 작업이 여러 파일에 영향을 줄 수 있는 것. 의미라는 관점에선 하나의 수정이라고 할 수 있다

Commit은 수정의 단위. 수정은 여러 파일에 걸친 변경 내역의 묶음일 수 있다

• commit 1. 월,화 자율 학습 일정 추가 (14년 07월 06일 12:42)
• commit 2. 수요일 학습 내용 추가 (14년 07월 09일 10:03)
• commit 3. 수,목,금 교육 시간 수정 (14년 07월 10일 17:00)

규칙 3

• 상태를 저장하는 공간을 만들 수 있다

  • “branch”

  • 상태란 모든것이다. 파일, 파일의 내용, commit 정보 등 git이 관리하는 모든 것을 의미한다

• 즉, 기존 원본의 파일의 상태를 그대로 유지한 상태에서 파일의 내용을 수정하거나 변경이 가능하다
  • 그러나 원본 파일에는 아무런 영향을 끼치지 않는다

git의 시작

• 지정한 폴더의 변경 내용을 추적하기위한 준비

  • “init”

    • 선택된 폴더의 변경 내용을 추적하기 위해 git 저장소를 만든다. 저장소가 만들어지면 git은 지정한 폴더를 포함하여 하위 폴더의 모든 변경 내용을 commit 단위로 추적한다

  • “master”

    • init 명령으로 저장소가 만들어질 때 git은 master라는 이름의 branch를 기본으로 생성하고 이후 commit 내용을 branch 기준으로 저장한다

commit은 branch 공간에 기록된다

master
⎪
commit 1. 월,화 자율 학습 일정 추가 (14년 07월 06일 12:42)
⎪
commit 2. 수요일 학습 내용 추가 (14년 07월 09일 10:03)
⎪
commit 3. 수,목,금 교육 시간 수정 (14년 07월 10일 17:00)

새로운 브랜치 만들기

• 파일을 수정하기 않고 새로운 실험 하기

  

Error img가 나올 경우에는 여기를 눌러주세요.

- 새로 만든 branch lab1은 master와 완전히 동일한 상태를 가진 공간.
- lab1 branch에서 수정을 한 후 commit 하면 그 변경사항은 lab1에만 기록되며 master branch에는 어떤 영향도 주지 않음

완전히 독립된 branch lab1

• 새로 만든 branch lab1 은 master 와 완전히 동일한 상태를 가진 공간
• lab1 branch에서 수정을 한 후 commit 하면 그 변경사항은 lab1에만 기록되며 master branch에는 어떤 영향도 주지 않은

원하는 만큼 branch 생성 가능

• git은 매우 빠르게 새로운 독립공간인 branch를 원하는 만큼 만들 수 있다
• branch 이름은 이름 정의 규칙 내에서 사용자가 원하는 형태로 작명할 수 있다

다른 branch로 돌아가야 한다면?

• checkout master

• 원한다면 언제든 다른 branch(작업 공간)로 이동할 수 있다
• branch는 마지막 commit 상태를 유지한다

• 작업 중인 위치를 가르키는 가상의 커서가 존재하는데 이를 git에서는 HEAD라 한다

branch를 이동하는 이유

• 새로운 실험을 하기 위해 lab1을 만들고 작업을 하고 있다. 그런데 master branch에 내용을 변경할 일이 발생했다. 어떻게 해야할까?

  • 답은 master branch로 이동하여 변경 작업을 처리한 후 commit. 다시 lab1 branch로 돌아와 하던 실험을 계속한다

실험종료. 선택의 순간

• lab1에서 진행했던 파일의 수정과 같은 실험이 예상과 달리 필요없는 작업이 되었다. 어떻게 하면 될까?

  • 답은 master로 이동 후 lab1 branch를 삭제한다. 기록 보관 차원에서 삭제하지 않아도 아무 문제 없다

• lab1에서 진행했던 실험이 성공적으로 끝났다. 실험의 결과를 master branch에 옮기려한다. 어떻게 하면 될까?

  • 답은 lab1 branch의 내용을 master branch와 merge(병합)한다

branch와 branch의 merge(병합)

• 병합결과

  • master branch에 lab1 branch를 merge하면 git은 lab1 branch의 내용과 master branch의 commit의 내용을 포함하여 두 branch를 병합한다
  • 변경 내용에 따라 파일 내용이 변경되고 때론 파일이 삭제될 수 도 있으며 추가될 수 도 있다

정리

• commit : 수정 내역을 사용자 기준의 의미로 기록한다

• branch : 완전히 독립된 작업 공간을 만들 수 있다

• checkout : 독립된 작업 공간인 branch를 자유롭게 이동항 수 있다

• merge : branch와 branch간 내용을 병합할 수 있다

git으로 다른 사람과 함께 작업하는 원리 및 방법

• git 저장소를 하나 가지고 있다. 내 컴퓨터에 있기 때문에 나만 접근이 가능하다

  • 동료와 함께 작업을 어떻게 할까?

    • 1. 복사를 시도
         • USB와 같은 하드웨어를 이용한 복사 및 여러 방법의 복사를 통하여 동료와 작업을 시도
         • 복사는 단방향이다. 한번 주고 동료가 작업한 결과를 돌려 받기 위해선 너무나 많은 어려움이 예상된다

         • Git은 “리모트 저장소”를 지원한다

• 리모트 저장소가 있다면

  • 리모트 저장소 또한 원본 git 저장소와 동일한 저장소이다
  • 리모트 저장소를 경유하여 함께 작업할 동료도 완전히 동일한 저장소를 다운로드 받을 수 있으며, 동일한 방식으로 작업을 할 수 있다

• 리모트 저장소에서 저장소 다운로드

  • 리모트 저장소에서 처음으로 git 저장소를 다운로드 받는 것을 복사본을 만든다는 의미로 clone 이라 한다

• 리모트 저장소의 변경 내용 업데이트

  • 리모트 저장소의 변경된 내용을 로컬(내 컴퓨터) 저장소에 적용하는 작업을 Pull 이라 한다. 이때 branch merge와 같은 병합이 발생한다

• 내 저장소(로컬 저장소)의 변경 내용 리모트로 전송하기

  • 로컬 저장소에서 작업한 내용을 리모트 저장소로 보내는 작업을 push라 한다
  • 함께 작업하는 동료에서 변경사항을 전송하기 위해선 리모트 저장소를 경유해야 한다는 것을 알 수 있다

학습 후 나의 생각

git은 개발자가 자기 자신과 동료 및 친구와의 협업이나 여러 프로젝트를 진행하면서 사용해야 하는 것을 알고는 있었다

그러나 git이 왜 중요한지 모르고 github을 학습 내용을 올리거나 개발자를 꿈꾸거나 함께 공부하는 친구들이 쓰니까 나도 쓰자 라는 생각으로 사용하였다 하지만 이번 학습을 계기로 git의 사용법과 함께 왜 git이 협업의 툴로써 사용이되고 git으로 협업을 하면 어느점이 장점이 되는지를 알게 되었다

• git에 대한 장벽

  어떤 공부를 하던간에 가장 힘든 점은 역시나 전문용어에 대한 설명이 너무 어렵거나 설명이 너무 없어서 이해를 못하는 것이다 이 게시글을 보면서 가장 좋았던 점은 git에서 가장 기본적인 command의 설명과 함께 어떻게 git이 작동하고 실행되며 원리는 어떻게 되는지를 보여줘서 왜 commit을 해야하고 push를 해야하는지 혹은 branch의 필요성과 master는 무엇인지 등에 관하여 확실하게 이해를 하게 되었다는 점이다

• 이 외의 생각

  이번 공부 외의 다른 공부를 할때도 생각하는것이지만 항상 새로운 것을 배우거나 이해하는 것은 즐거운 일인것 같다는 생각을 한다 그리고 어느 한 단계를 이해하고 나면 그 뒤에 나오는 내용들이 더욱더 궁굼해지기도 하고 공부에 대한 흥미도 높아지는 것 같다 학습에 대한 노하우도 길러지고 나만의 방식으로 학습하거나 이해하는 방법을 점점 발전 시켜 나아가는 계기도 되었다