+Add item 을 통해 내용 추가 후 

제목 클릭 이후 커스터마이징 가능

스프린트 뷰 추가

ip 주소에서 특유의 도메인을 사용하여 웹사이트를 배포하는 방법을 찾다가 알게된 지식을 차후에 다시 볼 수 있도록 기록한 내용

1.  도메인 주소 구매

https://www.gabia.com/

사진 속에서는 비용이 만만치 않아 보이지만 event domain을 구매하면 1년 기준 500~1000원 정도로 저렴하게 구매하는게 가능하다.

아래는 사진 예시

2.  AWS Route 53 이용

3.  도메인 관리 버튼에서 네임서버 설정

.은 빼야한다 (중요)

네임서버 정보변경은 루트서버 갱신 및 네임서버 캐시에 따라, 적용되는데 1~2일 정도 소요될 수 있다고 합니다.

도움 받은 글

https://seill.tistory.com/1112

요약

1. 도메인 구매
2. AWS Route 5S 서비스 사용
3. 도메인 구매 사이트에서 네임 서버 등록 

Route 5S 서비스 이용 이유

다른 DNS 서비스를 사용해서 도메인 주소를 연결 할 수도 있지만 AWS에 있는 Route 5S 서비스를 이용하는 이유

1. 통합성: Route 53은 기존 AWS 서비스와 잘 통합된다.
2. 높은 가용성: Route 53은 높은 가용성과 안정성을 제공하는 전 세계의 DNS 서버 네트워크를 활용하여 가용성과 안정성이 높다.
3. 헬스 체크: Route 53은 헬스 체크 기능을 제공하여 특정 리소스의 상태를 모니터링 하고 문제 발생 시 트래픽을 다른 리소스로 자동으로 리디렉션 가능하다.
4. 간단한 관리: AWS 서비스의 특징으로 Management Console을 통해 설정을 쉽게 관리할 수 있다.

도메인 구매 사이트에서 네임 서버 등록이 필요한 이유

네임 서버의 역활은 해당 도메인에 이름을 ip주소로 변환하는데 필요한 정보 제공해 주는 것이기 때문에

네임 서버의 등록이 되어 있지 않다면 도메인 주소를 통해 특정 ip 주소로 이동하는 것이 불가능하다. 

따라서 필수적으로 등록해 주어야 한다.

.gitignore 파일이란?

Git에게 특정 파일이나 디렉토리를 추적하지 않도록 지시하는 역할을 하는 특수한 파일
해당 프로젝트와는 관계없는 파일들이 원격저장소에 올라가지 않도록 하기 위해 사용
민감한 정보를 포함하는 파일, 시스템이나 개발 도구에 의해 생성된 파일, 빌드 결과물 등을 Git의 추적 대상에서 제외할 수 있다.

.gitignore 파일의 각 줄은 무시할 패턴을 지정하며, 아래와 같은 규칙을 따릅니다:

1. 빈 줄이나 #로 시작하는 줄은 무시됩니다.
2. 표준 Glob 패턴을 사용합니다.
3. 슬래시(/)로 시작하면 하위 디렉토리에 적용되지 않습니다.
4. 디렉토리는 슬래시(/)를 끝에 사용하여 지정할 수 있습니다.
5. 느낌표(!)로 시작하는 패턴의 파일은 무시되지 않습니다.

사용 예시:

스프링 부트 프로젝트에서 유출되면 안되는 중요한 정보가 담긴 파일이 GIt에 올라가지 않도록 설정

application.properties 파일 제거

# Application configuration
/src/main/resources/application.properties

자동 생성 사이트

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

깃허브 .gitignore파일을 편하게 만들기위한 오픈소스 프로젝트

결과물

# Created by https://www.toptal.com/developers/gitignore/api/java,windows,macos,intellij+all,visualstudiocode,gradle
# Edit at https://www.toptal.com/developers/gitignore?templates=java,windows,macos,intellij+all,visualstudiocode,gradle

### Intellij+all ###
# Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio, WebStorm and Rider
# Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839

# User-specific stuff
.idea/**/workspace.xml
.idea/**/tasks.xml
.idea/**/usage.statistics.xml
.idea/**/dictionaries
.idea/**/shelf

# AWS User-specific
.idea/**/aws.xml

# Generated files
.idea/**/contentModel.xml

