git이란 무엇인가?
https://ko.wikipedia.org/wiki/%EA%B9%83_(%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4)
git은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에
해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.
분산 버전 관리(DVCS)
분산 버전 관리는 소프트웨어 버전 관리를 위한 시스템이다.
이 시스템은 각 개발자가 중앙 서버에 접속하지 않은 상태에서도 코드 작업을 할 수 있는 것이 특징이다.
Git Basics
git을 사용해서 파일 버전 관리를 할 때 파일은 다음 3개의 상태중 하나의 상태에 있게 된다.
- committed(커밋)
수정 사항들이 git에 저장 된 상태를 'committed'라고 하며, 이러한 행위를 'commit'한다고 함 - modified
modified file은 이름 그대로 수정된 file이다.
하지만 아직 'commited'되지 않은 상태의 file을 이야기함 - staged
stage file은 modified file에서 한단계 더 나아가서 곧 commit 될 거라고 mark 해놓은 상태이다.
즉, modified와 committed의 중간 상태라고 생각하면 됨.
이렇게 중간 상태가 존재하는 이유는,
commit 하기 전에 중간 상태를 저장할 수 있도록 하기 위함이다.
commit을 하면 commit history에 남기도 하고, 혹시 추가 수정 사항이 있거나 다시 되돌려야
할 때 까다롭기 때문에(commit 후에도 다시 되돌리는게 가능은 하다.) commit 전에 중간 상태에
저장할 수 있도록 하는 것이다. 즉, commit은 해당 개발이 완전 완료되었을 떄 하는 것이기 떄문에,
아직 완료는 안되었지만 그래도 중간 상태를 저장할 필요가 있을 때 staging을 사용하는 것.
git을 사용한 버전 관리의 flow는 다음과 같다.
- 소스코드 전체를 다운로드 받는다.(전문용어로, 'git repository를 checkout한다'고 표현)
- 소스코드 파일들을 수정한다. 즉, 개발을 한다.
- 수정한 파일들을 stage한다.
- 계속해서 소스코드 파일들을 수정해 나간다.
- 해당 작업이 완료될떄까지, 즉, commit 할 준비가 될 때까지 3번과 4번을 반복한다.
- 완료되면 commit
Basic git Commands
git init
프로젝트를 git repository로 만들기 위해서 사용하는 명령어.
여기서 프로젝트라 함은 개발하고자 하는 소스코드들이 있는 디렉토리를 말한다.
git init을 해서 git repo로 만들어야 git으로 버전 관리가 시작된다.
git add
수정 사항들, 즉 modified 파일들을 staged 상태로 이동할 때 사용하는 명령어
또한, git repo에 새로이 추가된 파일들을 staged 상태로 이동시킬 떄도 사용
새로이 추가된 파일들은 'untracked'파일이라고 하는데, git에서는 이들도 수정사항이라고 본다.
git commit
staged 된 파일들을 commit 하고자 할 때 사용하는 명령어.
git diff
어떤 수정 사항들이 적용되었는지 보고자 할 때 사용하는 명령어.
staged 된 수정 사항들은 git diff로 볼 수 없다.
modified 된 파일들만 git diff로 볼 수 있다.
git status
현재 상태를 보여주는 명렁어.
어떤 파일들이 modified가 되었고, 어떤 파일들이 staged가 되었는지 등의 전체적인 상황을 보여줌
git log
commit 내역들을 보여줌. commit history라고도 함.
git log를 통해 이제까지 커밋 내역들을 볼 수 있다.
git rm
원하는 파일을 git repo에서 삭제한다.
git mv
원하는 파일을 git repo 상에서 이동시킬 때 사용한다.
주로 rename할 떄 사용.
git branch
branch를 생성할 때 사용된다.
git checkout
어떤 branch를 checkout 할 때 사용되는 명렁어.
Branch & Merging
git을 사용할 때는 branch 기반으로 개발한다.
git branch를 이해하기 위해 먼저 git이 어떻게 데이터(수정사항)를 저장하는지 알아야한다.
git은 데이터를 단순한 변경사항(diff)으로 저장하지 않는다.
git은 파일의 스냅샷의 연속으로 저장한다.
git은 새로 commit이 들어오거나 프로젝트의 상태를 저장할 떄마다 파일이 존재하는
그 순간을 중요하게 여긴다. 그래서 파일이 달라지지 않았으면 git은 빠른 성능을 위해서
파일을 새로 저장하지 않고 이전 상태의 파일에 대한 링크만 저장한다.
즉, 수정 사항만을 저장하는게 아니라 파일의 스냅샷을 시간순으로 저장하는 것.
그리고 변경사항을 볼때는 현재 스냅샷과 이전 스냅샷을 비교하여 변경사항을 볼 수 있는 것.
이렇게 스냅샷으로 저장되어 있기 때문에, 개발자가 central server에서 새로 repo를 checkout받으면
해당 리포의 특정한 시점의(일반적으로 가장 최신) 스냅샷을 checkout받는 것이다.
개발자들이 각자 snapshot을 checkout 받아서 개발을 하면 어떻게 서로의 변경사항들을 조율할 수 있을까?
즉, 서로의 변경사항들을 합쳐서 새로운 최신 버전의 스냅샷을 만드는 과정이 필요한데,
문제는 어떤 스냅샷을 기준으로 변경사항들을 합치느냐 하는 문제가 생긴다.
그래서 이러한 문제를 해결하기 위해 branch를 사용한다.
branch는 나뭇가지 또는 분점을 뜻한다. 즉, 기본이 되는 큰 줄기가 있고 그 줄기로 부터
옆으로 가지가 나는 걸 뜻한다. git의 branch 모델이 바로 이러한 구조이다.
기준이 되는 스냅샷이 있다. 이 기준을 master branch라고 한다.
그리고 각 개발자는 mater branch를 checkout 먼저 하고,(이동하고)
master branch로 부터 자신만의 branch를 만든다.
이걸 feature branch라고 한다. 그리고 feature branch를 기반으로 개발을 한 후
개발이 완료가 되고 commit을 하면 자신의 feature branch를 다시 master branch로 합하게 된다.
이렇게 합하는 과정을 merge라고 한다.
정리하자면,
- master branch를 checkout한다.
- 자신만의 feature branch를 만든다.
- feature branch에서 개발을 한다.
- 완료되면 commit 한다.
- master branch에 feature branch를 merge한다.
커밋과 브랜치 추가 설명
출처 : https://learngitbranching.js.org/?locale=ko
1. Git 커밋
커밋은 Git 저장소에 여러분의 디렉토리에 있는 모든 파일에 대한 스냅샷을 기록하는 것.
git은 커밋을 가볍게 유지하고자 하기 때문에, 커밋할 때마다 디렉토리 전체를 복사하진 않는다.
각 커밋은 저장소의 이전 버전과 다음 버전의 변경내역('dela'라고도 함)을 저장한다.
그래서 대부분의 커밋이 그 커밋 위의 부모 커밋을 가리킨다.
커밋은 프로젝트의 스냅샷들로 생각하면 충분하다.
스냅샷이란?
https://ko.wikipedia.org/wiki/%EC%8A%A4%EB%83%85%EC%83%B7_(%EA%B8%B0%EC%96%B5_%EC%9E%A5%EC%B9%98)
컴퓨터 파일 시스템에서 스냅샷은 과거의 한때 존재하고 유지시킨 컴퓨터 파일과 디렉토리 모임이다.
커밋은 프로젝트의 스냅샷이다.
커밋은 프로젝트에서 한 때 존재하고, 프로젝트를 유지시킨 컴퓨터 파일과 디렉토리 모임이다.
2. git 브랜치
브랜치는 특정 커밋에 대한 참조(reference)에 지나지 않는다.
브랜치를 많이 만들어도 메모리나 디스크 공간에 부담이 되지 않기 때문에,
작업을 큰 브랜치로 만들기 보다 작은 단위로 잘게 나누는 것이 좋다.
브랜치를 '하나의 커밋과 그 부모 커밋들을 포함하는 작업 내역'이라고 기억하자.
git remote(원격)
출처 : https://learngitbranching.js.org/?locale=ko
git remote 또 하나의 컴퓨터에 있는 저장소의 복사본일 뿐이다.(원격 저장소)
인터넷을 통해 이 또 하나의 컴퓨터와 커밋을 주고 받는 등 대화를 할 수 있다.
원격 저장소의 장점은 다음과 같다.
- 원격 저장소는 백업으로서의 역할을 수행한다.
로컬 git 저장소는 파일들을 이전의 상태로 되돌리는 기능을 가지고 있다. - 원격 저장소를 통해 코딩을 다른 사람과 함께 할 수 있다.
개인의 프로젝트 복사본이 호스트되기 떄문에, 다른 사람이 프로젝트에 쉽게 기여할 수 잇다.(최근의 변화를 pull)
github는 원격 저장소에서의 활동을 시각화해주는 웹 사이트 중 하나이다.
3-1. git clone
원격 저장소를 생성하는 명령어
git clone은 원격 저장소(git hub)의 복사본을 로컬(내 PC)에 생성할 때 사용하는 명령어이다.
git clone 명령 이후, 로컬 저장소(내 pc)에 origin/master라고 하는 새 브랜치가 생긴다.
이런 종류의 브랜치는 원격 브랜치라고 부른다.
원격 브랜치는 원격 저장소의 상태를 반영한다.(가장 최근 원격 저장소와 작업 기준)
원격 브랜치는 로컬에서의 작업과 공개적으로 되고있는 작업의 차이를 이해하는데 도움을 준다.
- origin/ 는 무엇인가?
원격 브랜치에는 이름짓기 규약이 있는데
remote name/branch name
이런 이유로, 만약 origin/master라는 이름의 브랜치를 보게 되면,
브랜치의 이름은 master이고 원격 저장소의 이름은 origin인 것이다.
대부분의 개발자들은 자신의 주 원격 저장소를 origin이라고 짓는다.
사실 보통 다 이렇게 쓰기 때문에 git은 저장소를 git clone하게 되면 원격 저장소의 이름을
origin이라고 자동으로 설정해놓는다.
3-2 git fetch
원격 저장소에서 데이터를 가져오는 방법.
git 원격 작업들은 결국 서로 다른 저장소에서 데이터를 주고 받는 것에 불과하다는 것을 알자.
원격 저장소와 작업을 해서 상태가 변하면 원격 브랜치들 또한 그 변경들을 반영한다.
git fetch는 다음을 수행한다.
- 원격 저장소에는 있지만 로컬에는 없는 커밋들을 다운로드 받는다.
- 우리가 원격 브랜치가 가리키는 곳을 업데이트 한다.(에를 들어, origin/master)
git fetch는 본질적으로 로컬에서 나타내는 원격 저장소의 상태를 실제 원격 저장소의(지금)
상태와 동기화한다.
git fetch는 다음을 수행하지 않는다.
- 로컬 저장소의 상태는 전혀 바꾸지 않는다.
- git fetch는 다운로드 단계이다.(설치가 아님)
3-3. git pull
원격 저장소의 변경을 fetch하고, 그 이후에 merge 하는 작업의 과정이 워낙 자주있는 일이라,
git은 이 두 가지를 한번에 하는 명령을 제공한다.
git pull 명령이다. 이는, 본질적으로
git fetch 후에 내려받은 브랜치를 병합하는 과정의 단축이다.
3-4. git push
로컬의 변경 사항을 지정한 원격 저장소에 업로드하고,
그 원격 저장소가 새 커밋들을 합치고 갱신하게 한다.
git push가 끝나면, 다른 사람이 원격 저장소에서 해당 변경사항을 받을 수 있다.
즉, git push 는 개인의 작업을 '공개' 하는 개념이다.
