개발자, 일상의 흔적

1. 왜 GIT을 써야하는가

2. GIT의 구조 및 명령어

3. GIT 사용의 예시

4. GIT 실습

3. GIT 사용의 예시

GIT을 어떻게 쓸까?

우리는 형상관리를 위해 많은 개발자들이 하나의 저장소를 사용한다. 많은 개발자가 있으니 이를 효과적으로 사용하기 위한 방법에 대한 약속을 정한다. 약속은 대부분 브랜치를 사용하는(따는) 방법이며, 이를 GIT의 브랜치 전략이라고 한다.

우리는 브랜치를 어떻게 약속하여 사용하는지에 대해 배울것이고, GIT Flow와 GIT hub Flow 전략을 설명할 것이다.

GIT Flow 전략

Master : 라이브 서버에 제품으로 출시되는 브랜치로, 배포 가능한 상태의 버전만을 관리한다.

Develop : 다음 출시 버전을 대비하여 개발하기 위한 주요 브랜치다.

Feature : 기능을 완성 할 때까지 유지되는 브랜치로, 보통 개발자 저장소에만 있고 원격 저장소에는 push하지 않는다.

               Develop 브랜치에서 가져와서 Develop 브랜치로 merge한다.

Release : 다음 버전을 출시하기 위한 브랜치로 Develop브랜치에서 가져와서 Q/A, 테스트 진행 후 문제가 없으면 Master브랜치와 Develop브랜치로 merge한다.

Hotfix : Mater브랜치에서 오류가 발생하면 Mater브랜치에서 가져와서 급하게 수정하여 Master브랜치와 Develop브랜치로 merge 한다.

※ Mater브랜치와 Develop 브랜치는 항상 유지하는 기본으로 두고 나머지 브랜치를 보조브랜치로 사용한다. 

상황에 따른 브랜치 전략 예시

※ 신규 기능 개발 시 브랜치 전략(Feature 브랜치)

① Develop 브랜치로부터 신규 개발할 기능을 위해 Feature 브랜치를 생성한다.

② Featrue 브랜치에서 기능을 완성 하면 Develop 브랜치로 merge한다.

※ 라이브 서버로 배포하는 브랜치 전략(Release 브랜치)

① Feature 브랜치가 Develop 브랜치로 모두 merge 되었다면, QA와 테스트를 위해 Release 브랜치를 생성한다.

② Release 브랜치를 통해 오류가 확인이 되면 Release 브랜치 내에서 수정을 한다.

③ QA와 테스트가 모두 통과 되면 배포를 위해 Master 브랜치로 merge 한다.

④ 만일 Release 브랜치에서 오류 수정을 했을 경우 동기화를 위해 Develop 브랜치에도 merge 한다.

GIT hub Flow 전략 

※ 브랜치 생성 

- 기능 개발, 버그 수정 등 어떤 이유에서든 새로운 브랜치를 생성하되 브랜치 명으로 의도를 명확히 표현해야 한다.

- 새로운 브랜치는 항상 Master 브랜치에서 생성하고 Master 브랜치로 merge 한다.

- Master 브랜치는 항상 최신상태이다.

※ 개발 / 커밋 / 푸쉬

- 개발을 진행하며 최대한 상세히 커밋 메세지를 작성하고 수시로 push를 진행한다.

※ PR (Pull Request) 생성

- 피드백이나 도움이 필요할때나 merge 준비가 완료 되었을때 PR을 생성하여 pull해달라고 요청한다.

피드백이나 도움이 필요할때 : pull받아서 피드백 좀 해주세요

merge 준비가 완료되었을때 : 최종 merge 하게 pull 받아서 확인 후 push 해주세요.

1. 왜 GIT을 써야하는가

2. GIT의 구조 및 명령어

3. GIT 사용의 예시

4. GIT 실습

2. GIT의 구조 및 명령어

GIT은 앞서 말한것 처럼 여러 단계에 거쳐 다른 개발자들과 공유한다고 했다.

각 단계별 영역과 상태 등의 구조를 익혀두고 실습을 해보고 다시 이 구조를 본다면 훨씬 이해하기 쉬울것이다.

GIT 구조

위의 구조는 영역과 상태, 명령어로 되어있는 모식도이다. 하나하나 설명해보겠다.

① Untracked : git에서 추적하고 있지 않은 새로운 파일이 생성된 상태이다.

② Tracked : git에서 추적하고 있는 기존에 파일의 상태이며 하위로 2가지 상태를 가진다.

③ Unmodified : git에서 추적하고 있는 기존에 파일을 수정하지 않은 상태이다.

④ Modified : git에서 추적하고 있는 기존에 파일을 수정한 상태이다.

⑤ Staged : 버전을 만들 Stage Area에 파일이 있는 상태이다.

⑥ Version : 버전을 만든 후 .git Directory에 파일이 있는 상태이나, 버전이 만들어진 후 파일은 Tracked > Unmodified 상태로 바뀐다.

명령어

git add : 신규 생성된 파일이나, 기존에 git에서 관리하던 파일 중 수정한 파일을 Stage Area에 올릴 경우 사용하는 명령어이다. (Untracked 상태 → Staged 상태 , Modified 상태 → Staged 상태로 바꿈)

git commit : 버전을 관리할 Stage Area에 모인 파일들을 버저닝하는 명령어 이다. (Staged 상태 → Unmodified 상태로 바꿈)

git push : 버저닝한 파일들을 원격 저장소에 업로드하는 명령어이다.

git pull : 버저닝한 파일들을 원격저장소에서 다운로드 하는 명령어이다. 이렇게 다운로드 된 파일은 Tracked > Unmodified 상태로 다운로드 된다.