# Sensitive or high-churn files
.idea/**/dataSources/
.idea/**/dataSources.ids
.idea/**/dataSources.local.xml
.idea/**/sqlDataSources.xml
.idea/**/dynamic.xml
.idea/**/uiDesigner.xml
.idea/**/dbnavigator.xml

# Gradle
.idea/**/gradle.xml
.idea/**/libraries

# Gradle and Maven with auto-import
# When using Gradle or Maven with auto-import, you should exclude module files,
# since they will be recreated, and may cause churn.  Uncomment if using
# auto-import.
# .idea/artifacts
# .idea/compiler.xml
# .idea/jarRepositories.xml
# .idea/modules.xml
# .idea/*.iml
# .idea/modules
# *.iml
# *.ipr

# CMake
cmake-build-*/

# Mongo Explorer plugin
.idea/**/mongoSettings.xml

# File-based project format
*.iws

# IntelliJ
out/

# mpeltonen/sbt-idea plugin
.idea_modules/

# JIRA plugin
atlassian-ide-plugin.xml

# Cursive Clojure plugin
.idea/replstate.xml

# SonarLint plugin
.idea/sonarlint/

# Crashlytics plugin (for Android Studio and IntelliJ)
com_crashlytics_export_strings.xml
crashlytics.properties
crashlytics-build.properties
fabric.properties

# Editor-based Rest Client
.idea/httpRequests

# Android studio 3.1+ serialized cache file
.idea/caches/build_file_checksums.ser

### Intellij+all Patch ###
# Ignore everything but code style settings and run configurations
# that are supposed to be shared within teams.

.idea/*

!.idea/codeStyles
!.idea/runConfigurations

### Java ###
# Compiled class file
*.class

# Log file
*.log

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar

# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*
replay_pid*

### macOS ###
# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

### macOS Patch ###
# iCloud generated files
*.icloud

### VisualStudioCode ###
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
!.vscode/*.code-snippets

# Local History for Visual Studio Code
.history/

# Built Visual Studio Code Extensions
*.vsix

### VisualStudioCode Patch ###
# Ignore all local history of files
.history
.ionide

### Windows ###
# Windows thumbnail cache files
Thumbs.db
Thumbs.db:encryptable
ehthumbs.db
ehthumbs_vista.db

# Dump file
*.stackdump

# Folder config file
[Dd]esktop.ini

# Recycle Bin used on file shares
$RECYCLE.BIN/

# Windows Installer files
*.cab
*.msi
*.msix
*.msm
*.msp

# Windows shortcuts
*.lnk

### Gradle ###
.gradle
**/build/
!src/**/build/

# Ignore Gradle GUI config
gradle-app.setting

# Avoid ignoring Gradle wrapper jar file (.jar files are usually ignored)
!gradle-wrapper.jar

# Avoid ignore Gradle wrappper properties
!gradle-wrapper.properties

# Cache of project
.gradletasknamecache

# Eclipse Gradle plugin generated files
# Eclipse Core
.project
# JDT-specific (Eclipse Java Development Tools)
.classpath

### Gradle Patch ###
# Java heap dump
*.hprof

# End of https://www.toptal.com/developers/gitignore/api/java,windows,macos,intellij+all,visualstudiocode,gradle

Branch 네이밍 규칙

1) master branch, develop branch

본래 이름을 그대로 사용한다. 

ex: master, develop

2) feature branch.

feature/{feature-name}  형식을 사용한다.

이때 feature-name은 소문자, 하이폰 (-)의 구성으로만 작성한다.

ex: feature/parameter-json-parser, feature/opencv-result-drawing

3) release branch

release/{version} 형식을 사용한다. 

ex: release/1.0

4) hotfix branch

hotfix/{version}, hotfix/{hotfix-name} 형식을 사용한다. 

ex: hotfix/1.0, hotfix/previous-restart-issue

Commit Message

💡 커밋 규칙

• 최소 작업 단위를 기준으로 가능하면 작게 쪼갠다.
• 1개의 커밋에는 1개의 행위만 들어 있게 한다.
• 반드시 커밋구분 리스트를 접두사로 붙인다.
• 한글로 읽는 사람이 이해하기 쉽도록 작성한다. 

title

