[들어가기 앞서]
훗날 면접을 볼 때 git에 대한 질문을 받으면 어떻게 대답하지? 라는 생각을 하다가 git과 Github에 대한 정의나 자주 사용하는 용어들을 정리해 놓으면 도움이 되겠다는 생각에 이 글을 쓰게 되었다.
[1. git이란?]
git이란 분산 버전 관리 시스템(DVCS)으로, 코드관리 및 버전관리를 해주는 무료 공개 소프트웨어이며, 브랜치, 머지 등 다양한 기능을 통해 여러명이 하나의 프로젝트를 진행할 때 변경된 사항을 효율적으로 병합할 수 있도록 도와준다.
#버전관리 #백업 #협업
<형상 관리는 왜 해야할까?>
형상 관리란 소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것으로, 형산 관리는 일반적인 단순 버전관리 기반의 소프트웨어 운용을 좀 더 포괄적인 학술 분야의 형태로 넓히는 근간을 이야기한다.
일반적으로 형상 항목(Configuration Item)이라는 형태로 작업 산출물을 선정하고, 형상 항목 간의 변경 사항 추적과 통제 정책을 수립하고 관리한다.
그럼 이제 형상 관리가 무엇인지 알았으니 형상 관리가 왜 필요한지 다음 상황을 통해 살펴보자.
아래 그림은 'X' 라는 프로젝트를 개발자 A,B,C,D가 파트를 나눠 협업하여 진행하고 있는 상황이다.
해당 상황에서는 다음과 같은 문제가 발생할 수 있다.
A가 맡은 기능을 다 구현했는데, B가 맡은 기능을 아직 구현 못해서Code1을 완성할 수 없어 Code2의 개발을 할 수 없는 상황.- A, B가 각자 맡은 기능을 구현하고 Code1로
합쳤는데, 충돌이 발생하여 에러가 발생하는 상황.- Code1이 완성되어 C가 Code2를 개발하고 있는데, 갑자기 심각한 에러가 발생하여,
Code1의 상태로 돌아가야되는데, 백업해 둔 사람이 아무도 없는 상황.- Code2까지 전부 완성해서 D가 Code3를 개발하고 있는 도중 호환성 문제 때문에 Code1 부분에서 수정이 필요한 상황인데,
어느 부분에서 수정을 해야 하는 지 알 수 없는 상황.
위 상황 하나하나가 발생한다면 상당히 어지러운 상황이다... 이러한 상황을 방지하기 위해 형상 관리를 하는 것이다.
[2. GitHub란?]
Github는 git을 기반으로 소스코드와 관련 파일을 저장하고 관리할 수 있는 웹 기반 호스팅 서비스이다. 간단하게 개발자들이 협업을 위해 소스 코드를 공유할 수 있도록 도와주는 플랫폼이라고 생각하면된다.
*Github는 개발자들 사이에서 가장 인기 있는 형상관리 플랫폼이다.
[3. git에서 자주쓰는 용어 및 명령어 정리]
해당 장에서는 자주쓰는 용어와 명령어의 개념과 사용방법에 대해 설명한다.
<로컬 저장소(local repository)>
내 PC에서 직접 관리하는 저장소이다.
로컬 git저장소를 만드려는 디렉토리로 이동해서 아래 명령어를 실행하면 .git 폴더가 생성된다.
$ git init
.git 폴더에는 커밋, 스테이지 등 저장소에 필요한 파일들이 저장되어 있다.
<원격 저장소(remote repository)>
여러 사람이 함께 공유 할 수 있는 원격 서버에 저장된 저장소이다.
clone 명령어를 사용하면 기존 원격 저장소를 로컬에 받을 수 있다.
$ git clone https://(github repository directory)
<Branch>
변경 사항을 분리하여 관리할 수 있도록 한다. 각각의 Branch는 독립적인 작업 공간을 가지며, 변경 사항을 추적하고 병합할 수 있다.
<작업 폴더(Working Directory)>
말 그대로 작업하고 있는 폴더의 디렉토리
<Staging Area>
작업 폴더에서 작업한 내용을 기록($ git add) 하는 곳. stage에서 commit을 하게 되면 Github의 디렉토리에 저장된다.
<status>
파일의 상태를 확인하는 명령어
커밋된 파일 & 스테이지에 있는 파일 : tracked(git이 해당 파일을 추적 및 관리하는 상태)
그 외 : untracked(git이 해당 파일을 추적 및 관리하지 않는 상태)
$ git status
<add>
작업 폴더에서 작업한 내용을 stage에 기록할 때 사용하는 명령어
$ git add 파일명<- 해당 파일명의 파일 add
$ git add .<- 해당 경로의 모든 파일 add
<commit>
현재 stage에 있는 파일을 github directory에 저장
당연히 untracked 파일은 커밋되지 않는다.
$ git commit -m "커밋 메시지"
<커밋 메시지의 규칙>
커밋 메시지는 개발자들 사이에서 알아보기 쉽게 통용되는 규칙이 존재한다!1. 제목과 본문을 빈 행으로 구분한다.
2. 제목은 50글자 이내로 제한한다.
3. 제목의 첫 글자는 대문자로 작성한다.
4. 제목의 끝에는 마침표를 넣지 않는다.
5. 제목은 명령문으로 사용하며 과거형을 사용하지 않는다.
6. 본문의 각 행은 72글자 내로 제한한다.
7. 어떻게 보다는 무엇과 왜를 설명한다.이렇게 총 7가지이다. 그럼 이제 커밋 메시지의 구조에 대해 알아보자
타입 : 제목 (Header) 본문 (Body) 바닥글 (Footer)*Header은 필수지만 타입은 생략 가능하다.
타입은 해당 커밋의 성격이 드러나야하며, 아래 중 하나여야 한다.
타입 내용 feat 새로운 기능에 대한 커밋 fix 버그 수정에 대한 커밋 build 빌드 관련 파일 수정 / 모듈 설치 또는 삭제에 대한 커밋 chore 그 외 자잘한 수정에 대한 커밋 ci ci 관련 설정 수정에 대한 커밋 docs 문서 수정에 대한 커밋 style 코드 스타일 혹은 포맷 등에 관한 커밋 refactor 코드 리팩토링에 대한 커밋 test 테스트 코드 수정에 대한 커밋 perf 성능 개선에 대한 커밋 *Body는 Header에서 표현할 수 없는 상세한 내용을 적는다. (생략가능)
*Footer는 바닥글로 어떤 이슈에서 왔는지 참조 정보들을 추가하는 용도로 사용한다. (생략가능)<예시>
$ git commit -m "fix : 리스폰이 제대로 작동하지 않는 이슈 수정 플레이어가 리스폰 버튼을 눌렀을 때 리스폰 위치가 이상했던 현상 수정 Close : #123456"
<push>
commit한 파일을 원격 저장소에 올리는 명령어
$ git push (원격 저장소 이름) (Branch 이름)
<fetch>
로컬에는 없지만 원격 저장소에 올라가 있는 데이터를 모두 가져옴
$ git fetch (원격 저장소 이름)
<merge>
현재 작업 중인 Branch에 합칠 커밋을 지정해서 병합
$ git merge (병합할 Branch 이름)
<checkout>
다른 브랜치로 전환
예를 들어 mybranch라는 branch에서 작업을 하다가 yourbranch라는 branch로 전환을 하려면 아래와 같이 명령어를 작성하면 된다.
$ git checkout yourbranch
<pull>
원격 저장소의 데이터를 가져오고, 자동으로 현재 작업하는 로컬 브랜치와 merge
쉽게 생각하면 fetch와 merge의 기능이 합쳐진 명령어이다.
** *push 하기 전에 pull을 하지 않으면 이미 원격저장소에 변경사항이 일어났을 때(원격저장소와 로컬저장소의 차이가 있을 때) push에 실패한다. 따라서 수시로 pull해주는 것이 충돌 예방에 좋다.
$ git pull (원격 저장소 이름) (Branch 이름)
