git init
- git initialize → 로컬 깃 저장소에 등록시켜줌
git status
- git 저장소의 상태를 알려줌
** untracked: Git의 관리에 들어간 적 없는 파일
.gitignore
- .gitignore 파일을 만든 후 본문에 git에 등록하고 싶지 않은 파일 이름들을 써주면 그 파일들은 git 저장소에서 제외할 수 있음.
- 즉 무시해도 되는 파일들의 목록!
<형식>
# 모든 file.c
file.c
# 최상위 폴더의 file.c
/file.c
# 모든 .c 확장자 파일
*.c
# .c 확장자지만 무시하지 않을 파일
!not_ignore_this.c
# logs란 이름의 파일 또는 폴더와 그 내용들
logs
# logs란 이름의 폴더와 그 내용들
logs/
# logs 폴더 바로 안의 debug.log와 .c 파일들
logs/debug.log
logs/*.c
# logs 폴더 바로 안, 또는 그 안의 다른 폴더(들) 안의 debug.log
logs/**/debug.log
git add 파일명
- git add 파일명: 파일이 commit 할 준비가 됨
- git add . 하면 폴더 내 모든 파일들이 commit 할 준비가 됨
git commit
- git commit -m "FIRST COMMIT"
- git commit 시 Vi 모드로 진입하게 됨
* 입력 시작: i
* 입력 종료: esc
* 저장 없이 종료: q
* 저장 없이 강제 종료: q!
* 저장하고 종료: wq
git log
- commit 기록을 조회할 수 있는 명령어
git diff
- 파일에 어떤 내용이 변경되었는지 차이점 비교 가
git commit -am "(메시지)"
- git add, git commit을 한꺼번에 할 수 있는 명령어
- untracked 파일이 없을 때 한정하여 사용할 수 있음
- 리눅스는 오픈소스 소프트웨어로, 이는 만든어져 있는 것을 보는 사람들이 업데이트를 하는 것을 의미한다.
이걸 다른 말로 GNU라고 하고, 이 GNU에 대한 라이센스를 GPL이라고 한다. 리눅스란 유닉스라는 대형 컴퓨터 운영체제를 개인용 컴퓨터 OS체재로 만든 것.
- Git 은 리눅스가 만듬. Github는 마이크로소프트 소유
- VCS(Version Control System)는 1) 소스 코드를 저장하고 2) 수정 이력을 추적하며 3) 여러 로컬에서 변경한 내용을 쉽게 병합하게 해줌. VCS에서 가장 중요한 것은 원본 데이터가 "불변해야" 한다는 것!! 원본데이터 전체에 대한 사본을 만들어서 필요한 파일만 수정하고, 별도의 "메타데이터"를 만들어 어떤 파일이 어떻게 수정되었는지 변경사항을 기록한다.
하지만 원본데이터에 전체에 대한 사본을 만든다면 변경되지 않은 파일이 중복되기 때문에 용량이 너무 크다는 문제가 생긴다. 이를 방지하기 위해, 수정되지 않은 파일들에 대해서는 내용을 복사하는 것이 아니라 링크만 따와서 용량을 차지않도록 하는데 이를 soft link 파일이라고 한다. 그러나 이 과정은 너무나도 귀찮은데, 이것을 대신해 주는 것이 바로 VCS이다.
- 특정한 데이터에 대해 v1, v2가 있다고 하자. 이 때 v2가 아닌 v1에 있는 내용을 다시 사용하고 싶다고 하자.
v1을 다시 사용하기 위한 방법에는 두 가지 방법이 있는데,
1) v2 폴더를 삭제하는 것을 "reset"이라고 하고, 2) v1을 복사하여 v3을 생성하는 것을 "revork"라고 한다.
v1을 다시 사용하지 않는 것은, 파일이 많은 경우 중간 버전을 사용하는 것보다 항상 가장 최신 버전을 사용하는 것이 관리하기 용이하기 때문이다.
그러나 VCS는 협업이 안되고, 데이터베이스에 바이러스가 걸리면 데이터가 다 날아간다.
- 협업을 위해서는 형상을 맞추고 변경해야 하므로, pull을 하고나서 push 하는 것이 필수적. 로컬에서 자체적으로 만들고 push 한다면 conflict가 생긴다. CVCS에서는 중앙 컴퓨터만이 VCS 기능을 갖춰 버전 관리를 하기 때문에, 실수하여 pull 없이 push 한다고 하더라도 내용이 날아가는 것을 막을 수 없다. 따라서 모든 컴퓨터가 VCS 기능을 갖춰, 형상이 동일할 때 pull/push 할 수 있도록 한 시스템이 DVCS(Distributed Version Control System)이다.
- DVCS는 모든 컴퓨터가 형상 비교를 할 수 있으며, 형상이 다른 경우 Github에 push를 할 수 없게 되어있다.
<Git의 작동 원리>
- 리셋: 헤더의 포인터를 이전 포인트로 되돌리는 것
- 리셋을 해서 마지막 버전을 날려도, 깃은 자체적으로 백업(reflog)을 남김.
git reset --hard (포인터가 움직이게 하고 싶은 해시 앞 네자리) 해도 복구하고 싶으면 git reflog로 확인을 하고, 다시 git reset --hard (포인터 돌아가고 싶은 해시 앞 네자리) 하면 됨.
즉 reflog 덕분에, 한 번이라도 커밋을 했으면 리셋을 했어도 돌아갈 수 있다.
- 3 way merge: 여러 브랜치들이 공통 조상이 있는 상태에서 각각 개발이 이루어진 후 다시 merge 하려고 하는 것.
- fast forward merge: 개발이 여전히 하나의 선상에서 이루어져 merge 하려는 경우. 이 경우는 conflict 가 발생 안함
- rebase: git에서 브랜치를 합치는 방법으로, 1) 이미 남긴 로그를 수정하고
git rebase -i HEAD~3 : 마지막 헤드부터 3개의 헤드를 끄집어낸다. (VI 에디터 사용법 배우기 - 리눅스 할 때 하게 됨...)
에디터 사용 후 esc 누르고 :wq 하면 나올 수 있음.
- git rebase -i HEAD~3 을 한 후, 끄집어 낸 로그들을 가장 이전 것부터 최근 것까지 찌그러트리는 것을 squash라고 함. 이것을 통해서 로그를 굉장히 예쁘게 관리할 수 있음. 마지막꺼만 vi에디터에서 pick으로 두고 나머지는 pick을 s로 바꿔서 squash
- rebase 시 3-way merge 상황을 하나의 선으로 이을 수도 있음. feature에서 rebase 하면, feature이 main의 뒤로 들어감.
즉 feature 브랜치에서 git rebase main 하면 그림과 같이 합쳐짐
3 way merge의 경우 메인브랜치에서 merge 하기 때문에 팀장이 주로 conflict 하게 됨. 근데 rebase의 경우 브랜치로 main을 rebase하여 땡겨온 후 다시 main branch로 fast forward merge만 하기 때문에 , 팀원이 conflict 해결을 하게 됨. 즉 팀장이 편해짐. 그 말인 즉슨 팀원들 한명 한명이 모두 잘한다는 뜻 ... ^_^ 그렇기 때문에 웬만하면 아직 3way merge 만 해라.. !