y-log

Git이란?

git은 컴퓨터 파일의 변경 사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 오픈소스 분산 버전 관리 시스템이다.

주로 소프트웨어를 개발하며 코드 관리에도 사용되지만 어떠한 프로젝트의 변경사항을 지속적으로 추적하기 위해 사용될 수 있다. (나는 보통 소스코드 관리와 변경사항 추적을 목적으로 사용하고 있다)

Git-flow란?

Git-flow는 Git이 활성화가 될 2010년 정도에 Vincent Driessen이라는 사람이 만든 Git을 사용한 개발 작업 절차이다. Git-flow라고 해서 프로그램 같지만 프로그램이 아닌 약속, 규칙같은 개념이다.

Vincent Driessen또한 Git-flow는 완벽한 방법론이 아닌, 각자 팀에 맞는 개발 환경에 따라 변형해서 사용하는 것이 좋다고 언급했다.

Git-flow의 브랜치

Git-flow의 브랜치는 다음과 같이 구성되어 있다.

• master 와 devleop브랜치
  • master와 develop브랜치가 존재하고, develop브랜치는 master 브랜치에서 시작된 브랜치.
  Develop브랜치
  • develop브랜치에는 상시로 버그를 수정한 커밋들이  추가되게 된다.
  • 새로운 기능을 추가하는  경우  develope 브랜치에서 시작하는 feature브랜치를 생성
  Feature브랜치
  • 이 feature브랜치는 기능 추가 작업이 완료되었다면, develop 브랜치로 merge 
  • 새로운 기능을 추가하는  경우  develope 브랜치에서 시작하는 feature브랜치를 생성
  release 브랜치
  • develop브랜치에 이번 버전에 포함하는 모든 기능이 merge되었다면 , QA를 위해 develop브랜치에서 release브랜치를 생성
  •  QA를 무사히 통과하게되면 relase브랜치를 master와 develop브랜치로  merge
  • QA를  진행하면서 발생한 버그들은 모두 release브랜치에 수정

master와 develop은 항상 유지되는 메인 브랜치들이며 그 외에 feature, release, hotfixes는 필요한 기간에만 유지되는 보조 브랜치들이다.

다음은 Vincent Driessen의 블로그에서 Git-flow를 설명할때 사용하는 이미지이다.

타임라인을 보면 알겠지만 처음에는 master로 시작해 develop브랜치만 존재한다.

아직 소프트웨어를 배포하지 않았기 때문에 develop브랜치에서 개발을 시작한다.

개발을 진행하다가 추가로 필요한 기능이 생기면 feature브랜치를 생성해 작업을 한다. 

feature브랜치는 언제나 develop브랜치로부터 시작된다.

기능을 다 개발했다면 작업한 feature브랜치를 검토한 후 develop브랜치에 병합한다.

이제 이번 버전에서 필요한 기능이 모두 개발되었다면 QA를 위해 release브랜치를 생성한다.

QA를 진행하며 발견하는 버그들은 모두 이 release브랜치를 통해 fix된다.

이제 QA과정이 모두 끝났다면 release브랜치를 master와 develop브랜치로 병합한다.

그리고 master브랜치에 버전명시를 위한 태그를 생성 후 배포한다.

여기까지가 기본적인 개발 단계에서의 Git-flow이다.

하지만 배포 후에도 버그가 발생하는 경우가 있다.

그렇다면 긴급하게 수정을 해야하는데 그럴 경우 hofixes브랜치를 생성해 발생한 버그를 수정한다.

버그 수정이 완료되었다면 release브랜치가 완료됬을 때와 같이 master와 develop브랜치로 병합 후 버그 수정을 완료했다는 태그를 추가한다.

버전 태그

