2024-03-02 TIL 문서 복사

Signed-off-by: rlaisqls <rlaisqls@gmail.com>

src/content/docs/TIL/Git/Flow/GitFlow.md

@@ -0,0 +1,32 @@
+---
+title: 'GitFlow'
+lastUpdated: '2024-03-02'
+---
+
+Git Flow 는 2010년 Vincent Driessen 이 작성한 블로그 글을 통해 유명해지기 시작한 Git Branching Model중 하나로, Git의 사용 방법론이다. GitFlow는 프로젝트를 런칭한 이후에도 코드를 관리하기 용이하게 하고, 프로젝트에서 발생하는 다영한 워크플로우의 구현이 가능하기 떄문에 많은 개발자들이 사용하는 방법론으로 자리잡게 되었다. 에디터와 IDE에서 플러그인으로 지원하는 경우도 많다.
+
+브랜치의 종류가 많아 복잡하고, release와 master의 구분이 모호하기도 하지만 프로젝트의 규모가 커지면 커질수록 소스코드를 관리하기에 용이하다는 장점이 있다.
+
+<br>
+<img src="https://techblog.woowahan.com/wp-content/uploads/img/2017-10-30/git-flow_overall_graph.png">
+
+---
+
+## GitFlow의 브랜치
+
+Git Flow는 크게 5개의 branch 를 사용한다. 그중 가장 중심이 되는 브랜치는 Main 브랜치인 `master`와 `develop`브랜치이고, 나머지인 `feature`, `release`, `hotfix` 브랜치는 중간 과정을 보조하는 역할을 한다.
+
+- ### feature
+    각각의 기능 구현을 담당하는 브랜치이다. 주로 `feature/{구현기능명}`과 같은 명칭으로 생성되며, develop 브랜치로 머지된다. 머지된 후에는 해당 브랜치가 삭제된다. 
+
+- ### develop 
+    develop 브랜치는 말 그대로 개발을 진행하는 브랜치이다. 하나의 feature 브랜치가 머지될 때마다 develop 브랜치에 해당 기능이 추가된다. develop 브랜치는 배포할 수준의 기능을 갖추면 release 브랜치로 머지된다.
+
+- ### release
+    개발된 내용을 배포하기 위해 준비하는 브랜치이다. develop 브랜치에서 개발한 기능이 합쳐져 relese 브랜치가 생성되고, 검토 후에는 master 브랜치로 머지한다.
+
+- ### hotfix
+    배포된 소스에서 버그가 발생하면 생성되는 브랜치이다.  release 브랜치를 거쳐 한차례 버그 검사를 했지만 예상치 못하게 배포 후에 발견된 버그들에 대해서 빠르게 수정하기 위해 만들어진다. 수정이 완료되면 develop 브랜치, release 브랜치와 marster 브랜치에 수정사항을 반영한다.
+
+- ### master
+    바로 배포되어 사용 가능한 (production-ready) 상태를 가지고 있는 브랜치이다. 최종적으로 배포될 코드가 있기 때문에, 프로젝트의 중심이 된다.

src/content/docs/TIL/Git/Flow/GithubFlow.md

@@ -0,0 +1,26 @@
+---
+title: 'GithubFlow'
+lastUpdated: '2024-03-02'
+---
+
+GitFlow의 브랜치 전략의 복잡한 부분을 생략하여 간략화한 브랜치 전략이다. github flow는 master 브랜치 하나만을 가지고 진행하는 방식이다.
+
+<br>
+<img src="https://user-images.githubusercontent.com/43775108/125813582-d1500c51-e1af-44e7-9f90-83901dfec03f.png">
+<br>
+
+GitHub Flow는 `master`와 `feature`, 두개의 브랜치로 나뉜다.
+
+Github Flow의 개발 과정은 다음과 같다.
+
+1. master 브랜치에서 개발이 시작된다.
+2. 기능이나 버그에 대해 issue를 작성한다.
+3. 팀원들이 issue 해결을 위해 master 브랜치에서 생성한 `feature/{구현기능}` 브랜치에서 개발을 진행하고 커밋한다.
+4. 개발한 코드를 master 브랜치에 병합할 수 있도록 요청을 보낸다.
+    즉, **pull request**를 날린다.
+5. pull request를 통해 팀원들간에 피드백을 주고받거나 버그를 찾는다. 
+6. 모든 리뷰가 이뤄지면 테스트를 진행한 후 master 브랜치에 머지한다.
+
+github flow는 시시각각 master에 머지될 때마다 배포가 이루어지는 것이 좋다. 따라서 CI/CD를 통한 배포 자동화를 적용하는 것이 좋다.
+
+pull request에서 충분한 리뷰와 피드백이 진행되지 않으면 배포된 코드에서 버그가 발생할 수 있으므로 주의해야한다.

