Git 파헤치기

🔨 Git

코드 버전 관리 프로그램(툴), 버전을 편리하게 관리할 수 있도록 도와주는 도구

Git의 목적

1) 버전 관리
2) 동시 협업
3) 백업

버전 관리?

파일의 변화를 시간에 따라서 기록했다가 나중에 특정 시점에 버전을 다시 꺼내올 수 있는 시스템

버전 관리의 장점

1) 지난 과정 확인 가능
2) 언제든 이전 버전의 코드로 돌아갈 수 있음
3) 개발자끼리 협업할 수 있음
수정 시, 파일을 새로 만들면 관리가 힘들기 때문

💻GitHub

Git으로 관리하는 프로젝트를 올려둘 수 있는 사이트
- 외부 컴퓨터를 따로 마련하지 않아도 작업한 내용(백업본)을 내 컴퓨터가 아닌 다른 곳에 저장 가능
- 외부에 컴퓨터를 대신 만들어주는 서비스 (원격 저장소를 대신 제공해주는 서비스)
=> 다른 사람과 협업 가능

---

1. 레포지토리(repository)

저장소
커밋이 저장되는 장소, 프로젝트 디렉토리의 각 버전이 담기는 저장소
프로젝트의 변경 사항들이 버전별로 저장 → .git 디렉토리가 만들어짐 → 이를 레포지토리라고 함

2. 커밋(commit)

무언가를 행하다, 기록하다
프로젝트 디렉토리의 특정 모습을 하나의 버전으로 남기는 동작(행위 & 결과물)
- 커밋하는 당시의 프로젝트 디렉토리의 모습이 사진처럼 레포지토리에 저장됨(그 고정된 결과물 자체도 커밋이라 함)
- 커밋을 통해서 버전관리를 할 수 있음
- 과거의 프로젝트 디렉토리 모습을 볼 수 있음

---

[Git의 3가지 작업 영역]

1. working directory (=working tree)

작업을 하는 프로젝트 디렉토리

2. staging area (=index)

git add한 파일들이 존재하는 영역
- working directory 안에서 수정한 파일을 git add하면 그 파일들이 staging area에 올라가게 되고, 이후 커밋하면 staging area에 있는 파일들만 커밋에 반영 -> 원하는 것들만 선별적으로 커밋에 반영할 수 있음

3. repository

커밋들이 저장되어 있는 영역 (working directory의 변경 이력들 저장)
-> 커밋 시, 스냅샷(snapshot)처럼 repository에 저장

---

✨Git 사용하기

git init 현재 디렉토리를 git이 관리하는 프로젝트 디렉토리로 설정하고 그 안에 레포지토리(.git) 생성

=> 이제 Git으로 버전관리 할 수 있음

❗[첫 Commit을 하기 전에 꼭 해야할 것]

=> git에게 commit한 사람 알려주기(강제)

1) 이름과 이메일주소 설정

git config configure 설정하다, 구성하다

git config user.name "sodait"
git config user.email "sodait@email.com"
=> 커밋 시, 커밋에 이름과 이메일 주소도 함께 저장

2) 커밋할 파일 git add로 지정해주기

git add hello.js
커밋하기 전에는 커밋할 파일을 미리 지정해줘야 함 (수정된 파일의 모습이 커밋에 포함될 것이라 지정하는 것)

3) 커밋메시지 남기기(옵션 -m)

git commit -m "커밋에 관한 정보"

---

git status 상태
깃이 인식하고 있는 프로젝트 디렉토리의 현재 상태를 보여줌

stage: git add로 파일을 staging area에 추가하는 것
(변경 사항은 있었지만 git add를 해 주지 않아 staging area에 추가되지는 않은 파일)


현재 프로젝트 디렉토리 내에서 변경사항이 있는 모든 파일들 한 번에 staging area에 추가
git add .

git reset [파일 이름] : 초기화하다 git add 취소하기 (staging area에 올렸던 파일 다시 내리기)

---

리모트(Remote) 레포지토리 / 로컬(Local) 레포지토리

작업하던 내용 전송을 = 레포지토리 전송이라고 함

- github에서 만든 레포지토리 = 리모트 레포지토리(Remote Repository) 원격 레포지토리
- 내 컴퓨터에 있는 레포지토리 = 로컬 레포지토리(Local Repository)

Remote Repository 사용 이유

1) 안전성 (로컬 레포지토리가 없어졌을 경우 복원 가능)
2) 협업 가능 (리모트 레포지토리를 가져와서 내용 추가 후 다시 커밋 가능)

사용 예시
- GitHub 페이지에서 직접 내용을 수정하거나
- 다른 사람이 그 리모트 레포지토리를 자신의 컴퓨터로 가져가서 수정한 다음 다시 리모트 레포지토리에 git push한 경우


git push : 밀다, 밀어넣다 Local 레포지토리 내용을 → Remote 레포지토리에 보내기
git pull : 잡아당기다 Remote 레포지토리의 내용을 → 자신의 Local 레포지토리에 가져오기

cat README.md : 출력

git clone [프로젝트의 GitHub상 주소] : 복제하다 깃허브 프로젝트의 레포지토리를 그대로 복제

---

git log 기록, 일지 커밋 히스토리 출력
커밋 아이디(=커밋 해시) / 커밋한 사람 / 커밋한 날짜 / 커밋메시지

git log --pretty=online 커밋 히스토리 한 줄에 깔끔하게 보기 (--pretty 다음 =online은 옵션 중 하나)

git show [커밋아이디] (앞 4자리정도까지만 쳐도 됨) : 해당 커밋에 어떤 변경사항이 있었는지 확인 (해당 커밋과 바로 이전 커밋의 차이점 보여줌)

git commit --amend 수정하다, 고치다 가장 최근 커밋 수정하기(→ 커밋 메시지를 수정할 수 있는 vim창 뜸)
git diff [커밋 A 아이디] [커밋 B 아이디] 두 커밋간의 차이 보기

---

HEAD : 보통 가장 최근에 한 커밋을 가리킴(매번 더 새로운 커밋 가리킴)
HEAD가 가리키는 커밋에 따라 working directory 구성

---

branch 브랜치

나뭇가지 하나의 코드 관리 흐름
ex) 하나의 프로젝트 내에서 두 개의 브랜치를 만들 수 있음(두 가지 버전 ex.유료/무료)

맨 처음하는 커밋(original) = root(뿌리) commit

On branch master 마스터 브랜치 위에 있다 => 레포지토리를 만들고 커밋하면 자동으로 생기는 브랜치(기본 브랜치)

git branch [만들고싶은 브랜치 명] 새로운 브랜치 만들기
git checkout [가고싶은 브랜치명] 브랜치 이동하기