Let' git it!!!🤙🏻

1. Git /Github 란?
2. VCS(Version Control System)이란?
3. repository 생성 + 관련 명령어(git init, git add remote, git remote -v)
4. local repository / remote repository
5. git clone vs. git pull 개념 및 차이점
6. branch의 개념 + 관련 명령어(branch 생성, branch 이동, branch 제거)
7. git staging 설명 + 관련 명령어(add, commit, push)
8. conflict는 언제, 왜 발생하는가? 어떻게 해결하는가?

1. Git / Github 란?

Git 은 VSC ( Version Control System) 이다.
해석을 해보면 버전을 관리하는 시스템인데 여기서의 버전은 소스코드를 말한다. 그러면 소스코드 버전이란 무엇일까? 바로 소스 코드의 변경사항들에 대한 버전이다. 코드가 어떻게 수정되었는지, 어떤 것이 생겼는지에 대한 것들이다.

그런데 왜 이런 코드에 대한 변경 사항들을 관리해야 할까? 저런 버전 관리 시스템까지 만들면서? 그냥 코딩만 하면 되는거 아닌가? 라는 의문점이 생길 수도 있다.

우리가 이런 버전 관리 시스템 없이 일을 해야 한다고 생각해보자.
우리가 어떤 문서를 작성하거나 프로젝트를 위해서 PPT를 만들어야 하는 상황이라면 그 만들어지는 과정이 처음부터 끝까지 딱 한번에 되는 것은 아닐 것이다.

최종본 1.
최종본 1_1
진짜 최종본
진짜진짜 최종본
....
코딩을 할때 마다 이런식으로 원시적으로 저장을 해야 한다면 정말 고통스럽겠죠? 하지만 VCS는 이런 상황이 생기지 않도록 소스 코드를 효과적으로 관리해줍니다.

지금 우리는 개발을 배울때부터 Git과 함께 시작을 해서 Git 밖에 없을거라고 생각하지만 Git은 약 10년 전부터 많이 쓰이게 된 것이며 그 전에도 다른 VCS가 있었다고 합니다. 하지만 Git이 다른 시스템보다 더 편하고 효율적이기 때문에 지금은 대부분의 개발자들이 깃을 쓴다고 하네요.

Q. 그럼 왜 Git을 쓰는 것일까?

우리가 기존에 쓰던 것이 아닌 새로운 것을 쓰게 된다면 그만큼 배워야 하는 것도 많고 익혀야 하는 것도 많을 것입니다. 저도 윈도우를 쓰다가 맥으로 바꾸었더니 키보드부터 시작해서 터치패드 조작 등 새로운 것을 배워야하고 깔아야 하는 것들도 있어서 시간이 좀 걸렸습니다. 이렇게 새로운 걸 도입하면 회사 입장에서도 그만큼의 비용이 생기게 되는데요 왜 기존에 사용하던 것들을 두고 Git으로 넘어왔을까요?

왜냐하면 Git에는 Version control 뿐만 아니라 그 이상의 기능들이 있기 때문입니다. 그 중 핵심은 바로 협업 인데요.
모든 개발자가 하나의 코드 베이스르 가지고 개발을 할 수 있다는 점이 큰 차이였습니다. 팀으로 일하는 개발자들이 각자 개발을 하다가 그걸 하나의 레파지토리에 합치려고 했을 때, 다른 시스템들은 어려웠지만 Git은 비교적 쉽기 때문입니다.

Q. 협업과 Git & Github

Git이 버전 관리 시스템이라면
Github는 그 깃을 인터넷에 띄운 중앙 서버입니다.

깃이 편하다며, 그럼 깃만 쓰면 되는거지 왜 중앙 서버가 필요해? 그냥 우리가 관리하면 안되는 건가? 라는 생각이 들 수도 있습니다.

자 만약, 개발자 10명이 같은 코드를 가지고 일을 한다고 하면, 그 작업을 할때 기준이 되는 코드가 있어야 하겠죠.

