[Github] 기초 명령어 및 사용 방법 3편

1편, 2편

1편

 

 

2편

앞선 내용을 보고 오시는 것을 추천합니다.

 

전에 제가 보고 바로 이해했던 영상을 들고왔습니다.

 

재미도 있으니 한번 보는 것을 추천드립니다.

 

 

윗 영상 결론.

단순하게 그리는건 Obsidian 이 좋긴한데...

 

오늘의 목표 : gitFlow 에 대해서 이해해보자.

우리는 "왜 브랜치를 나누는가?"부터 생각을 해봐야한다.

 

한 프로젝트를 혼자서 진행을 한다면 브랜치가 이렇게 많지 않아도 문제가 없을 것이다.

하지만 우리가 회사에 들어가서 일을 한다면 친구들이 있는 곳은 최소가 5명이라고 했다.

그러면 프로젝트 하나를 혹은 한 부위를 한 팀이 담당을 하고 진행을 하는 것인데, 이것에 대한 관리가 필요하게 되어서

 

우리는 이것을 간단하게 "형상관리가 필요해서" 라고 말한다.

 

 

형상 관리란?

구성 관리 - 위키백과, 우리 모두의 백과사전

위키피디아에서는 "형상 관리는 소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것" 이라고 한다.

 

우리가 많은 사람들이 하나의 프로젝트를 잡고 하게 된다면 ( ex : 오픈소스 ) 언제 누가 수정을 했는지에 대한 관리가 필요할 것이다. 그래서 형상관리를 하기 위한 툴이 github라고 할 수 있겠다.

 

 

브렌치 전략은 어떤 것이 있는가?

• Git Flow
• Gitlab Flow
• Github Flow
• 등...

그 중에서 오늘은 위 영상에서 소개 된 방식인 Git Flow 방식을 소개하고자 한다.

 

 

1. Main 브랜치와 Develop 브랜치

Main 브랜치와 Develop 브랜치를 나누는 이유

Main 브랜치는 서비스를 사용하는 사용자에게 바로 적용이 되는

브랜치이기 때문이다.

 

 

그렇기 때문에 개발용 브랜치를 따로 두는 것이다.

 

모든 기능을 개발하고 한 곳으로 모와 테스트를 하기 위한

브랜치를 만드는데 그것이 Develop 브랜치이다.

 

 

 

 

 

2. Feature 브랜치 ( 기능 브랜치 )

Feature 브랜치로 새분화하는 이유

Feature 브랜치 Develop에서 여러가지고 나눠서

한명마다 한 기능을 잡고 개발을 진행을 하게 된다.

 

그렇기 때문에 Feature 브랜치는 많아지게 된다.

 

그렇기 때문에 합칠 때 문제가 생기는 위치이기도 한다.

 

 

 

 

 

 

 

3. release 브랜치

 

release 브랜치

 

 

이제 인원들이 개발을 진행한

기능 브랜치를 Develop 브랜치에서 테스트를

진행을 해보고 문제가 발견이 되지 않으면

 

 

 

진짜 문제가 없는지 안전을 위해서

release 브랜치로 진행을 하게 된다.

 

 

 

블로그 주인장은 프로젝트를 진행을 할 때

release을 사용을 하지 않고 진행을 하였다.

 

 

 

 

 

 

 

 

 

3-1. release 브랜치

release 브랜치에서도 문제가 없었다면

그러면 이제 진짜로 사용자에게 서비스가 제공이 되는

 

Main 브랜치로 이동을 하게 되고

release 브랜치도 문제가 없다는 것을 확인했으니

 

Develop 브랜치에도 적용을 하게 된다.

 

 

 

 

 

 

 

4. HotFix 브랜치

 

서버에 긴급 버그가 발생했다!!!

긴급한 경우에 사용하는 브랜치로

HotFix 브랜치를 사용을 하게 된다.

 

사용자에게 직접적으로 서비스가 되는

Main 브랜치에서 바로 새로운 브랜치를 만들어서

 

버그를 수정을 하고 Main 과 Develop 브랜치에

바로 적용을 하게 된다.

 

 

 

 

5. 최종

Git Flow 전략

 

우리가 프로젝트를 하면서 여러 사람의 손을 거쳐가는 경우가 많은데 형상관리가 잘 되어있다면

문제가 되는 부분을 빠르게 바로 잡을 수 있을 것이다.

 

결론적으로 이런 전략이 사용되는 것은 개발자의 편의성도 있겠지만

어떠한 일이 일어나든 빠르게 대처를 하는 모습을 보면 사용자들도 "문제가 생겨도 빠르게 대처를 할 수 있는 서비스

라고 생각을 하게 되지 않을까" 라는 생각이다.

 

그리고 블로그 주인장도 해당 전략으로 메인 소스코드를 한번 보호를 했던 경험이 있어서 나름 알기 쉽고 대비하기 좋은

Git Flow을 예시로 든 것도 있다.

 

 

 

0. 외전 : 부모브랜치와 merge할 때 생기는 문제 빠르게 찾는 법

블로그 주인장은 너무 늦게 알았다...

 

Feature 에서 기능을 만들고 있다가 Develop 으로 브랜치를 올리는 경우

문제가 생기는 경우가 많다.

 

여러가짓수가 있겠지만 변수 이름, 클래스이름, 파일이름, 등 이 곂치거나, 이미 사용된 파일의 위치라던가 이러한 이유로 생기는 문제가 생길 것이다.

 

빠르게 문제를 찾는 법은 아주 단순하다.

우리가 프로젝트를 업데이트를 하기 위해서 git pull을 하듯이 이미 앞에있는 프로젝트를 업데이트를 받아보는 것이다.

 

일단 Develop에 업데이트 된 내용을 내 브랜치로 옮기고 버그를 전부 수정을 한 다음에,

오류를 수정을 해서 Develop 브랜치에 수정한 내용을 올리면 된다.

 

 

느낀점.

잠을 못자서 그런지 아직까지는 아침에 너무 힘들다...

근대 하나하나 뭔가 채워나가는 느낌이 좋다...

블로그도 이렇게 꾸준히 해보자...