- git? gihub??

-Git은 VCS (Version Control System)의 일종이다.
여기서 소스코드란, 코드파일 (ex, index.html)과 같은 파일을 말한다.

- Git/GitHub란? & VCS(Version Control System)

Git이 VCS이다.
VCS에서 Vsms version을 뜻하는데, source code 즉, 코드파일의 버전(수정사항)을 관리하는 시스템이라는 말이다.

즉, 소스코드의 변경사항(version) 내역을 관리하는 시스템 = git.

개발자들은 Version데이터 베이스를 서버에 올려놓고 공유하는데, 이를 "Central VCS server(중앙버전관리시스템)" 라고 한다.

- Central VCS server의 문제점

만약 Central VCS server에 문제가 생겨 저장된 우리의 코드파일에 손상이 가거나 복구하지 못한다면? 끔찍하다.....

이를 해결하기 위해 나온것이 "Distributed Version Control System(분산 버전 관리 시스템) "이다.

중앙 서버 뿐망이 아니라 각 개발자의 컴퓨터에도 최신 버전의 코드 뿐만이 아니라 수정 사항 내역들과 meta 정보들을 전부 다 가지고 있는 방식이다.

---

-GitHub는 분산 버전 관리 툴인 깃(Git)을 사용하는 프로젝트를 지원하는 웹호스팅 서비스이다.

이게 무슨 말이냐~! -> github는 화려한 그래픽 유저 인터페이스(GUI) 제공한다. 반면에 git은 그저 텍스트 입력 방식이다. 또한 github는 여러 다른 편의 기능을 제공한다.

---

q. 왜 최신코드가 아닌 이전의 코드들을 기록, 관리해야하는 걸까?

어떠한 문서를 작성한 경험이 다들 있을것이다, 그때마다 최신의 버전만 가지고 있었을까??
글의 내용이 엉키거나 문제가 생길 경우를 대비하여 이전의 상태로 되돌릴 경우를 대비하여 이전의 내용들도 보관해본 경험이 있을 것이다.

위의 경우와 마찬가지로, 코드 버전 관리할때 더더욱 필요합니다. 팀 단위로 한 시스템을 개발할때는 누가, 어떠한 코드를, 언제 수정 했는지 등의 내역들을 확인,관리 할 수 있는것이 굉장히 중요하다. 또한 종종 동일한 파일에 여러 개발자가 코드를 수정하는 경우가 있음으로 각 수정 사항들을 체계적으로 관리할 수 있어야 함으로 중요하다.

• VSC의 기능
  -코드의 변경 사항 내역 기록 및 관리
  -필요시 이전 상태로 rollback
  -팀단위 개발시 체계적이고 효과적인 협업

---

- github 사용과정

<전체적인 구조 >

[remote와 local을 구분하였고, 아래의 구조와 각 구역에서 진행되는 과정은"<경로에 대한 설명>"을 참고해서 보면된다.]

[Remote] = 깃헙 -> master branch 가 있다.

6(master에 feature/login branch이 생긴다.)
7(PR(pull request작성할 때)을 날린다.=>관리자가 merge를 받아줌)

8.git check master(local의 master branch로 이동)

[Local] = 내 컴터 : master branch 가있다.

1(feature/login 만들어짐)
2(feature/login 만들어짐)

→ merge가 될 경우에만 이런 경로를 따른다.

→순서대로 따라 현재의 위치가 어디인지 생각하면서 과정을 따라가보자

<경로에 대한 설명>

(현재위치: master) => 항상 내 위치가 어딘지 생각하자!

1. branch 생성
   git branch feature/login → feature/login라는 branch ‘생성’

2. 이동

:git checkout feature/login

3. 작업

4. git add . (이건 중간저장의 개념, 점( . )찍어서 걍 계속 저장해주자)

5.git commit -m “내가 담고싶은 정보(ex...login complete)”

6. git push (~에) (~을, 를) (push를 한다.)

=> git push origin feature/login

(origin은 remote에 있는 master branch)

7. PR

------------------------------------------------------------경우1-------------------------------------------------------------------

<merge가 됐다면!!>

local의 master를 업데이트 시켜줘야해 그러면...!!

8.git check master(local의 master branch로 이동)

그 다음에 업데이트
9. git pull origin master

→ 새로운 작업을 위해서는 conflict를 방지하기 위해서 꼭 remote master에서 local master로 업데이트를 해주자!!

------------------------------------------------------------경우2-------------------------------------------------------------------

< conflict가 난다면!!> -> 7번에 이어서...

confilct가 난다면 나의 위치는???

: checkout으로 이동한 적이 없으므로 나의 위치는 아직까지 “feature/login” branch이다.

8-1. git pull origin master를 불러와서 나의 코드와 뭐가 다른지 보고 고친다.(conflict 해결)

그리고!

4-1.git add .

5-1. git commit -m “resolve conflict”

6-1. git push (~에) (~을, 를) (push)

=> git push origin feature/login

(origin은 remote에 있는 master branch)

7-1. PR요청이 없어도 된다!!!!!!!!! PR은 계속같이 있다.

#<자, 드디어 merge가 됐다면>

local의 master를 업데이트 시켜줘야해 그러면,...!!

8-2. git check master(local의 master branch로 이동)

그 다음에 업데이트
9-1. git pull origin master

→ 새로운 작업을 위해서는 conflict를 방지하기 위해서 꼭 remote master에서 local master로 업데이트를 해주자!!

accept current change / accept incoming change/ accept both change

이 중에서 고르고

(굳이 저장(컨트롤 s )할 필요 없이 add 해두된데....)

*꿀팁: commit 만 잘 남기면 잔디가 잘 깔린다.