[Day 29] Git(2) + Software Engineering

Git (2)

Git Flow

• git flow init : 깃의 다양한 브랜치들을 이용해 효율적으로 협업하기 위한 도구인 git flow를 적용해서 git을 시작한다.

Git Flow Collaboration

1. 개발자들은 PM이 만든 Git Flow가 적용된 원본 Github repo를 fork한 뒤 clone 한다.

2. 하지만 fork한 repo는 Git Flow가 허용되어 있지 않다.

   • git flow init 을 다시 해줘야 한다.
   • git flow init 하면 develop 브랜치가 자동으로 생기면서 이동한다.

3. develop 브랜치에서 기능 개발을 위해 feature 브랜치를 따서 작업한다.

   • git flow feature start 기능이름
   • 자동으로 브랜치가 생기면서 이동한다.
   • 작업을 수행한다.
   • 작업이 완료되면 feature/기능이름 브랜치 위에서 add, commit, push 한다.
   • feature 개발을 완료해서 더이상 브랜치를 쓸일이 없다면
     • git flow feature finish 기능이름
     • 자동으로 develop 브랜치로 merge된다. (feature/기능이름 브랜치는 local 에서 자동으로 삭제된다.)
     • [push해서 feature finish한 기록을 남긴다.]

4. 하나의 파일에 여러명이 붙어서 작업할 경우의 conflict를 회피하는 방법

   • 원본 remote repo의 주소를 복사해서 git remote add pmorigin repo주소 를 입력해서 원본 repo의 remote를 추가로 등록해놓는다.
   • git pull pmorigin develop 으로 땡기면 conflict가 발생한다.
   • conflict 발생한 파일을 수정하면 git status 에서 both modified 라고 뜬다.
   • add, commit 한 뒤 fork한 개발자의 repo에 push 한다.
   • 개발자가 PM에게 conflict solve 한 내용을 pull request를 보낸다.
   • PM이 pull request를 merge 하면 끝.

5. 순서

   • PM

     • git init -> git flow init
     • some change -> push develop

   • Dev team

     • form PM’s repo -> clone
     • git flow init
     • git flow feature start <feat-name>
     • some change -> add, commit, push feature/<feat-name>

     • git flow feature finish <feat-name>

     • git remote add pmorigin <PM's repo address>

     • git pull pmorigin develop

     • git push origin develop —> create Pull Request (dev to dev)

6. release 브랜치 (주로 PM이 관리한다.)

   • release 브랜치는 배포와 버전에 관련된 브랜치이다.
   • release 브랜치를 딸 때는 git flow release start <version-number>
   • release 브랜치를 종료하고 git flow release finish <version-number> 를 하면 자동으로 master 브랜치로 옮겨간다.
   • release 브랜치가 종료되고나면 master 브랜치와 develop 브랜치의 내용이 같아지고, 버전이 하나 올라간다.

Software Engineering

• 웹의 최근 흐름
  • PWA(Progressive Web Aplication) : 웹을 앱 처럼 사용한다.
  • 웹이 앱을, 앱이 웹을 따라가려는 경향이 있다.
  • 웹페이지에서 서비스 워크를 이용해 애플리케이션 알림처럼 보내주는 기능도 가능하다.
  • 웹에서 하드웨어(스마트폰 등)의 센서에 접근이 가능해진다.
• DevOps
  • Development Team + Operation Team
  • 운영과 개발을 통합하여 커뮤니케이션 리소스를 줄이고, 개발 실패 확률을 줄임과 동시에 보다 안정적인 서비스를 운영할 수 있다.

개발 생명 주기 (Software Development Life Cycle)

1. 요구사항 분석
   • 요구사항(Requirement)
     • 무엇이 구현되어야 하는가에 대한 명세
     • 시스템이 어떻게 동작해야 하는지 혹은 시스템의 특징이나 속성에 대한 설명
   • 요구사항 분석(Requirements Analysis)
     • 시스템 공학과 소프트웨어 공학 분야에서 수혜자 또는 사용자와 같은 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 것과 같은 업무
     • 비즈니스 요구사항 -> 사용자 요구사항 -> 시스템 및 기능 요구사항
     • use case diagram
   • 명세는 너무 지나치게 상세하게 작성하지 말자!! 독이 될수도 있다… ㅠ