깃의 개념과 구조, 명령어 사용법(커밋,push, pull, 초기화, 브랜칭 생성 및 머지)

안녕하세요. 

 

오늘은 형상관리 소프트웨어 깃에 대해 알아보겠습니다. 

 

깃에는 크게 깃허브와 깃랩이 있습니다.

 

국내에서는 깃허브가 사용도가 굉장히 높고 깃랩은 깃허브에 비해 인지도가 현저히 낮죠.

 

깃과 관련된 형상관리 소프트웨어가 두개이지만 다행이 깃의 개념과 구조, 사용법 모두 같으니 

 

두 소프트웨어를 각각 공부할 필요는 없습니다. 

 

 

깃의 개념과 구조를 알면 형상관리를 하며 일어날 수 있는 위기상황에 적절한 대응을 하는데 큰 도움이 될 것입니다. 

 

 

목차

• 깃의 개념과 구조
• 깃 연동
• 깃 사용법(소스 올리기)
• 깃 사용법(커밋내용 보기)
• 깃 사용법(로컬 소스 복원)
• 깃 사용법(잘못올라간 소스 복원)
• 깃 사용법(소스 내려받기)
• 브랜치 생성 및 원격지 머지

 

 

깃의 개념과 구조

 

 

 

 

 

깃은 위와 같은 구조로 이루어져있습니다.

 

다른 형상관리 프로그램과 차이점은 로컬에 저장소가 하나 더 있다는 것입니다. 

 

또한 stage area 라는 영역도 다른 형상관리 프로그램에는 없는 영역이죠. 

 

working directory는 실제 소스가 저장되어있는 공간입니다. 

 

소스를 원격지인 깃에 올리기 위해서는 위의 파란색 화살표 경로인 add -> commit -> push의 절차를 거치게 되며,

 

소스를 내려받기 위해서는 위의 살구색 화살표 경로인 fetch -> merge 또는 checkout 이거나 pull의 절차를 거칩니다.

 

 

소스를 직접 올려보며 깃의 구조에 대해 깊게 알아보도록 하겠습니다. 

(자세한 사용법은 사용법을 설명하면서 하겠습니다. 우선, 구조 설명부터 하겠습니다.)

 

 

먼저 위와 같은 프로젝트가 있다고 할 때, 제가 //변경사항 발생이라고 소스 코드를 수정하였습니다. 

 

그렇게 되면 해당 소스파일이 Unstaged Changes 영역에 발생하고 이 소스를 초록색 +버튼을 누르면 staged changes로

 

이동시킬수 있습니다. 이때 이 staged changes가 stage area 영역이고 초록색 + 버튼을 누른 것이

 

working directory에서 stage area로 소스파일을 add 작업을 한 것입니다.  

 

 

그런다음 위와 같이 커밋메세지 창에 커밋메시지를 작성해주시고 commit을 누르면 로컬 저장소까지만 올라가고

 

commit & push 버튼을 누르면 원격지 저장소인 깃에 올라가는 것입니다. 

 

구조를 단계별로 알기 위해 commit버튼을 눌러 commit을 먼저 하겠습니다. 

 

 

 

 

 

커밋을 하게 되면 history에 커밋 내역이 작성됩니다. 

 

위에서 우리가 커밋메시지를 메인소스 변경이라고 작성했는데 해당 커밋이 작성되어있음을 확인 할 수 있습니다. 

 

이전 커밋 내역들도 볼 수 있죠. 

 

그리고 위의 이미지에서 fea25.... 으로 이상한 문자들이 있는데 이는 커밋내역을 구분하기 위한 커밋 해시입니다. 

 

저 커밋 해시로 실제 커밋내역을 구분하는 것이죠. 

 

 

 

스프링 프로젝트를 다뤄본사람들은 위와 같은 구조가 익숙할 것입니다. 

 

위의 폴더는 방금 제가 올린 프로젝트 폴더입니다. 

 

위와같이 프로젝트 폴더 아래 .git이라는 숨김폴더가 있을 것입니다. 

 

해당 폴더가 로컬 리포지터리에 해당하는 부분입니다. 

 

 

폴더를 들어가보면 위와같은 구조로 나눠져 있습니다. 

 

 

/logs
브랜치별로 커밋내역이 로그로 기록됨

 

/objects
실제 커밋한 데이터들이 저장되는 곳
(참고, 해시값으로 변환되어 저장)

 

/refs
브랜치별 마지막 커밋내역 저장
refs 하위 heads는 로컬 브랜치, remotes는 원격지 브랜치

 

 

 

 

refs 폴더에 들어가서 확인을 해보니 우리가 마지막에 커밋한 커밋해시가 저장되어있음을 확인할 수 있습니다. 

 

허나 지금은 로컬 저장소까지만 저장되어있는 것이고 아직 원격지에는 저장이 되어있지 않습니다. 

 

 

 

 

 

원격지의 히스토리를 확인해보니 최신 커밋내역이 우리가 작성한 "메인 소스 변경"이 아닙니다. 

 

