Git fundamentals (w/GitHub)

🖐 반드시 알아야 하는 Git

 

* 저번 시간에 couresra 강좌에서 VCS에 대해서 배웠음

What is VCS?

* 이제 VCS의 일종인 Git에 대해서 알아보자! (추가로 GitHub까지)

 

(참고로 git은 그림으로 이해하는게 BEST다. 그리고 직접 해보는게 장땡!)

 

<타 VCS 종류와 Git의 차이점?>

Git은 일종의 snapshot을 찍어 보관한다

'Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.'

▶ 즉 타 VCS는 기존 file이 있으면 새로운 변경사항이 생길 때마다 해당 변경사항이 기존 file에 반영하는, file-based changes로 (delta-based Version Control) 저장되는데 / Git은 순간순간의, 일종의 snapshot을 카메라로 찍어내듯이 변화가 생겼을 때 전체의 snapshot 순간을 저장한다. 

 

- 타 VCS(상단)와 git(하단)의 차이점 (그림) -

 

---

- 원격 GitHub 저장소와 함께: git 관련 명령어 - 

 

* local 환경에서 작업하는 git & 그리고 원격으로 연결하여 작업 가능한 GitHub까지 합쳐서 - 서로 간의 관계로 알아보면..

 

 

🖐 Git은 코드의 여러 변경 이력들과 기록들을 쉽게 추적하고 파악할 수 있기 때문에 '코딩의 필수 기술' 중 하나

🖐 따라서 추적 & 저장 기능 때문에 우리는 git을 통해 이전 기록으로 돌아갈 수도 있음 (당연히 작업물을 남길 수도 있음)

(CLI 뿐 아니라 GUI로도 최근에 git을 지원해줌 - 세상만사 편해짐 😸 ㅎㅎ)

🖐 예를 들어 최신 버전에 문제가 생겼을 때 이전 버전으로 다시 돌아가서 작업을 수행하거나 & 또는 새로운 버전을 다르게 만드는 등, 여러 버전을 만들어 (일종의 branch로 나열해) 관리할 수 있는 GIT

---

≪Git을 사용해 GitHub을 이용하는 방법은 위와 아래  두 그림에 모두 정리됨! 완전 깔.끔. 👍≫

 

🌟 local이 remote로 올리는 방법 / 반대로 remote에서 local로 가져오는 두 방향 모두 공부해 보자 🌟

 

🌟 먼저 git init으로 git 저장소 만들기 🌟

 

→ 일단 해당 위치에 'git으로 remote하게 관리하겠다'라고 선언하는 git 명령어이다. 

(+) .gitignore 생성 - git으로 원격 위치와 왔다갔다 하기 어려운 file들이나 git으로 public하게 관리를 하면 안되는, 보안상의 문제가 있을만한 모든 file들이나 변경사항들은 gitignore file을 생성해 해당 파일에 저장한다.

 

① GitHub → local repo로 가져오기

 

1> 먼저 해당 repo를 내 GitHub 계정의 repo로 forking

 

2> fork된 내 계정의 repo 주소를 복사해 git clone 뒤에 붙여 내 local로 가져옴

(여기서 git remote -v를 사용해 원격으로 연결이 된 branch 이름과 상태를 알 수 있음)

 

★ 여기서! git clone & git pull & git fetch & git merge ? 차이점 ★

 

👆 git pull은 현재 내가 local에서 작업하고 있는 '도중에' 원격 repo의 새로운 내용을 local로 가져오고 싶을 때 사용

✌️ git clone은 애초에 처음 작업할 때 초반에 원격 repo 내용 모두를 그대로 가져올 때 사용

(git clone 처음에만! 이후 원격 repo update될 때마다 git pull로 조금씩 조금씩 local로 가져오는 시나리오가 BEST)

 

🤟 git pull = git fetch + git merge

 

- 역시 그림을 통해 확인하면 - (master branch가 아니라 'main' branch입니다. 인종차별용어 금지됨) -

 

 

→ git fetch를 통해 현재 내가 작업하고 있는 branch를 tracking하고 있는 원격 branch로만 fetch한다

→ 그리고 git merge 과정을 통해 remote branch의 변경 사항을 현재 내 local branch로 가져올 수 있다.

→ 그리고 이 git fetch + git merge 과정을 합친 게 'git pull' 과정!

 

▦ 여기서 git fetch한 뒤 현재 local branch에 변경사항이 tracking되어 있다면, git merge하는 과정에서 conflict! 충돌 발생 (주의!) ▦

 

Q. 그렇다면, 도대체 왜, git pull 한번에 하면 될걸, 왜 git fetch + git merge 이렇게 나눈 것일까?

A. for 협업!