제가 대학생일 때, 대중문화에 대한 수업을 들었는데 팀별로 나누어져 각자 같은 내용의 책을 읽고 토론을 한 후 그에 대한 내용을 올리는 과제가 있었는데요. 교수님께서는 그 올리는 파일의 형식과 예시를 올려주셨습니다. 학생들은 그 형식에 맞춰서 글을 올렸었죠. 그 당시에는 상당히 귀찮게 느껴졌지만 나중에 파일을 정리해 보니 모두가 같은 형식으로 올려서 한번에 합치거나 파일을 관리하기가 굉장히 편했던 기억이 있습니다.

코드에서도 마찬가지로, 기준이 되는 레파지토리(Repository 라서 줄여서 Repo)가 있는데요.
이런 중앙 코드 레파지토리가 있으면 이 레파지토리에는 모든 사람이 접근을 할 수 있어야 합니다. 즉, 중앙 서버가 필요한 것이죠. Github는 그 중앙 서버 서비스를 제공하는 것입니다.

우리는 Github를 쓰지 않아도 우리가 직접 서버를 띄워서 그걸 중앙레파지토리 삼아서 일을 할 수도 있겠지만 그럴 경우에는 관리해야 하는것도 많고 해야 하는 작업도 많아서 편리하고 가격적으로도 괜찮은 Github를 쓰는 것이죠.
또 Github에는 브라우저에서 바로 소스를 볼 수 있다든지 팀을 관리할 수 있다든지 리뷰를 쓸 수 있다든지 하는 여러가지 부가적인 기능들을 제공하고 있으니 안쓸 이유가 없겠죠?

이런 귀여운 고양이도 볼 수 있구요...?

local vs server

자이제 중앙 서버에 있는 코드로 작업을 해야 합니다. 그러면 우선 그 중앙 서버에 있는 소스를 내 컴퓨터 (local)로 다운받겠죠? 이때 우리가 하는 작업이 바로 Clone( 복제 ) 입니다.

매트릭스의 복제인간처럼...통째로 복제된 코드를 가지고 우리의 로컬에서 작업을 하고 그 작업이 끝나면 다시 서버에 올려야겠죠?
그때 하는 작업이 push 입니다.

my local => server ( github)

이렇게 중앙 서버에 push 해서 올라간 코드는 다른 사람들과 공유할 수 있습니다.

그러면 다른 사람은 그 최신 소스를 받겠죠? 이때 이루어 지는 작업이 (pull) 입니다.

여기서 기억해야 할 것은, 처음에 하는 작업은 clone이었고, 최신의 코드를 받는 것은 clone이 아닌 pull 이라는 점입니다.

모든 작업은 중앙 서버에서 일어나는 것이 아니라 로컬 컴퓨터에서 이루어지기 때문에 문제가 있어도 서버가 아닌 내 노트북에서만 일어납니다. 때문에 다른 개발자에게 영향이 가지 않습니다.

가끔씩 우리가 코드를 올리다가 다른 사람과 코드부분이 겹쳐서 올리다가 충돌(conflict)이 일어나는 상황이 발생합니다. 하지만 그것 또한 중앙 서버가 아닌 우리의 컴퓨터 ( 로컬)에서 일어나는 일이기 때문에 중앙 서버에 문제가 생기지 않습니다.

갑자기 깃허브가 서버가 다운되는 상황이 발생한다고 하더라고 우리는 다른 컴퓨터를 임시 서버로 하고 그 서버로 모든 것을 보내서 배포하는 작업도 할 수 있습니다.

Git 세가지 스텝

Modified

수정이 된 상태

staged

중간 저장 상태
( git add)

commit

메인 깃 허브에 저장이 된다.

작업을 만들고 바로 커밋을 해야 하는데 왜 staged라는 중간 단계가 필요한가?
라는 의문점이 들 수도 있을 것 같습니다.

커밋을 한다는 것은 작업이 끝났다. 완성했다는 의미로 봐도 될 것 같습니다. 만약 작업을 하다가 우리가 중간 저장을 하지 않으면 수정한 내용을 되돌리거나 하는 일이 아주 힘들어 질것입니다. 우리가 어떤 작업을 하다가 날라갈것을 대비해서 습관적으로 control s로 저장을 하는 것과 마찬가지인 것이죠.