보통 소프트웨어를 표시할때 버전은 x.x.x의 형태로 이루어진다. 이 숫자들은 무엇을 의미할까? 버전의 가장 첫 번째 숫자는 Major Version을 의미한다. Major Version은 보통 1로 시작해서 소프트웨어 전체적으로 큰 변화가 생겼을때 버전 업을 한다. 두 번째 숫자는 Minor Version을 의미한다. Miner Version은 보통 0으로 시작해서 없던 기능의 추가나 기존 기능의 수정 등의 변화가 발생했을 때 버전 업을 한다. 마지막 세 번째 자리는 Build or Maintenance Version이라고 하며 자잘한 버그나 내부적 코드 보안 등의 변화가 발생했을 때 버전 업을 한다. 이 버전은 0으로 시작하지만 생략하는 경우도 있다.

Reference.

link1 link2

MVC

Model
View
Controller

개발할 때 3가지 형태로 역할을 나누어 개발하는 방법론을 MVC 패턴이라 한다.

모델 Model

어플리케이션의 정보, 데이터를 나타낸다. 

어플리케이션이 무엇을 할것인지를 정의하며 내부 비지니스 로직을 처리하기 위한 역할을 한다.

모델의 규칙
1. 사용자가 편잡하길 원하는 모든 데이터를 갖고 있어야 한다.
2. view나 controller에 대해서 어떤 정보도 알지 못한다.
3. 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야한다. 

뷰 View

화면에 무엇인가를 보여주기 위한 역할

input 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타낸다. 다시 말해 데이터 및 객체의 입력, 그리고 보여주는 출력을 담당한다. 데이터를 기반으로 사용자들이 볼 수 있는 화면이다.

뷰의 규칙
1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
2. 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.
3. 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.

컨트롤러 Controller

모델이 “어떻게” 처리할 지를 알려주는 역할을 하고, 모바일에서는 화면의 로직처리 부분이다.

화면에서 사용자의 요청을 받아서 처리되는 부분을 구현되게 되며, 요청 내용을 분석해서 Model과 View에 업데이트 요청을 하게 된다. (모델과 뷰의 중개 역할)

컨트롤러의 규칙
1. 모델이나 뷰에 대해서 알고 있어야 한다.
2. 모델이나 뷰의 변경을 모니터링 해야 한다.

MVC가 필요한 이유와 의의

사용자가 보는 페이지, 데이터처리, 그리고 이 2가지를 중간에서 제어하는 컨트롤, 이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은바에만 집중을 할 수 있게 된다.

공장에서도 하나의 역할들만 담당을 해서 처리를 해서 효율적이듯...

​

서로 분리되어 각자의 역할에 집중할 수 있게끔하여 개발을 하고 그렇게 애플리케이션을 만든다면, 유지보수성, 애플리케이션의 확장성, 그리고 유연성이 증가하고, 중복코딩이라는 문제점 또한 사라지게 된다. 

MVC패턴은 결국 "어떻게 나눌 것인가"에 대한 해답 중 하나다. 어떤 특정한 역할들에 대해 역할분담을 할 때 가이드라인을 제시하는 방법 중 하나가 바로 MVC패턴!!!!!

MVC패턴의 한계

MVC에서 View는 Controller에 연결되어 화면을 구성하는 단위요소이므로 다수의 View들을 가질 수 있다. 그리고 Model은 Controller를 통해서 View와 연결되어지지만, 이렇게 Controller를 통해서 하나의 View에 연결될 수 있는 Model도 여러개가 될 수 있다.

즉, 화면에 복잡한 화면과 데이터의 구성 필요한 구성이라면, Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 생길 수 있다 MVC가 너무 복잡하고 비대해져서, 새 기능을 추가할때마다 크고 작은 문제점을 가지고 소드 분석이나 테스트도 어렵다.... 이런 형태의 MVC를 Massive ViewController (대규모 MVC 어플리케이션) 라고 부른다. 

그래서 위의 문제점을 보완한 여러 다양한!! 패턴을 파생시켰습니다.

MVP, MVVM, Viper, Clean Architecture, Flux, Redux, RxMVVM….

Reference.

링크1 링크2