1. 왜 GIT을 써야하는가

2. GIT의 구조 및 명령어

3. GIT 사용의 예시

4. GIT 실습

1. 왜 GIT을 써야하는가

세상에 거의 모든 현업 개발자들은 혼자 개발하지 않으며, 소스들은 개발자들의 손을 통해 지속적으로 바뀐다.

이러한 특성으로 인해 소스코드들을 체계적으로 관리해주는 것 필요했고 이러한 일을 형상관리라고 한다.

우리도 일상적으로 형상관리를 해본일이 있다.

발표자료를 팀원들에게 공유 하는 상황을 그려본다.

최종.pptx

진짜 최종.pptx (아이콘 수정)

진짜 진짜 최종.pptx (진짜 최종.pptx + 피드백 자료 합치기)

진짜 이게 찐 최종.pptx (오타 발견)

이런 파일 공유 많이 해봤을 거라 생각한다. 상황은 다음과 같다.

최종.pptx를 받은 팀원이 최종_피드백.pptx로 피드백을 했다.

아이콘 이미지를 바꾸기 위해 난 이미 진짜 최종.pptx를 저장해서 공유하려고 했다.

피드백을 받았으니 둘을 합쳐 진짜 이게 최종.pptx가 만들어진다.

근데 또 오타를 찾았다......

진짜 이게 찐 최종.pptx가 만들어진다.

위와 같은 상황을 잘 관리할 수 있게 도와주는 툴(프로그램)을 우린 형상관리 툴(프로그램)이라고 한다.

형상관리 툴은 다른 개발자와 같은 파일을 수정하거나 개발했던 것을 원복해야할 때 등 좋지 못한 상황이 발생했을 때도 큰 힘을 발휘한다.

이 형상관리 툴은 SVN과 GIT이 대표적이다. 다만, GIT은 혁신이라고 불리우는 대신 지옥에서 왔다는 별명을 가지고 있다.

둘의 특징은 다음과 같다.

SVN은 직관적이기 때문에 사용하기가 편하다.

SVN서버에 저장소를 만들고 거기에 모든 개발자들이 연결하여

중앙 집권식으로 소스를 업로드(commit), 다운로드(update)하게 된다.

이 말은 SVN서버와의 연결이 끊어지면, 업로드 다운로드가 안 될뿐아니라

소스를 수정했던 이력들을 볼수 없고, 서버가 수명을 다 한다면 수정 이력들을 날려버리게 된다.

내 로컬 PC에 소스는 남아있으니 SVN서버를 다시 파서 개발자들에게 이쪽으로 붙으라고 하면 되지만,

여기서 GIT이 좋은 이유를 찾을 수 있다.

GIT은 여러 단계를 거쳐 다른 개발자들과 소스를 공유하게 되는데,

단계가 많다보니 단계별로 발생 할 수 있는 경우의 수가 많다.

그럼에도 불구하고 GIT이 가진 장점으로 위와 같은 상황에서 힘을 발휘한다. 

GIT은 개발자들마다 독립적으로 저장소를 가지고 있고 관리가 가능하기 때문에

GIT 서버가 어떻게 되든 히스토리를 똑같이 복구 할수 있다.

심지어 GIT의 서버는 github.com 사이트에서 서버로 활용할 수 있어, 서버 구매 비용도 없고 서버가 잘못될 가능성도 현저히 적다.

히스토리가 왜 중요할까?

다음으로 GIT은 개발자 자신만의 버전관리를 할 수 있다.

버전 관리라고 함은 어떠한 기능을 만들때 썼던 여러가지 소스들을 유의미한 단위로

묶어서 관리한다는 이야기이다.

만약, 로그인 기능을 만든다고 하면 로그인 기능을 업데이트한 버전을 묶어서 저장소에 저장을 한다.

이렇게 관리된 버전들은 명령어 하나로 아주 쉽게 이전 상태의 버전들로 돌아갈 수 있다.

세번째 GIT은 Branch와 merge 기능을 사용하기에 좋다.

갑자기 처음 보는 용어가 나와서 당황 했을 것이다. 한국말로 브랜치와 머지라고 하는데

위의 최종.pptx사태로 돌아가 보자. 

(개념적으로만 이해하고 넘어가자. 실습으로 이해하는게 더 빠르다.)

상황

최종.pptx를 팀원에게 공유하고 혹시 피드백이 올지 몰라

최종.pptx를 기반으로 따로 진짜 최종.pptx 파일로 작업한다.

아니나 다를까 최종_피드백.pptx가 피드백이 왔고

진짜 최종.pptx와 최종_피드백.pptx를 합쳐 진짜 진짜 최종.pptx를 만들었다.

해석

2번째 줄인 최종.pptx를 기반으로 따로 진짜 최종.pptx 파일로 작업한다.

는 말을 최종.pptx에 브랜치따서 작업 한다고 얘기한다.

4번째 줄에 최종_피드백.pptx와 진짜 최종.pptx를  합쳐 진짜 진짜 최종.pptx를 만들었다.는 얘기는

브랜치로 딴 진짜 최종.pptx와 원본 파일의 수정본인 최종_피드백.pptx를 머지 한다고 한다.

최종 정리

SVN

- 직관적이고 사용하기 편하다.

- 중앙 집권식으로 소스들을 다운로드 업로드 한다.

- 서버가 죽으면 히스토리를 살릴 수 없다.

GIT

- 독립적인 저장소를 관리한다.

- 버전 관리를 개발자가 직접 할 수 있으며, 버전별 소스 상태 변경이 용이하다 

- branch와 merge 기능을 사용하기 좋다.