• 커밋 구분 리스트를 접두사로 사용한다.
• 그 후 ~한다는 명령어로 시작하여 한눈에 어떤 작업을 했는지 알기 쉽게 적는다.
• 영어로 예시를 들면 Create~, Add~, Fix~, Delete~

summary

• 45자 이내로 간결하게 작성한다.

description

• summary를 풀어서 작성한다.
• description만 보고도 어떤 작업을 했는지 파악할 수 있도록 작성한다.
• 기존에서 변경된 사항이 있다면 before, after 를 명시한다.
• ex) 함수 A 리턴값 타입 변경 : int → float

Pull Request

💡 PR 규칙

• 최소 작업 단위를 기준으로 가능하면 작게 쪼갠다.
• 1개의 PR에는 1개의 작업만 들어 있게 한다.
• 코드의 변화를 300줄 미만으로 유지한다.
• 리뷰어가 코딩 스타일을 리뷰하지 않도록 코드 컨벤션을 잘 지킨다.
• 정상적으로 동작하는지 테스트하고, 정상적인 경우에만 PR 한다.
• 한글로 읽는 사람이 이해하기 쉽도록 작성한다. 

title

• 작업한 브랜치 명을 그대로 따라 간다. 

description

• 작업 이유, 작업 내용, 리뷰어가 알아야 할 내용, 이미지 등을 상세하게 명시한다.

template

## 개요
작업하게 된 이유를 작성해주세요.

## 작업 내용
작업한 내용을 상세하게 설명해주세요.

### 추가된 사항
새로 추가한 작업에 대해 설명해주세요.

### 변경 사항
기존 내용에서 변경된 사항을 before -> after 형식으로 작성해주세요.

## 이슈
궁금한 사항 혹은 리뷰어들이 알아야 하는 이슈를 작성해주세요.

## 이미지
시각적인 설명이 필요한 경우 부가적으로 첨부해주세요.

https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

https://blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=skykbc&logNo=222016405016 

GitLab-Flow 전략이란?

GitLab에서 제안한 효율적인 브랜치 관리 전략이다.

기존의 Git Flow나 GitHub Flow의 방식을 확장하여, 복잡한 프로젝트와 배포 환경에서도 안정적인 작업을 가능하게 하는 것이 특징이다.

GitHub Flow전략과 마찬가지로 Master 브랜치가 항상 배포 가능한 상태를 유지하며 

Git Flow전략과 마찬가지로 다양한 종류의 브랜치를 활용하여 작업을 분류 할 수 있다.

(간단한 경우) 브랜치 종류 

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치
feature : 새로운 기능이나 버그 수정을 위한 브랜치 master 브랜치로부터 분기하며 master 브랜치로 병합된다.

방법

1. master 브랜치에서 작업을 시작하기 위한 feature 브랜치로 분기합니다.
2. feature 브랜치에서 작업을 시작하고 작은 단위로 쪼개 커밋합니다.
3. 작업이 완료된 코드는 리뷰 및 테스트를 하고 master 브랜치에 병합시킵니다.

(복잡한 경우) 브랜치 종류

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치로 모든 배포 환경에 대한 공통 코드가 존재한다.
feature : 새로운 기능이나 버그 수정을 위한 브랜치 master 브랜치로부터 분기하며 master 브랜치로 병합된다.
environment : 특정 환경에 대응하는 브랜치 환경에 따라 여러개의 종류가 있을 수 있다.
- development : environment 브랜치 중 하나로 개발자들이 새로운 기능을 개발하고 초기 테스트를 진행하는 환경의 브랜치
- staging : environment 브랜치 중 하나로 실제 서비스 배포 전 마지막 테스트와 검증을 수행하는 환경의 브랜치
- production : environment 브랜치 중 하나로 실제로 사용자에게 서비스되는 프로덕션 환경의 코드를 담당하는 최종 브랜치

방법

1. master 브랜치에서 새로운 기능이나 수정이 필요한 부분에 대해 feature 브랜치를 생성하여 분기합니다.
2. feature 브랜치에서 작업을 시작하고 작은 단위로 쪼개 커밋합니다.
3. 작업이 완료된 코드는 PR 리뷰 및 테스트를 하고 master 브랜치에 병합합니다.
4. master 브랜치에 병합된 변경 사항을 development 브랜치, 환경에 반영합니다.
5. development 브랜치,환경에서 테스트가 성공적으로 수행되면 staging 브랜치,환경에 반영합니다.
6. 실제 서비스 배포 전 마지막 테스트와 검증을 수행하고 완료되면 최종적으로 production 브랜치,환경으로 병합합니다.