src/content/docs/TIL/Git/GitLab.md

@@ -0,0 +1,53 @@
+---
+title: 'GitLab'
+lastUpdated: '2024-03-02'
+---
+
+Gitlab은 Git의 원격 저장소와 코드 리뷰, 이슈 트래커 기능등을 제공하는 소프트웨어로, 설치형 Github라는 컨셉으로 시작된 프로젝트이기 때문에 Github와 비슷한 면이 많다.
+
+## 1. 패키지 종류
+GitLab 패키지는 3가지로 구분된다.
+
+- GitLab CE : Community Edition으로 설치형이고 아무런 제한 없이 무료
+- GitLab EE : Enterprise Edition으로 설치형이고 매월 유저당 과금 [(참고)](https://about.gitlab.com/pricing/)
+- GitLab.com : 클라우드형이고 개인이 가입해서 사용하면 무료
+
+## 2. 기능
+- Git 저장소 및 관리
+    - 프로젝트 생성하면 자동으로 git 저장소가 생성됨
+- 그룹 및 팀원
+    - 그룹을 만들고 팀원을 지정해서 그룹 단위로 접근 권한을 관리할 수 있음
+- 업무 관리
+    - 마일스톤을 설정하고 이슈를 등록해서 담당자를 지정해서 업무를 관리할 수 있음
+    - 코드 커밋 로그에 이슈번호 넣으면 자동으로 이슈와 연결
+    - 라벨을 사용해서 이슈를 구분해서 관리할 수 있음
+- 코드 리뷰
+    - Merge request를 통해 코드 리뷰를 할 수 있는 프로세스를 만들 수 있음
+    - 해당 request에 댓글로 커뮤니케이션 할 수 있고 소스코드에도 댓글 달 수 있음
+- 위키
+    - markdown 형식 지원
+    - wiki 별도 git 저장소가 생성되어 로컬에서 작업해서 push 해도 됨
+- 이력 및 통계 조회
+    - Activity 이력 조회
+  - Files 브라우징
+  - Commit 브라우징(커밋 이력, 브랜치로 비쥬얼하게 이력 조회, 그래프로 통계 제공)
+- 검색
+  - 전체 검색: 프로젝트, 이슈, Merge request 검색 가능
+  - 그룹 내 검색: 프로젝트, 이슈, Merge request 검색 가능
+  - 프로젝트 내 검색: 코드, 이슈, Merge request, 코멘트, Wiki 검색 가능
+- Snippets
+  - 재사용 가능한 소스 코드나 텍스트를 저장해서 사용하는 기능
+  - 공통 유틸성 코드나 팁에 대해서 공개해서 사용하면 좋을 것 같다.
+- 관리자
+  - 그룹 및 사용자 관리
+  - 관리자 페이지에서 사용자 추가, 혹은 회원가입 형태도 되고 LDAP 연동도 가능함
+
+## 3. 그외 특징
+- 오픈 소스: MIT 라이센스로 700명 이상의 개발자들이 참여하고 있는 프로젝트
+- 확장성: 서버당 25,000명의 유저 수용 가능, A-A 클러스터 지원
+
+## 4. 장점
+- 비용: 유저수나 프로젝트 수에 관계없이 무료
+- 사용성: 다른 무료 솔루션들에 비해서 UI가 괜찮다. 모바일 Web, App으로도 사용 가능
+- 운영성: 대부분의 관리는 웹 브라우저로 가능.
+- 최신성: 오픈 소스 그룹이 활발히 활동하고 있어서 지속적으로 업데이트 된다. 

src/content/docs/TIL/Git/Selfhosted Runner.md

@@ -0,0 +1,63 @@
+---
+title: 'Selfhosted Runner'
+lastUpdated: '2024-03-02'
+---
+
+Self-hosted Runner란 Github Actions에서 사용자가 지정하는 로컬 컴퓨팅 자원으로 빌드를 수행하도록 설정하는 기능이다. 주로 배포작업이 많아 배포가 지체되거나 서버 비용이 부담되는 경우 사용한다.
+
+
+## 설정 방법
+
+Github Actions을 사용하고자 하는 저장소에서 Settings - Actions - Runners로 이동한다.
+
+<img width="1268" alt="image" src="https://github.com/rlaisqls/TIL/assets/81006587/6634f525-7bbc-4876-8eae-5e08f7655906">
+
+설정하고자 하는 로컬 머신에 해당되는 OS를 선택하면 OS 별로 설정하는 방법이 Download와 Configure란에 설명되어 있다. Linux 기준으로는 다음과 같다.
+
+#### Download
+```bash
+# Create a folder
+$ mkdir actions-runner && cd actions-runner# Download the latest runner package
+$ curl -o actions-runner-linux-x64-2.307.1.tar.gz -L https://github.com/actions/runner/releases/download/v2.307.1/actions-runner-linux-x64-2.307.1.tar.gz# Optional: Validate the hash
+$ echo "038c9e98b3912c5fd6d0b277f2e4266b2a10accc1ff8ff981b9971a8e76b5441  actions-runner-linux-x64-2.307.1.tar.gz" | shasum -a 256 -c# Extract the installer
+$ tar xzf ./actions-runner-linux-x64-2.307.1.tar.gz
+```
+
+#### Configure
+```bash
+# Create the runner and start the configuration experience
+$ ./config.sh --url https://github.com/rlaisqls/rlaisqls --token ATKA767R3GXF2HTFSJ72VZ3E3MNQ6# Last step, run it!
+$ ./run.sh
+```
+
+Github가 로컬머신에 접속하는 방식이 아닌 로컬머신에서 github 저장소로 접속하는 방식이기 때문에 github 저장소 주소와 액세스 토큰으로 설정해야 한다.
+
+토큰은 개인 계정 Settings - Developer settings - Personal access tokens - Generate new token 에서 `admin:enterprise - manage_runners:enterprise`로 발급받을 수도 있다.
+
+## 사용 방법
+
+정상적으로 github에 등록이 되면 github의 Runners에서도 목록을 확인할 수 있다.
+
+등록한 Self-hosted Runner를 활성화시키기 위해서는 해당 로컬 기기의 actions-runner 폴더에서 run.sh 프로그램을 실행시킨다.
+
+```bash
+./run.sh
+```
+
+이제 workflows 디렉토리 안에 actions 사용시 해당 self-hosted runner를 통해 빌드되도록 yaml 파일을 만들어주면 된다.
+
+```bash
+runs-on: self-hosted
+```
+
+등록된 self-hosted runner가 많을 경우 OS 값을 조합하거나, Custom 라벨을 붙여 구분할 수 있다.
+
+```bash
+runs-on: [self-hosted, linux, x64, custom-label]
+```
+
+Self-Hosted Runner의 장점으로는 enter Github-hosted Runner와 달리 사용 비용이 전혀 없기 때문에, private repository에서 작업하는 경우에 비용을 줄일 수 있다는 점이 있다. 하지만 사용하는 시점에 Github와 연결이 되어있어야 하고 로컬머신에 대한 관리가 추가로 필요하다는 단점이 있다. 배포하는 상황에 따라서 적절히 로컬 머신을 연결하여 배포용 서버로 사용하면 좋을 것 같다.
+
+---
+참고
+- https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners

src/content/docs/TIL/Git/hooks/GitHub hooks.md

@@ -0,0 +1,38 @@
+---
+title: 'GitHub hooks'
+lastUpdated: '2024-03-02'
+---
+
+Git에서는 어떤 이벤트가 생겼을 때 자동으로 특정 스크립트를 실행하도록 할 수 있다. 이 훅은 클라이언트 훅과 서버 훅으로 나눌 수 있는데, 클라이언트 훅은 커밋이나 Merge 할 때 실행되고 서버 훅은 Push 할 때 서버에서 실행된다. 
+
+프로젝트의 `.git/hooks` 폴더에 들어가서 해당 훅의 이름을 파일명으로 쉘스크립트를 작성하면, 해당 훅이 특정 상황에 자동으로 실행된다. 
+
+<img width="776" alt="image" src="https://user-images.githubusercontent.com/81006587/203177263-6763519c-e0d9-4dc0-a1e7-d9ea1b529de1.png">
+
+분류에 따른 훅은 아래 표와 같다.​
+
+### Commit workflow hook
+
+|훅|설명|
+|-|-|
+|pre-commit|commit 을 실행하기 전에 실행|
+|prepare-commit-msg|commit 메시지를 생성하고 편집기를 실행하기 전에 실행|
+|commit-msg|commit 메시지를 완성한 후 commit 을 최종 완료하기 전에 실행|
+|post-commit|commit 을 완료한 후 실행|
+
+### Email workflow hook
+
+|훅|설명|
+|-|-|
+|applypatch-msg|git am 명령 실행 시 가장 먼저 실행|
+|pre-applypatch|patch 적용 후 실행하며, patch 를 중단시킬 수 있음|
+|post-applypatch|git am 명령에서 마지막으로 실행하며, patch 를 중단시킬 수 없음|
+
+### 기타
+
+|훅|설명|
+|-|-|
+|pre-rebase|Rebase 하기 전에 실행|
+|post-rewrite|git commit –amend, git rebase 와 같이 커밋을 변경하는 명령을 실행한 후 실행
+|post-merge|Merge 가 끝나고 나서 실행|
+|pre-push|git push 명령 실행 시 동작하며 리모트 정보를 업데이트 하고 난 후 리모트로 데이터를 전송하기 전에 실행. push 를 중단시킬 수 있음|

src/content/docs/TIL/Git/hooks/githook을 위한 perl command.md

@@ -0,0 +1,45 @@
+---
+title: 'githook을 위한 perl command'
+lastUpdated: '2023-12-11'
+---
+## perl option
+
+Perl은 심플한 프로그래밍 언어 중 하나이다. CLI에서 `perl` 명령어를 통해 짧은 스크립트를 실행할 수 있다.
+
+아래와 같이 텍스트 대치 등 간단한 처리 스크립트를 작성하는 데 사용하기 좋다.
+
+```bash
+perl -p0e 's/__PROJECT_TREE__/`cat`/se' "$readme_template" > "$readme"
+```
+
+1. **실행 제어**
+    - -e  : 스크립트로서 실행할 스트링을 지정하여 Command Line에서 수행
+    - -M : 펄 모듈을 로드하는 옵션이며, Default Import 하지 않을 경우 -m 옵션을 사용
+    - -l   : 표준 장소 앞에서 모듈을 검색하기 위한 디렉토리 지정 
+    - -c  : 펄 프로그램을 컴파일(실행전 에러 체크)
+
+2. **데이터**
+    - -0  : (zero) Input Record 구분자 지정(00, 0777)
+    - -a  : split된 결과를 @F 배열에 사용 (-p, -n)
+    - -n  : <>를 사용하여 파일에 레코드 값을 @ARGV 인자로 검색(-p,-e로 정의 및 파일을 한라인씩 처리)
+    - -p  : -n과 동일, $_의 내용을 프린트
+    - -i  : 파일 편집(perldoc perlnum 참조)
+    - -F  : 패턴으로 분활하여 사용(awk -f'|' eq perl -F'|')
+    - -s : enable rudimentary parsing for switches after programfile
+    - -S : look for programfile using PATH environment variable
+
+3. **위험**
+    - -w  : 펄 코드에 대한 에러코드(warning)를 출력 (코드상 use warnings 키워드 사용)
+
+4. **버전**
+    - -v   : 버전을 확인 하기 위한 옵션(중요한 펄 정보를 보여줌)
+    - -V   : 버전에 대한 구성을 보여주는 옵션(Config.pm 참조)
+
+## 텍스트 치환
+
+```
+s/{before}/{after}/;
+```
+
+https://www.perl.com/pub/2004/08/09/commandline.html/
+https://thdnice.tistory.com/49