커밋해시도 fea25...이 아닙니다. 

 

우리는 커밋만 했고 push를 하지 않았으니 당연히 원격지에는 우리가 커밋한 내용이 아직 올라가지 않은 것입니다.

 

다시 이클립스에서 로컬 히스토리를 확인하여 push를 해보겠습니다. 

 

 

 

 

위와 같이 push를 했다면 원격지에도 우리 소스가 올라갔을 것입니다. 

 

 

 

원격지 git에서 확인을 해보니 위와 같이 커밋내역이 생성됨이 확인이 됬네요.

 

커밋내역을 클릭해보면 아래와 같이 수정한 부분을 친절하게 알려주는데요.

 

 

1changed filed은 1개의 파일이 수정됬다는 뜻이고 1addition은 한줄 추가 됬다는 뜻이고

 

0 deletions은 한줄 삭제됬다는 뜻입니다.

 

 

이렇게 소스를 직접 올려보며 깃의 구조와 개념에 대해 알아보았습니다. 

 

이제 깃을 사용하는데 있어 자주사용되는 명령어들을 개념과 함께 알아보도록 하겠습니다. 

 

 

 

깃 연동

 

먼저 깃에 들어가 리포지터리를 하나 만들어주세요. 

 

 

리포지터리를 만들면 위와같이 리포지터리의 https 주소를 알려주는데 리포지터리의 주소를 복사해주세요. 

 

 

그런 다음 이클립스에서 연동하려는 프로젝트를 우클릭하고 [Team] -> [Share Project...]를 클릭해주세요. 

 

 

 

 

 

 

깃을 선택하고 해당 프로젝트를 선택하고 create repository를 누른 다음 Finish 버튼을 눌러주세요. 

 

원격지 리포지터리와 로컬 리포지터리를 연동하려면 첫 커밋을 push 해야 합니다. 

 

이전에 깃의 개념과 구조를 통해 알아본 push를 똑같이 진행하겠습니다. 

 

 

모든 소스를 add 하고 커밋메시지 작성후 commit&push 버튼을 누르면

 

 

 

 

 

위와 같은 창이 뜨는데 URI에 이전에 복사해두었던 깃 리포지터리의 https 주소를 복사하고

 

아이디 비밀번호를 입력해주세요. 

 

그런 다음 push 버튼을 누르면 로컬 리포지터리와 깃 리포지터리가 연동이 됩니다. 

 

 

 깃 사용법(소스 올리기)

 

소스를 올리기 위해서는 위에서 설명햇던 것처럼 stage에 add 후 commit&push를 해야합니다. 

 

add, commit,push는 이해가 됬을테니 생략하도록 하겠습니다. 

 

이후 나오는 커밋내용과 소스 복원 등의 방법을 알면 깃 소스 올리는데 큰 도움이 될 것입니다. 

 

 

 깃 사용법(커밋내용 보기)

 

 

 

 

위와 같이 이클립스에서 깃 항목을 선택하고 깃 리포지터리 목록 중 원하는 프로젝트를 선택해주세요. 

 

그런다음 history탭을 선택하면 커밋내역을 볼 수 있습니다. 

 

 

 

 

만약 특정 커밋이 어떤 파일을 수정시켯고 어떻게 변화됬는지 알고 싶다면

 

해당 커밋을 클릭 하면 오른쪽 하단 처럼 수정된 파일 목록이 나옵니다. 

 

이때 파일을 더블 클릭하면 파일의 변화된 내용을 라인별로 알려줍니다 

 

 

 깃 사용법(로컬소스 복원)

 

소스관리를 하다보면 여러가지 상황에 올 수 있다. 

 

한 두명의 개발자가 아닌 수십명 수백명의 개발자들이 함께 하나의 프로젝트를 형상관리 할때는 더더욱 그렇다.

 

혼자서 개발을 할때면 크게 상관없지만 여러명이 같이 개발을 할때는 

 

개발을 하는 워크스페이스와 형상관리하는 워크스페이스를 별도로 분리하여 관리하는 것이 좋다. 

 

개발한 소스를 형상관리 워크스페이스에 옮겨 소스를 올릴려고 하는 과정에서 만약 

 

올라가면 안되는 소스가 옮겨졌는데 수십개의 파일을 옮겨 하나하나 다시 원복하는게 불가능할 때 

 

소스를 다시 초기화 하는 명령어들이 있다. 

 

 

 

- Reset - Soft, Mixed, Hard 옵션

 

 

 

Reset 명령어는 사용자가 선택한 커밋 시점의 내용으로 로컬 소스를 초기화 하고 해당 커밋 이후의

 

커밋내역을 모두 삭제합니다.

 

단, 당연히 로컬에서만 삭제가 되는 것이겠죠. 원격지의 커밋 내역은 삭제되지 않습니다. 

 

Soft 옵션은 커밋내역만 초기화 시키고 stage와 로컬 소스는 변화되지 않는 옵션입니다. 

 

