1.개발자스럽게 깃허브사용하기

저번주부터 프로젝트를 시작했다. 우린 group rule로 브랜치 만들기 전에 이슈를 먼저 올리기를 결정했다. 오늘의 목표는 개발자스럽게 Github 사용하기
강찬성 마스터님께서 올려주신 강의를 듣고 실습해보며 개발자 기본기 강화, 협업 능력 향상, 실전 적용을 하고자한다.

1.3 개발자스럽게 Branch 관리하기

Flow: Flow는 Git을 사용하면서 Branch를 어떤식으로 사용할지에 대한 전략이다.
대표적인 Flow로는 Git, Github가 있다.
Local 중심의 Git flow: 주로 로컬 저장소에서 브랜치를 중심으로 한 개발 흐름을 갖춤
Remote 중심의 Github flow: 리모트 저장소(주로 Github)에서의 작업 흐름을 중심으로 함
여기서 Local과 Remote는 어디를 중심으로 작업 흐름이 진행되는지를 의미한다.

Git Flow

Local 중심 Branch 전략이다. 일반적으로 사용되는 Branch로는 main(master), develop, release, feature, hotfix 등이 있다.

main(master): 배포의 기준이 되는 브랜치면서 release tag를 기록하는 브랜치다. main 브랜치에 직접 commit을 하거나 develop, release 브랜치가 아닌 브랜치에서 merge를 하면 안된다.
develop: 개발의 중심이 되는 브랜치다. 배포 버전별로 정의된 기능을 구현하며 develop브랜치에 모으고, 코드를 배포할 때 develop 브랜치로부터 release 브랜치를 만들어 준비한다. 실제 기능 구현은 develop 브랜치에 하지 않고 feature 브랜치에서 진행한다.
feature: 실제로 기능을 구현하는 브랜치다. 기능을 구현하거나 버그픽스, 리펙토링 등을 수행하기 위해 develop브랜치로부터 브랜치를 만들어 작업을 수행한다. feature 브랜치에서 작업이 완료된 경우 develop 브랜치에 merge를 진행한다. (feat, refactor, fix, docs와 같이 목적에 따라 다양한 종류의 feature 브랜치가 존재한다.)
release: 배포를 준비하는 브랜치다. develop 브랜치에서 배포를 위한 개발이 끝나면, release브랜치를 만들어 배포를 준비한다. release 브랜치에서는 bugfix 및 추가적인 refactoring을 진행한다. 추가된 작업은 develop브랜치에도 반영한다. 배포 준비가 완료되면 main브랜치로 merge를 진행한다.
hotfix: 배포가 완료된 버전(main브랜치)에서 심각한 버그나 문제가 발생했을 때 사용되는 브랜치다. main브랜치에서 hotfix브랜치를 만들어 문제를 해결한 후 필요한 브랜치들에 merge해준다.

GitHub Flow: Remote 중심 Branch 전략이다.

위의 Git Flow에 비해 더 빠른 속도의 개발 및 배포를 가능하게 한다.
Git Flow의 경우 목적에 따라 많은 브랜치를 사용하지만, Github Flow는 main 브랜치와 feature 브랜치로 구성된다.
main 브랜치의 경우 Git Flow의 main, develop, release 브랜치의 역할이 합쳐진 형태이다.
feature 브랜치의 경우 Git Flow의 feature, hotfix브랜치의 역할이 합쳐진 형태이다.
Git Flow와 달리 develop이나 release브랜치처럼 배포 준비를 위한 브랜치가 따로 없다.
따라서 main branch에 merge하는 작업을 신중하게 해야한다.

목표2 Commit 메시지 남기기 Git을 사용할 때 커밋 메시지를 작성하는 규칙인 Commit Convention에 대해 알아보자! 대표적인 Commit Convention인 유다시티 Commit Convention, Gitmoji Commit Convention에 대해 배우고 Commit을 기록할 때마다 자동으로 일련의 로직을 실행해주는 Pre-commit에 대해 배운다. Commit Convention: 커밋을 남기는 규칙이다. 협업 시에 일관적인 Commit Log를 통해 서로 다른 사람들이 작업한 내용을 쉽게 파악 및 유지보수 하기 위해 사용한다. Header, Body, Footer로 구성되며 Body와 Footer은 선택적으로 사용한다. 유다시티 Commit Convention Subject Commit Log의 제목을 나타내는 Subject부분이다. 50자를 넘기지 않고, 대문자로 작성하며 마침표를 붙이지 않는다. 과거시제를 사용하지 않고 명령어로 사용한다. Added(x), Add(o) 일반적으로 Subject에는 prefix로 Type이 붙으며 Type뒤로 작업의 대략적인 내용이 붙는다. feat refactor fix style chore tests docs 새로운 기능 리펙토링 버그 수정 코드포멧팅,주석처리 빌드수정,패키지관리자수정 테스트코드 문서 작업 feat: Add rest api code Body 작업에 대한 상세 기록을 나타내는 본문이다. 별도 Format은 존재하지 않지만 Subject와 Body의 구분을 위해 한칸 공백을 만들어준다. Subject로 설명이 가능한 수준이면 Body는 생략해도 되지만 그렇지 않은 경우는 Subject를 더 간략하게 작성하고 Body에 내용을 추가한다. Subject와 구분될 수 있도록 한칸 띄워 작성하며 72자를 넘기지 않도록 한다.

Body가 생략되는 경우 feat: Add multiply function with two variables. Body가 생략되지 않는 경우 feat: Add user authentication feature