→ 한 프로젝트에 여러 developer들이 다양한 branch에 작업을 하고 main branch에 merging하는 과정을 거칠텐데, 여기서 한 developer가 외부에서 fetching해서 가져온 작업들을 바로 merging하는 작업까지 거친다면, 다른 developer들의 동의 없이 바로 local branch에 변경이 발생한다. 같이 협업하는 과정에서 일종의 developer들끼리 일관된 consensus가 발생해야 하고, 동의를 얻으면 git merge 진행, 아니면 취소하는 절차를 밟게 된다!

 

3> branch 확인(git branch) + 사용할 branch working directory로 가져오고(git checkout) 작업 시작!

→ 일단 여러 branch가 있는 지 확인한다. default로는 main이나 파생된 다른 branch가 있는 지 git branch로 확인
(git branch -al이면 원격 포함 모든 branch 종류 출력)

→ 내가 원하는 다른 branch에서 작업을 하고 싶다면 git checkout --branchname을 통해 작업 branch를 switching!

 

---

② 내 working directory에서 작업한 결과물을 GitHub으로 내보내기 (git clone 결과 내 local에서 만들어진 localrepo)

 

1> working directory에서 여러 파일들을 수정하는 등 작업을 완료하였다면 staging area에 올리기 위해 git add

→ 변경사항이 이제 git에 의해 추적되기 시작 (git add ./을 사용하면 모든 file이 staging area로 올라가는데 이는 위험하므로 정확히 commit할 대상이 되는 file들만 git에 기록되게끔 git add 뒤의 일부 파일들만 올린다)

 

2> git add된 staging area에서 최종적으로 git commit -m 'commit message'를 사용해 local repo에 올리기 (커밋 메시지 필수)

(※ git status를 통해 어떤 file들이 working directory, staging area, localrepo에 있는 지 여러 상태들을 한 눈에 알 수 있음)

 

Q. 왜 staging area를 따로 둬서 git add & git commit 이렇게 두 과정을 거치게 하는 걸까요?

A. (by Stackoverflow)

-1- 'staging helps you split up one large change into multiple commits' : 로컬에 여러 변경들이 있었는데 이 변경들을 개별적으로 구분하여 따로 원격 repo에 올리고, 다른 팀원들이 각 변경들을 절차적으로 쉽게 이해할 수 있게 하고 싶을 때 - 변경들 부분부분마다 git commit을 올릴 수 있다는 장점이 존재!

 

-2- 'staging helps in reviewing changes' : staging 단계에 있는 file들을 git diff를 사용해 (git commit 하기 이전) 여러 변화들을 살펴볼 수 있다. 따라서 git을 사용해 우리는 최종적으로 어떤 부분에 문제가 있고 어떤 변화가 있는 지 세심하게 확인할 수 있다는 장점이 있음!

 

-3- 'staging helps when a merge has conflicts' : merge가 발생하게 되면 staging area에 내용이 반영된다 (branch 합병!) 

 

-4- 'staging helps you keep extra local files hanging around' : 혼자 추가적으로 local file을 수정하고 반영하고 싶을 때 해당 branch에 있는 작업을 바로 commit하거나 일부만 staging area에 올려 나만 나름대로 관리가 가능하다!

 

-5- 'staging helps you sneak in small changes' : 큰 작업을 한다고 가정할 때, 일부 변화만 반영을 해야 한다면 쉽게 staging area에 있는 일부만 commit해서 올릴 수 있다. 이는 staging area가 존재하기 때문에 일부를 골라서 commit할 수 있다는 점!

 

(+) git log를 통해 변경사항을 확인할 수 있음 (여러 commit 기록 확인 가능)

 

3> git push로 내 GitHub 계정 remote repo에 올리기

→ ex) git push origin main - origin이라는 원격 branch에 내 local 환경에서 작업한 main branch가 올라감

 

4> GitHub 사이트에서 forked된 내 repo에 pull request 버튼 클릭! (main repo 관리자의 승인이 나면 반영)

→ 이제 실제 main hosting GitHub repo에 내가 직접 변경한 부분이 commit message와 함께 실제 PR로 반영된다

 

* 간단하게 git & github 기초에 대해서 알아봄 🍁 (꼭 기억할 부분!) *

---

* 그림 출처) https://velog.io/@kbs5665/Git-Workflowpair-programming

* 출처 - git 설명 공식 docu) https://www.git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F

* 출처) fetch vs. pull - https://medium.com/@sabbirhossain_70520/git-fetch-vs-git-pull-691823ed4239

* 출처) https://www.daleseo.com/git-init/

* 출처) https://kimcoder.tistory.com/288

* 출처) https://stackoverflow.com/questions/49228209/whats-the-use-of-the-staging-area-in-git