[Github] - github pull request & github action 을 이용한 자동화

1. git pull request

1) 개요

• Merge 를 하기 전에 사전 검토를 하는 과정 
• git hub 에서는 pull request 라고 하는데 다른 곳에서는 merge request 라고 함
• git 의 표준 명령이 아니고 호스팅 서비스에서 제공하는 기능으로 git 의 호스팅 서비스마다 서로 다른 명령어를 가짐

---

• 관리자용 계정에서 git hub repository 생성
  1. README.md 를 갖는 test-pr 이라는 repository 생성
  2. 브랜치 보호설정
  3. repository 선택하고 [Settings] - [Branches]를 선택한 후 [Add classic branch protection rule]을 선택
  4. Branch name patter 에 main 을 설정
  5. Require a pull request before merging 을 체크하게 되면 이제 main 브랜치로는 직접 push 할 수 없고 pull request 를 통한 병합을 사용하도록 설정
  6. Require approvals 은 pull request 후에 협업자들의 승인을 얻어야 병합을 할 수 있도록 설정
  7. Require review from Code Owners 는 pull request 후 저장소 관리자의 리뷰 승인이 필요하도록 설정
  8. 협업자 추가
  9. 관리자 컴퓨터에서 repository 클론
  10. 현재 로그 (git log --oneline) 와 브랜치 ( git branch) 확인
• 개발자 A : feat1  브랜치에서 파일을 추가 & 작성 & 커밋 & 푸시 
• github 페이지로 이동해 브랜치 생성 확인 -> Compare & Pull Request -> pull request 요청을 전송
• 타이틀과 내용을 작성하고 pull request를 생성

2) Remote Repository 생성

• 원격 레포지토리를 생성할 때 협업자가 직접 push 를 할 수 없도록 생성
• 생성 시 협업자가 직접 push 를 할 수없음
• 몇명의 개발자가 동의해야만 merge 를 할 지 설정 후 일반적으로 관리자만 merge 를 수행함
• 실습 
  1.  관리자 계정으로 repository 생성
  2. 협업자를 등록: Settings에서 Colaborators에서 Add People
  3. branch 보호 설정: Settings에서 Branches 에서  Add Class Branch Protection Rule을 클릭하고 필요한 옵션을 설정
  4. 개발자 계정에서 코드를 clone 하고 작업을 수행
  5. 내용을 수정
  6. 브랜치를 생성하고 커밋을 수행한 후 푸시
  7. git hub에 접속해서 pull request를 생성

3) 협업 대상이 명확하지 않은 경우

• 오픈 소스 프로젝트의 저장소나 개인이 저장소의 코드를 공개해서 불특정 다수로부터 개선의 도움을 받고자 하는 경우
• 협업자를 지정할 수 없음
• 원본 저장소를 Fork 해서 pull request 를 생성할 수 있음
• 실습
  1. 원본 프로젝트에서 협업자를 제거
  2. 해당 경우 clone 을 하지 않고 fork 를 수행
     1. fork 는 clone 고 유사한데 다른 계정의 git hub 저장소를 나의 git hub 저장소로 복제하는 기능
     2. fork 가 완료되면 새로운 계정에 저장소가 복제됨
  3. 파일을 추가하고 내용을 작성
  4. 새로운 브랜치를 만들어서 push
  5. 관리자가 아닌 경우는 pull request 를 생성해서 변경을 요청
  6. 관리자가 pull request 를 승인함

 

2. Gitflow

1) 개요

• 브랜치 운영 방식
• 여러 사람이 협업하는 큰 규모의 프로젝트나 지속해서 배포 계획을 세우고 진행하는 프로젝트에 유용하게 사용

2) Gitflow 의 branches

• 2개의 주 브랜치와 3개의 보조 브랜치를 이용
• 주 브랜치

• master
  • 과거에 배포된 코드 또는 앞으로 배포될 최종 단계의 코드가 관리되는 곳
  • 태그와 함께 버전 정보가 기록됨
  • 원격 저장소 (origin/master) 에서 관리
• develop
  • master 로부터 분기되어 나온 브랜치
  • master 와 release 브랜치와 병합
  • 다음에 배포할 프로그램의 코드를 관리
  • 배포할 프로그램의 기능이 준비되면 release 브랜치로 병합되어 검사
  • master 로 병합되어 배포 버전으로 태그를 부여받음
  • 원격 저장소 (origin/develop) 에서 관리
  • master 브랜치에서 git checkout -b develop 으로 생성

---

