Git과 GitHub

웹 개발 공부를 시작하면서 생활코딩 강의를 들었다. 깃허브를 이용한 웹 호스팅강의에서 깃허브에 대해 처음 알게되었고,

깃허브에 가입을 하게 되었다. 간단히 깃허브에 대해 알게되고 호스팅도 해보면서 신기함을 느끼고 알아보니 개발자들이

꼭 써야하는 페이지 라고 해서 더 알아보려다가 뭔가 어려워서 좌절... 하고 자주 안들어가게 되었다.

그리고 첫 팀플을 하게 되었는데, 일단 팀원들이 각자 작업을 하다가 드는 생각이 '나중에 어떻게 합치지...?' 였다...

그래서 다시 찾아보게 된 것이 바로 깃허브. 깃허브로 협업을 하면 아주 쉽게 합칠 수 있다는 것을 알게되고,

바로 공부해보았다.

 

공부를 하면서 알게된 첫 사실. 깃(Git)과 깃허브(GitHub)는 다른것이다..!

 

깃허브를 사용하여 작업한 것들을 합친다고 말하지만, 엄밀히 말하면 우선 '깃(Git)'을 사용하고, 깃허브에 저장 하는 개념이다. 그렇다면 깃허브를 알기 전 깃부터 알아야 한다.

 

깃 (Git)

 깃(Git)은 2005년에 리누스 토르발스에 의해 개발된 분산형 버전 관리 시스템(Version Control Systems)으로, 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 시스템이다.

깃의 주된 기능은 소스 코드의 버전을 관리하고, 여러 사용자들 간에 파일 작업을 조율, 즉 협업 시에 파일 관리를 도와준다.

우선 Git의 기본 용어들을 알아보자.

 

-Repository : 사용자의 히스토리,태그,소스를 브랜치에 따라 버전을 저장하는 저장소. 작업자가 변경한 모든 히스토리를 확인 가능.

-Working Tree : 저장소를 어느 한 시점을 바라보는 작업자의 현재 시점

-Staging Area : 저장소에 커밋하기 전에 커밋을 준비하는 위치

-Commit : 현재 변경된 작업 상태를 점검을 마치면 확정하고 저장소에 저장하는 작업

-Head : 현재 작업중인 Branch를 가리킨다.

-Branch : 가지 또는 분기점을 말하며, 어느 분기를 복사하여 가지처럼 뻗어 나와서 작업을 하는 작업영역이다. 이 Branch에서 작업을 한 후에 완성이 되었을 때 Merge를 하여 작업을 한다.

-Merge : 다른 Branch의 내용을 현재 Branch로 가져와 합치는 작업을 의미.

 

작업 순서를 예를 들면서 용어를 적용시켜 보겠다.

프로젝트를 시작하려고 한다.

1. 우선 로컬(컴퓨터)에 작업을 저장할 저장소(Repository)를 만든다.

2. 그리고 이제 파일을 생성하고 작업을 한다. 깃은 로컬 저장소에서 사용하기 때문에 인터넷이 없어도 사용 가능하다.

3. 로컬에서 작업(소스코드, 파일을 변경)을 하고, 지금까지 작업한 내용을 저장(Commit)을 하고싶다.

4. 이 때  작업을 한(변경사항이 있는) 파일들을 Staging Area에 놓고 준비를 한다.

5. 내가 무슨 작업을 했는지 메세지를 남기고 Staging Area에 있는 파일들을 저장소(Repository)에 커밋 한다.

그리고 나는 나의 프로젝트에 새로운 기능을 추가하고싶다. 그런데 원본 파일들에 막 작업을 하면 왠지 불안하다.

뭔가 문제가 생겼을때 복구하기 힘들것 같다는 생각을 하게 된다.

6. 이 때 지금까지의 작업을 복사해서 새로운 작업영역(Branch)을 만든다.

7. 이 브랜치에서 작업을 해보고 기능이 아주 잘 되서 원본에 합치기(Merge)를 한다.

 

깃을 사용하면 이런식으로 인터넷 없이 로컬에서 작업한다.

그러면 깃허브는 뭔가?

 

깃허브(GitHub)

깃허브는 바로 이 로컬의 Git을 온라인에 저장할 수 있는 저장소이다.

나의 로컬 저장소의 브랜치들, 브랜치의 소스들, 소스들의 커밋내역을 깃허브 저장소(온라인 Repository)에 올려서 저장할 수 있다.

그리고 여러 사람들이 협업을 할 때 깃허브를 사용하는데, 협업이 아주 수월해진다.

여러 사람이 하나의 깃허브 저장소를 공유하며, 여러 브랜치를 만들어서 작업을 해 나간다.

우선 나의 로컬에서 작업을 하면서 커밋을 하고, 이 커밋내역을 깃허브에 올린다.(Push)

이 때 나의 커밋에 다른 사람들이 변동된 라인마다 코멘트를 남길 수 있다.

"~~~이렇게 하는것 보다는 ~~~이렇게 하는게 좋을 것같아요" 처럼 실시간으로 피드백을 해줄 수 있다.

그리고 나의 브랜치에서 기능이 완성되어서 원본(Master)에 Merge하려고 한다.

원본에 브랜치를 합치는 것은 굉장히 조심해야 하는 작업이다.

그래서 Merge 요청(Pull Request)을 하면, 원본 파일과 브랜치 파일간의 충돌(Conflict)이 있을 때 깃허브가 우선 막아준다.

그리고 충돌이 없다 하더라도 협업 팀원들이 Merge 하려는 브랜치의 작업 내용을 확인했을 때 썩 좋지 않으면 코멘트를 남기면서 요청을 취소할수도 있다.

이런 식으로 깃허브는 각자의 로컬 저장소에서의 작업내용을 저장할 수 있다.