Basic Git Command

모든 커맨드 라인에는 git이 기본적으로 들어갑니다.

git init

이 파일을 깃으로 관리하겠다는 것입니다.

git add

중간 저장 (staged)

git status

git diff
수정한 내역을 보고 싶을 때 (modified 일때만 볼 수 있음)

git status

어떤 파일을 쓰고 있는지 어떤걸 브랜치 했는지

git log

수정한 히스토리를 보고 싶을 때

git rm

삭제하기

git mv

움직이거나 경로를 바꿀때

-Branch Merging

Branch Merging

깃은 트리구조로 되어 있습니다.
모든것의 기준이 되는 기둥이 바로 master 이며, branch는 그 기둥으로 부터 뻗어서나가는 것이죠. branch 한다는 것은 master에서 하나를 따는 것이라고생각하면 됩니다.

우리는 보통 작업을 할때 master에서 작업을 하지 않고 branch를 만들고 거기에서 작업을 합니다. 그러면 왜 branch를 만들고 거기서 작업을 해야 하는 것일까요?
우리가 협업을 하게 되면 수 많은 사람들이 작업을 하고 수정을 합니다. 그런데 그 기준이 되는 master를 대상으로 수정을 하고 커밋을 하게 되면 그 중심이 되는 것에 계속해서 변경사항이 생기고 그러면 다른 기존의 것들에 영향이 가겠죠. 나는 아직 작업을 마치지 않았는데 다른 사람이 master에 커밋을 해버린다면 내 작업에 영향이 갈것입니다.

그래서 master에서 branch를 따로 만들고 그 branch를 대상으로 작업을 합니다. 그런데 보통은 작업을 기능별로 나누어서 하기 때문에 이렇게 기능별로 나누어서 브랜치를 만들고 작업을 하는 것을 feature branch 라고 합니다.
feature(기능)별로 작업을 한 후에는 다시 master 에 올려서 원래의 것들과 함께 합치겠죠? 이때의 작업을 Merging, 합친다고 합니다.
여기서 merging 또한 중앙 서버가 아닌 우리의 컴퓨터에서 일어나는 작업입니다.

여기서 합친다는 것은 1 + 1 = 2 와 같은 더해주는 것이 아니라 수정 사항을 덮는 것입니다. 그런데 만약 다른 사람과 한 작업에서 겹치는 부분이 일어난다면 어떻게 할까요? 이와 같이 같은 수정 사항때문에 코드가 충돌하는 상황을 conflict 되었다고 합니다. 그러면 깃은 이 겹치는 부분에 대해서 알려주며 어떻게 할 것인지 물어봅니다. 그래서 우리는 그 부분을 보면서 상대방과 함께 수정을 해야 하죠. 이것을 conflict 이 난 것을 해결한다고 합니다.

이런 충돌이 나는 것은 Pull을 하는 상황입니다. 우리는 수정 사항을 올릴때 pull을 해야 합니다. 마치 브랜치가 이렇게 말하는 것과 같죠. "야 우리 이거 업데이트 되었으니까 최신 코드 pull해서 그거 포함한 다음에 push 해줘"
그래서 최신 코드를 pull을 하려고 하는데 그 최신 코드에 내가 작업한 파일과 겹치는 부분이 생기는 것이 conflict 인 것이죠.

master branch에 commit을 한다는 것은 회사에 핵심 역할을 하는 코드에 나의 코드를 올리는 것이기 때문에 책임감이 따르는 행동입니다. 때문에 내가 원하는 파일들만 올린게 맞는지. 잘 돌아가는지. 하는 것들을 잘 체크해야 합니다.
내가 만약 올리고 싶지 않거나 올라가면 안되는 파일들은 gitignore 이라는 파일을 만들어 관리해야 합니다.

참고한 사이트(https://www.linuxnix.com/what-are-the-top-version-control-systems/)