• feature
  • develop 브랜치에서 분기
  • develop 브랜치와 병합
  • 브랜치 이름은 feature/이름
  • topic branch 라고도 부르는데 다음 배포에 추가될 기능을 개발하는 브랜치
  • 기능이 완성되면 develop 으로 병합됨
  • 기능이 필요하지 않거나 만족스럽지 않은 경우 삭제 가능
  • 개발자의 로컬 저장소에 위치하고 원격 저장소에는 푸시하지 않음
  • develop 브랜치에서 git checkout -b feature/func1 형태로 생성
  • 작업 후 브랜치 병합을 할 때 --no--ff 옵션으로 병합
• release
  • develop 브랜치에서 분기
  • 병합은 develop 과 master 와 수행
  • 이름 규칙은 release/버전정보
  • 기능이 완서오딘 develop 브랜치의 코드를 병합해서 배포를 준비하는 브랜치
  • 배포에 필요한 준비, 품질 검사, 버그 수정을 진행
  • release 브랜치가 배포할 상태가 되면 master 로 병합
  • master 에 만들어진 커밋에 태그를 추가
  • 배포 후 release 브랜치가 필요없으면 삭제
  • develop 브랜치 상태에서 git chekout -b release/v0.1 형태로 생성

git merge --no-ff release/v0.1
git tag -a v0.1

• hotfix
  • master 에서 분기되어 나온 브랜치
  • develop 이나 master 와 병합
  • 브랜치 이름은 hotfix/버전정보
  • 기존 배포한 버전에 문제를 해결하기 위한 브랜치
  • 브랜치는 문제가 발생한 master 의 버전으로 생성
  • 문제를 해결한 후에는 master 와 develop 에 각각 병합을 진행
  • release 브랜치가 삭제되 않았다면 release 브랜치에도 병합을 진행함
  • 병합 후 브랜치는 삭제
  • master 브랜치에서 git checkout -b hotfix/v0.1.1

2) Gitflow 의 branches

• Gitflow 브랜치 관리를 편하게 할 수 있는 확장 프로그램
• https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

git-flow cheatsheet

• 작업

• 초기화 (미리 git init 을 할 필요가 없음) : git flow init
• 2개의 브랜치 (master, develop) 가 생성
• feature 나 release 브랜치 시작

git flow [브랜치 종류] start [브랜치 이름]
git flow feature start func1

• feature 나 release 브랜치 완료

git flow [브랜치 종류] finish [브랜치 이름]
git flow feature finish func1

 

3. gitignore

1) 개요

• 개발을 진행하다보면 프로그램 버전 관리와 관련이 적은 파일이 포함되는 경우가 있음
• 백업용 파일이나 로그 파일, 소스 코드 빌드나 컴파일 이후에 생성되는 파일들은 버전 관리와 연관성이 적음 
  -> 추적 대상에서 제외해도 무방
• 보안상 민감한 정보를 저장하고 있어서 공개적인 원격 저장소에 공유하기 곤라한 파일들 제외 필요
• 원격 저장소의 추적 대상에서 제외하고자 하는 파일이나 디렉터리를 등록하는 파일이 .gitignore

2) 실습

1. 하나의 디렉터리를 만들고 git init 을 수행
2. 파일을 생성
3. .gitignore 파일을 추가하고 작성 -> 확인
   1. 디렉터리를 설정하면 디렉터리 안의 모든 내용을 추적하지 않음
4. .gitignore 파일에 추가 -> 확인 (folder 안의 내용은 추적하지 않음)
5. 확장자 패턴 가능함 
6. .gitignore 파일 수정 -> 확인

3) 작성 규칙