Mixed 옵션은 커밋내역과 stage를 초기화,

 

Hard 옵션은 로컬의 모든 영역 커밋내역과 stage area와 로컬 소스를 초기화 시키는 명령어입니다. 

 

Reset 명령어의 동작 방식은 로컬 리포지토리의 커밋 취소입니다.

 

원격지에 반영하기 전에 개발자가 로컬 리포지토리에 형상관리하며 잘못된 부분이 있다면 Reset시점 이후 커밋 내역을 삭제하고

 

Reset 시점 부터 원격지에 반영하려고 하는 경우에 사용하면 유용할 것 같습니다.

 

 

깃 사용법(잘못올라간 소스 복원)

 

실수로 올라가면 안되는 내용이 원격지까지 올라간 경우 다시 복원하는 방법에 대해 알려드리겠습니다. 

 

방금 살펴본 reset 명령어는 모두 로컬영역을 초기화 시키는 명령어입니다. 

 

원격지에 이미 올라간 커밋내역을 삭제시키는 방법은 없고 해당내용을 제거한 내용을 커밋해야합니다. 

 

 

 

 

위와 같이 잘못올라간 커밋 내역에 우클릭을 하고 Revert Commit을 하면

 

해당 커밋내역을 초기화 하는 커밋 내역이 발생합니다. 

 

 

위와 같이 Revert "메인 소스 변경" 이라는 우리가 선택한 커밋을 Revert한 커밋이 발생합니다. 

 

이 상태에서 push까지 하게 되면 "메인 소스 변경"이라는 커밋메시지로 올라간 커밋 내용이 다시 초기화 되는 커밋이 

 

원격지까지 올라가게되며 원격지에 해당 커밋 내역이 이전 버전으로 초기화가 됩니다. 

 

 

 

소스를 확인해보니 //변경사항 발생이라는 "메인 소스 변경" 이라는 커밋내역으로 올라간 내용이

 

원격지에서 초기화 됨을 알 수 있습니다.

 

 

 

 

깃 사용법(소스 내려받기)

 

 

깃의 소스를 내려받는 법은 간단합니다.

 

pull을 통해 한번에 내려받을 수 있고

 

[fetch] -> [checkout] 또는 [merge]를 통해 원격지의 소스를 내려 받을 수 있습니다. 

 

pull은 원격지의 소스를 한번에 로컬까지 내려받아 로컬소스와 원격지 소스를 한번에 싱크 맞출 수 있습니다.

 

 

 

 

fetch를 하면

 

 

 

아래와 같이 원격지의 커밋내역들이 로컬에 최신화가 됩니다. 

 

 

 

 

원하는 커밋을 선택하여 merge 또는 checkout 하면 로컬 소스와 싱크가 맞춰집니다.

 

 

 

브랜치 생성 및 원격지 머지

 

이번에는 브랜치를 생성하여 마스터와 새로 생성한 브랜치를 머지하는 과정을 해보겠습니다. 

 

아래와 같은 절차로 브랜치를 생성해주세요.

 

 

 

 

 

 

 

 

 

지금 우리 프로젝트는 관리자 브랜치인 master 브랜치와 새로 생성한 브랜치인 develop 브랜치가 있습니다. 

 

develop 브랜치에서 소스를 수정하여 master에 머지 해보겠습니다. 

 

 

 

위와 같이 //develop 브랜치 소스 수정 이라는 주석을 추가하고 원격지에 push하겠습니다.

 

 

 

이제 원격지에가서 본격적인 브랜치 머지를 진행하겠습니다. 

 

 

원격지 리포지터리에 들어가서 compare & pull request 버튼을 클릭해주세요.

 

이 버튼을 통해서 두 브랜치의 소스 내용을 머지하는 것입니다. 

 

 

 

 

 

이후의 버튼을 계속 클릭하여 절차를 마무리해주세요.

 

 

 

원격지의 커밋내역을 확인해보니

 

 

 

위와 같이 develop 브랜치의 커밋을 머지한 머지 커밋내역이 생성됨을 알 수 있습니다. 

 

 

 

로컬에서 다시한번 pull을 하여 히스토리를 확인해보니

 

 

 

위와 같이 분리된 브랜치가 합쳐진것을 확인 할 수 있습니다.

 

 

 

이렇게 해서 깃의 중요한 명령어들을 모두 살펴보았습니다. 

 

형상관리는 여러명의 개발자가 같이 진행하는 프로젝트에서 굉장히 중요한 부분이고 

 

자신이 개발한 소스를 관리하기 위해서도 굉장히 중요한 부분입니다. 

 

위의 명령어들이 형상관리 하는데 큰 도움이 될거 같습니다.

 

 

++참고++

이미 머지된 브랜치를 머지 취소할 수 도 있습니다.

 

위에서 언급한 Revert요청을 다시 날리는 경우에도 가능하고, 

 

관리자가 pull Request에서 해당 커밋을 찾아 직접 Revert할 수도 있습니다.