Implemented user registration form with validation
Integrated authentication middleware for secure login process
Enhanced UI with user-friendly error messages Footer 해당 작업과 관련된 Issue의 Tag를 기록한다. Commit Log에 Issue Tag를 남기면 Github에서 자동으로 해당 태그를 인식하여 Issue에 관련된 Commit을 연결해준다. Issue나 Commit에서 양방향으로 서로를 참조할 수 있기 때문에 작업 History관리 목적으로 사용한다. Issue Tag는 #(이슈번호)로 적는다. feat: Add user authentication feature
Implemented user registration form with validation
Integrated authentication middleware for secure login process - Enhanced UI with user-friendly error messages

#123

Gitmogi

깃모지는 이모지를 사용하여 커밋의 의미를 표현하는 커밋 컨벤션이다.

사진 설명을 입력하세요.

각 이모지는 특정한 의미를 가지고 있어서 코드 변경의 성격을 빠르게 파악할 수 있다.

일반적으로 다음과 같은 이모지가 사용된다.

:sparkles: feat (새로운 기능 추가)

:bug: fix (버그 수정)

:memo: docs (문서 변경)

:art: style (코드 스타일 변경)

:recycle: refactor (코드 리팩토링)

:white_check_mark

test (테스트 추가/수정) :construction: WIP (작업 중인 커밋) Body, Footer가 존재하지 않기 때문에 Issue Tag를 남깁니다. :bug: Fix issue with login validation (Fixes #123) Pre-commit 코드를 커밋하기 전에 정해진 로직(hook)을 자동으로 실행한다.

로직 수행

코드 포맷팅: 코드의 일관된 스타일을 유지하기 위해 자동으로 포맷팅을 수행한다.
정적 분석: 정적 분석 도구를 사용하여 코드에서 잠재적인 버그, 보안 취약점 또는 일반적인 코드 품질 문제를 확인한다.
테스트 실행: 자동화된 테스트를 실행하여 새로 추가되었거나, 수정한 코드가 기존 로직에 영향을 주지 않았는지 확인한다.
의존성 관리: 코드에 필요한 모든 라이브러리 의존성이 만족되었는지 확인한다. 목표3 개발자스럽게 Issue 사용하기 Issue 코드를 커밋하기 전에 정해진 로직(hook)을 자동으로 실행한다. 프로젝트에서 작업에 대해 정의하고, 관리할 수 있는 Issue ! Issue의 형태는 새로운 기능 구현, 버그 수정, 개선 사항, 질문 등이 있다. Issue: 개발 작업의 단위이다. 작업의 성격에 따라 기능 구현, 버그 리포팅 등과 같은 Issue로 나뉜다. 배경, 구현해야하는 항목, 관련있는 다른 Issue 혹은 Pull request 등을 작성한다. 버그 리포팅 Issue의 경우 재현 방법, 개발 환경 등과 같이 버그를 고치는 데 필요한 내용을 추가로 작성한다. Issue Template: 반복적으로 작성해야하는 항목들을 줄여줄 수 있다. Issue Tag: Commit에 생성된 issue의 번호를 기록하여 양방향으로 링크를 걸 수 있다. 직업 히스토리 관리 측면에서 필요하다. [실습] Github Repository 연동 준비 Remote 환경(Github)에 올라온 내용이 없기 때문에 Local 환경(내 컴퓨터)에서 해당 프로젝트를 진행할 폴더에 git을 설정한 뒤 Remote에 Push 해야한다. 사진 설명을 입력하세요. git init 명령어로 git 환경 초기화를 한다. 사진 설명을 입력하세요. Readme를 생성한 뒤 커밋을 남기고 Remote Registry를 등록한 뒤에 push한다.

Issue Template 생성하기 (1) - Github 에서 생성하기 사진 설명을 입력하세요. setting - features - issues set up templates 사진 설명을 입력하세요. Bug report - 프로젝트에 버그 리포팅을 위한 템플릿을 생성 Feature request - 프로젝트에 새로운 기능을 제안하는 템플릿을 생성 Custom template - 그 외에 템플릿을 생성할 때 사용하는 기본 템플릿

Feature request를 추가 Preview and edit 버튼으로 내용을 수정할 수 있다. 사진 설명을 입력하세요. Feature request의 기본 템플릿이다. 이름 오른쪽에 수정 버튼으로 수정할 수 있다. 사진 설명을 입력하세요. Background: 작업의 배경을 작성 Todo: 해야할 작업들을 나열. (SubTask 개념) See also: 해당 Issue와 관련있는 다른 Issue 혹은 Pull Request의 태그

Background

Todo

Todo 1
Todo 2

2.전처리 고민

Python의 OpenCV 라이브러리 Canny Edge Detection

import cv2
import matplotlib.pyplot as plt

# 이미지를 흑백으로 불러오기
image = cv2.imread('your_image.jpg', cv2.IMREAD_GRAYSCALE)

# 가우시안 블러 적용 (노이즈 제거)
blurred_image = cv2.GaussianBlur(image, (5, 5), 0)

# Canny Edge Detection 적용
edges = cv2.Canny(blurred_image, threshold1=100, threshold2=200)

# 결과 출력
plt.figure(figsize=(10, 10))
plt.subplot(1, 2, 1)
plt.title('Original Image')
plt.imshow(image, cmap='gray')

plt.subplot(1, 2, 2)
plt.title('Canny Edge Detection')
plt.imshow(edges, cmap='gray')

plt.show()

cv2.imread: 이미지를 읽을 때 흑백(grayscale)으로 불러옴 cv2.GaussianBlur: 가우시안 블러를 사용하여 노이즈를 줄이기 cv2.Canny: Canny Edge Detection을 수행하는 함수고 threshold1과 threshold2는 하한선과 상한선을 나타. 이 값을 조정하여 에지 검출 민감도를 변경할 수 있음 matplotlib: 원본 이미지와 Canny Edge Detection 결과를 시각화하여 비교함.

CLI