• #: 주석
• [파일 이름] : 해당 파일 이름으된 저장소의 모든 파일 무시
• /[파일이름] : 현재 경로에 있는 파일만 무시
• *.[확장자] : 확장자를 가진 파일 무시
• [디렉토리이름]/ : 디렉토리의 모든 파일
• [디렉토리이름]/[파일이름] : 해당 경로의 파일 무시
• [디렉토리이름]/*.확장자 : 해당 경로의 확장자를 가진 파일 무시
• ![파일 이름] : 해당 파일 이름으로 된 것은 예외

4) 자동 생성

• https://toptal.com/developers/gitignore

gitignore.io

 

4. 기본 브랜치 변경

# 확인
git config --get init.defaultBranch
# 변경
git config --global init.defaultBranch main

 

5. github action

1) 개요

• 새로운 기능을 개발는 경우
  1. 개발 후 코드를 테스트
  2. 빌드 후 원격 저장소에 반영 후 배포
• github 를 원격 저장소로 사용하는 경우 github action 을 도구를 사용해 일련의 작업을 자동화 할 수 있음
• github action 은 소프트웨어 개발에 필요한 작업 주기를 자동화하는 도구
• action 은 이벤트 기반으로 특정 이벤트 발생 -> 특정명령 or 명령 집합을 자동으로 실행 가능

이벤트는 Pull Request, Push 와 같은 변경을 의미함 

1. 이벤트 발생
2. Jobs 호출
3. Jobs 안의 Steps 호출
4. Acㅅions 수행

• 동작 설정은 yaml 파일에서 생성함
  • 로컬에서 직접 설정 : .gitbunb/workflows
  • github 레포지토리에서 설정 : Actions 탭에서 선택해서 생성함

2) 작성예시

실행할 명령의 순서: 빌드 -> 테스트 -> 이미지 생성 -> 배포

#구분하기 위한 이름
name: 이름

#이벤트
on:
  push:
    branches: [브랜치 이름 나열]
  pull_request:
    branches: [브랜치 이름 나열]


#수행할 내용
jobs:
  build:
    runs-on: ubuntu-latest

    steps:
uses: actions/checkout@v2
name: 작업 이름
uses: actions/수행할내용 - 프로그래밍 언어 셋업
with:
	환경변수
run: 실행할 명령

3) node.js 로 만들 애플리케이션을 테스트하는 과정을 git action 으로 구현

1. github 사이트에서 레포지터리 생성
2. nodejs 프로젝트 생성
   1. 빈 디렉터리를 생성
   2. npm init 을 입력하고 옵션을 설정
3. 필요한 패키지 설치
4. node 플랫폼의 모든 프로젝트는 package.json 에 설정 -> 해당 파일 수정
5. app.js 파일을 추가하고 작성 -> 실행
6. github 에 push -> .gitignore 에 node_modules/ 추가
   1. node 관련 프로젝트는 node_modules 디렉터리가 외부 라이브러리를  있는 디렉터리
   2. 해당 디렉터리를 분산버전 관리시스템에 올릴 시 공간 낭비 -> 업로드 안됨
   3. 의존성 모듈은 package.json 파일에 모두 기록 -> npm install 이라는 명령을 수행시 설치 가능
7. 테스트 수행
   1. 테스트를 위한 라이브러리를 설치
   2. 테스트를 위한 파일을 생성하고 작성
   3. 테스트 수행
   4. test a여령을 package.json 에 등록함 : npm test 라는 명령어로 테스트를 수행
8. Github Action 작성 : main 브랜치가 push 될 때 테스를 수행
   1. 프로젝트에 .gitignore/workflow 디렉터리를 생성
   2. .github/workflows 디렉터리에 yaml 파일을 생성하고 작성 
9. 작성한 코드를 push 하고 github 페이지에서 action 을 확인

 

6. Github 을 정적 웹사이트 배포에 이용하기

1) 개요

• Github Repository 는 그 자체로 하나의 웹 서버 기능 수행 가능
• Github Repository 를 만듦 -> README.md 파일 작성 -> .git 을 제외한 부분은 URL 로 입력 -> README.md 파일 출력
• 하나의 계정에 하나의 정적 웹 사이트를 배포할 수 있도록 URL 도 제공

2) 정적 웹 사이트 만들기

1. 웹 사이트 생성 -> 실행 확인
2. 배포 준비
   1. react, vue, angular 프로젝트는 바로 배포가 안됨
   2. javascript 로 만든코드를 HTML 로 변환해서 출력하는 프레임워크들임
   3. 정적으로 변환해서 배포 진행
   4. build : 소스 코드 실행이 가능한 코드로 만듦 -> node  기반의 Frontend 프레임워크는 배포를 위해 필수적
   5. npm run build 명령 수행 -> build 디렉터리 생성 -> 정적 웹 파일 생성
   6. build 디렉터리의 내용을 배포하면 정적 웹 사이트 배포
3. github 에 정적 웹 사이트 만들기 
   1. repository 를 생성 : repository 이름은 반드리 계정.github.io
   2. build 디렉털의 내용을 repository 에 복사

7. Docker private Registry 생성

1) hub.docker.com 이 아닌 registry 생성

1. aws ec2 에 접속해서 public IP 와 docker 설치 여부 확인

2) registry 라는 이미지를 이용해서 docker image registy 를 생성

1. 이미지 다운로드
2. 컨테이너 실행

3) 생성한 이미지 저장소를 사용하기 위한 설정 추가

1. /etc/docker/daemon.json 파일에 저장소를 추가 
2. /etc/init.d/docker 파일에 추가
3. 도커 재시작
4. 새로 등록한 레지스트리의 이미지 확인
5. nginx  이미지를 받아와서 tag 를 변경하고 업로드
6. 카탈로그 다시 확인