버젼관리
버전 관리란 파일의 변화를 기록하며 추후 특정 버전으로 불러올 수 있는 시스템을 말한다.
그렇기에 무언가 잘못되었을때 복구할 수 있고, 소스 코드의 변경사항을 자동으로 추적이 가능하게된다.
추적이 가능해지면 코드가 어떤 이유로 쓰였는지 알기 쉽고 대규모 작업을 안전하게 진행 할 수 있다.
버전관리의 종류
버전관리는 로컬형, 중앙집중형, 분산형으로 나눌 수 있는데 이는 버전관리가 어디서 이루어 지는지에 따라 다르다.
1. 로컬형
- 대부분 디렉토리로 개인의 컴퓨터에 파일을 복사하고 수정하는 방법을 쓰는데 이 방법은 간단하지만, 잘못되기 쉽고 개개인이 데이터를 가지고 있기에 데이터 관리가 힘들다.
거기에 CD와 디스크와 같은 실물이 존재하는 경우도 있어 물리적으로 데이터가 파괴될 가능성도 존재한다.
2. 중앙집중형
- 프로젝트를 진행하기 위해 여러사람이 해야 할 때 파일을 관리하는 방법으로 파일을 관리하는 서버가 따로 존재하며 클라이언트가 중앙 서버에서 필요한 파일을 받아 사용(checkout)한다.
- 이는 누가 무엇을 하는지 알기 쉬워 관리자가 관리하기 편하고 모든 로컬 데이터를 관리하는 것보다 데이터 관리가 훨씬 쉽다.
- 하지만, 서버에 문제가 생기면 문제가 생긴 시간만큼 협업이 불가능해지며 서버가 있는 하드디스크에 문제가 생기면 모든 히스토리를 잃게된다.
3. 분산형
- git가 여기에 해당하며 단순히 checkout을 하는게 아니라 저장소를 히스토리와 더불어 통채로 복제한다.
그렇기에 서버에 문제가 생기더라도 복제물로 다시 복구하기 쉽다.
- 각자가 서버를 가지고 있는 형태라 각자의 서버를 공유하며 파일을 공유하기 쉽다.
Git
다른 버전관리 시스템과 Git의 차이점은 데이터를 다루는 방법이 다르다.
대부분의 VCS는 각 파일의 변화를 시간순으로 관리하며 이를 델타 기반이라고한다.
Git은 데이터를 파일 시스템 스냅샷(snapshot)의 연속으로 취급하고 크기가 아주 작다.
Git은 파일이 달라지지 않았으면 성능을 위해서 파일을 새로 저장하지 않고, 이전 상태의 파일에 대한 링크(link)만 저장한다. 즉, Git은 데이터를 스냅샷의 스트림처럼 취급한다.
Git에서 관리하는 상태는 3가지가 있다.
Committed : 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미한다.(수정하고 저장한 상태)
Modified : 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않은 것을 말한다. (수정만 한 상태)
Staged : 현재 수정한 파일을 곧 커밋할 것이라고 표시한 상태를 의미한다.
Git 명령어
| 명령어 | 설명 |
| git commit | git를 커밋한다.(변경 내용을 확정한다.) |
| git branch [브랜치 명] | 브랜치를 만든다. |
| git branch -f [브랜치명] [이동위치] | 브랜치를 원하는 곳으로 이동시킨다.(헤드 상관없음) |
| git checkout [브랜치 명] | 브랜치 명을 적은 곳으로 헤드를 이동한다. |
| git merge [브랜치 명] | 흩어진 브랜치를 합친다. |
| git rebase [브랜치 명] | 커밋을 모으고 복사한 후 다른곳에 떨어뜨려 커밋의 흐름을 보기좋게 한줄로 만들수 있다.(head가 움직여서 브랜치명 아래로 간다.) |
| git rebase [브랜치 명][브랜치 명] | 헤드와 상관없이 작동하며 앞에 적은 브랜치 아래로 뒤에적은 브랜치가 이동한다. |
| git rebase -i [브랜치 명]~[숫자] | 커밋의 순서를 바꾸거나 제외 하거나 할 수 있다. (브랜치 명만 입력 시 브랜치 아래 모두 고를 수 있다.) |
| git reset | 애초에 커밋하지 않은 것처럼 예전 커밋으로 브랜치를 옮긴다. |
| git revert | 브랜치를 복사해서 사용하는 명령어로 헤드 기준 위에 복사 |
| git cherry-pick [커밋 명][커밋 명] | 원하는 커밋을 복사해서 헤드 아래로 가져온다. |
| git commit --amend | 커밋의 내용을 변경한다. |
| undo | 명령을 되돌린다. |
| git tag | 특정 커밋에 어떤 내용을 남긴다.(보통 버전을 남기는데에 사용한다.) |
| git remote(원격) | 원격 저장소는 오늘날의 클라우드 시스템을 떠올리면 된다. git remote는 또 하나의 컴퓨터에 있는 자신의 저장소의 복사본을 만들며 일반적으로 인터넷을 통해 커밋을 주고받는 등의 대화가 가능하다. |
| git clone | 서버에 저장되어 있는 데이터를 로컬에 복사하는 명령어로 원격 브랜치는 특정한 목적을 제공하기 때문에 특별한 송성이 있다. 먼저 저장소의 상태를 반영하며 로컬에서의 작업과 공개적으로 되고있는 작업의 차이를 이해하는데 도와준다. |
| git fetch | 로컬에서 나타내는 원격 저장소의 상태를 실제 원격 저장소의 상태와 동기화한다. (언제 파일의 상태가 변할 지 모르기에 자주 하게 되는 명령어이다.) 로컬에 없는 커밋을 다운로드하고 존재하는 커밋을 업데이트 한다. 원격 저장소의 내용을 변경하면 원격 브랜치 또한 그 영향을 반영한다. |
| git pull | 없는 커밋을 다운로드 받은(fetch) 후 merge합치는 두 명령어를 묶은 명령어다. + git pull이 있어도 pit fetch가 필요하다. git fetch와 git pull 내용의 차이가 심할 수가 있기에 git pull만 사용하면 파일에 충돌이 날 수 있기 때문이다. |
| git push | 로컬의 변경을 원격 저장소에 업데이트 한다.(git fetch의 반대) 원격에 없는 커밋을 업로드 하고 원격 브랜치를 업데이트 한다. |
상대참조
| 기호 | 설명 |
| Head | 현재 체크아웃 된 커밋을 가르키며 대부분의 명령어는 헤드에서 이루어진다. (현재 작업중인 커밋) |
| ^(캐럿) | 특정 커밋의 부모로 이동 - ^^ : 와 같이 붙일 수 있다. - ^2 : 부모가 둘일 때 두번째 부모 |
| ~(숫자) | 특정 커밋의 (숫자) 번째 부모로 이동 |
+ git branch [브랜치 명] [브랜치 명]~^2^ 와 같이 여러가지를 붙여서 쓸 수도 있다.
추가
| 명령어 | 설명 |
| git push origin [브랜치1]:[브랜치2] | 로컬에 있는 브랜치 1에서 서버로 업로드 브랜치 2까지 |
| git fetch origin [브랜치1]:[브랜치2] | 서버에 있는 브랜치 1에서 서버에서 로컬로 다운로드 브랜치 2까지 |
| git push origin [NULL]:[브랜치] | '없음'(NULL) 을 푸시해서 브랜치가 사라진다. |
| git fetch origin [NULL]:[브랜치] | '없음'(NULL) 을 패치해서 브랜치가 추가된다. |
추가내용
Remote rejected
메인 브랜치는 보통 잠겨있고 테스트를 거친 최종만이 올라갈 수 있다.
그렇기에 새롭게 브랜치를 만들고 작업을 한다.
rebase 와 merge 의 차이
merge : 작업 이력이 남지만, 커밋트리가 복잡하다.
rebase : 커밋트리가 단순해서 보기쉽지만, 작업이력이 남지않는다.
원격 명령어
원격 명령어는 로컬과 서버와 연동하여 로컬에 파일을 서버에 업로드 하거나 서버의 파일을 로컬에 다운로드 하는 등의 활동을 할 수 있다.
ex) git push, pull, fetch
<revort> : <place>
colon refspec로 <soure> : <destination>
Git 명령어 배우는 사이트
https://learngitbranching.js.org/?locale=ko
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
learngitbranching.js.org