(특별한 경우) 브랜치 종류

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치 모든 배포 환경에 대한 공통 코드가 존재한다.
feature : 새로운 기능이나 버그 수정을 위한 브랜치 master 브랜치로부터 분기하며 master 브랜치로 병합된다.
environment : 특정 환경에 대응하는 브랜치
- development : environment 브랜치 중 하나로 개발자들이 새로운 기능을 개발하고 초기 테스트를 진행하는 환경의 브랜치
- staging : environment 브랜치 중 하나로 실제 서비스 배포 전 마지막 테스트와 검증을 수행하는 환경의 브랜치
- production : environment 브랜치 중 하나로 실제로 사용자에게 서비스되는 프로덕션 환경의 코드를 담당하는 최종 브랜치
release : 특정 버전의 배포를 위한 브랜치, 특정 버전의 준비가 완료된 후 해당 브랜치를 프로덕션 브랜치로 병합하여 배포하게 된다.
hotfix : 프로덕션에서 발생한 긴급한 이슈를 해결하기 위한 브랜치 production 브랜치로부터 분기하며 수정 후에는 production과 master 브랜치 모두에 병합된다.

방법

1. master 브랜치에서 작업을 시작하기 위한 feature 브랜치로 분기합니다.
2. feature 브랜치에서 작업을 시작하고 작은 단위로 쪼개 커밋합니다.
3. 작업이 완료된 코드는 PR 리뷰 후 mater 브랜치에 병합합니다.
4. master 브랜치에서 release 브랜치로 분기 후 테스트와 검증을 수행합니다.
5. release 브랜치에 병합된 변경 사항에 테스트가 성공적으로 수행되면 master, development 브랜치, 환경에 반영합니다.
6. development 브랜치,환경에서 테스트가 성공적으로 수행되면 staging 브랜치,환경에 반영합니다.
7. 실제 서비스 배포 전 마지막 테스트와 검증을 수행하고 완료되면 최종적으로 production 브랜치,환경으로 병합합니다.
8. production 환경에서 발생한 긴급한 이슈는 hotfix 브랜치에서 긴급 수정하고 production 및 master 브랜치로 병합합니다.

장점

• 다양한 브랜치를 전략을 사용하여 작업을 분류하기 때문에 복잡한 프로젝트에 적합하다.
• 다양한 브랜치 전략으로 조합하여 사용할 수 있어 유연성이 높다.
• 지속적인 배포와 통합 master 브랜치에서 일어나는 모든 변경 사항은 즉시 테스트와 통합이 가능해지므로, 지속적인 통합(CI)와 배포(CD)를 가능하게 한다. 

단점

• 다양한 브랜치와 워크플로우를 관리해야 하므로 복잡성이 높다.
• 다양한 브랜치를 유지하고 관리하기 위한 비용이 발생할 수 있다.

언제 사용하면 좋은가?

1. 복잡한 프로젝트를 관리 해야할 때
2. 다양한 환경에서 배포해야 할 프로젝트인 경우
3. 지속적인 통합 및 배포 (CI, CD)환경의 구축이 필요한 프로젝트인 경우

GitHub-Flow 전략이란?

GitHub에서 제안한 간단하고 직관적인 Git 브랜치 전략이다.

브랜치를 master 브랜치와 각각의 작업을 위한 topic 브랜치로 나누어서 작업하는게 특징으로 단순성과 배포 중심을 가지고 있다.

주요 포인트는 브랜치를 작업 단위로 만들고 각 브랜치가 자체적으로 완결성을 가져 항상 배포 가능한 상태인 master 브랜치로 병합될 수 있게 관리하는 것이다.

이러한 특징으로 인해 GitHub Flow는 빠른 반복적인 개발과 배포를 가능하게 한다.

브랜치 종류

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치
topic : 새로운 기능 또는 변경 사항을 구현하기 위해 master 브랜치로부터 분기하여 생성되는 브랜치

방법

주의사항: master 브랜치는 언제나 배포 가능한 상태를 유지해야 합니다.

1. master 브랜치에서 작업을 시작하기 위한 새로운 브랜치를 분기합니다.
2. 이때 브랜치의 이름은 작업 내용을 설명하는 방식으로 짓습니다.
3. 새로운 브랜치에서 작업을 수행하고 작은 단위로 쪼개 커밋을 만듭니다.
4. 작업이 완료되면 GitHub에 푸시하고 PR을 생성합니다.
5. PR을 통한 코드리뷰 과정을 거치고 테스트가 통과하면 master 브랜치로 merge합니다.
6. merge된 브랜치를 즉시 배포합니다.

장점

• 간단하고 직관적이다. 새로운 기능을 위한 브랜치를 만들고 그 기능을 완성한 후에 master 브랜치로 병합하는 간단한 워크플로우 작업이기 때문이다.
• 코드 리뷰를 통한 품질 관리. PR을 통해 팀원들의 코드를 리뷰 

단점

• 단순한 워크 플로우를 가지고 있기 때문에 복잡한 프로젝트에 적합하지 않을 수 있다.
• 브랜치 전략이 고정적이다. master 브랜치에서 새 브랜치를 만들고 다시 master 브랜치로 병합하는 방식을 사용하므로 다양한 브랜치 전략을 적용하기 어렵다.

언제 사용하면 좋은가?

1. 작은 규모의 팀에서 단순한 프로젝트를 관리 할 때
2. 빠른 반복과 개발주기를 가지며 지속적인 배포가 필요한 경우

Git-Flow 전략이란?

배달의 민족 안드로이드 개발 파트에서 사용하고 있는 Git branch 전략으로

브랜치를 기능(feature), 릴리스(release), 핫픽스(hotfix) 등으로 구분하여 운영하는게 특징이다.

개발은 develop 브랜치에서 이루어지고, 테스트와 스테이징은 release 브랜치에서 이루어진다.

그리고 문제가 발생하면 핫픽스 브랜치에서 수정하여 메인 브랜치로 병합하게 된다. 

이미지 출처, 참고: https://techblog.woowahan.com/2553/

브랜치 종류

master : 최종 브랜치로 제품을 배포하는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 PR, Merge 한다
feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 PR, Merge 한다
release : 배포를 위해 master 브랜치로 보내기 전에 먼저 테스트와 스테이징을 하기위한 브랜치
hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치

방법

1. master 브랜치에서 develop 브랜치를 분기합니다.
2. 개발자들은 develop 브랜치를 기준으로 브랜치를 분기합니다.
3. 각 구현해야 할 기능 마다 develop 브랜치에서 feature-* 브랜치로 분기합니다.
4. 작업 변경 사항을 최소단위로 feature-* 브랜치로 commit 합니다.
5. 기능을 개발하던 도중 다른 개발자의 PR혹은 커밋으로 develop 브랜치가 변화 했다면 rebase 하여 현재 브랜치의 커밋을 임시적으로 제거하고, rebase 대상 브랜치의 모든 커밋을 먼저 적용한 다음, 이전에 제거했던 커밋을 다시 적용해 작업합니다. (merge 와의 차이점은 선형적인 커밋 이력을 유지할 수 있다는 점 입니다.)
6. 기능 개발이 완료 되었다면 develop 브랜치로 PR 합니다.
7. 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치를 분기합니다.
8. 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영합니다.
9. 테스트가 완료되면 release 브랜치를 master와 develop에 merge합니다.
10. master 브랜치에서 버그 발생시 hotfix-* 브랜치로 분기하여 작업합니다. 이후 develop 브랜치와 master브랜치에 반영합니다.

장점

• 각 단계(개발, 스테이징, 배포 등)에 맞는 브랜치를 사용함으로써 작업을 체계적으로 관리할 수 있다.
• 복잡한 프로젝트에 적합하며, 큰 규모의 팀에서도 효과적으로 작동한다.

단점

• 많은 수의 브랜치를 관리해야 하므로, 브랜치 관리가 복잡해질 수 있다.
• 처음 해당 개발 흐름을 접할 때 이해가 어려울 수 있다. 

언제 사용하면 좋은가?

1. 복잡한 프로젝트를 관리 할 때
2. 정기적인 릴리즈 주기와 명확한 릴리즈 관리가 필요한 프로젝트인 경우