dragonhyeon 님의 블로그

멀티라인 문자열 (Multiline Strings)""" ... """ 멀티라인 문자열을 그대로 쓰면, 들여쓰기가 코드 전체 스타일과 어긋나서 보기가 안 예쁠 수 있음def main(): prompt = f"""When I use multi-line strings in Python,the indentation style looks misaligned and messy.How can I fix this?""" print(prompt)아래와 같이 코드 작성시 출력 앞부분에 공백이 들어감def main(): prompt = f""" When I use multi-line strings in Python, the indentation style looks misaligned and m..

Git(develop) git rebase -i maindevelop 커밋 히스토리를 main 위로 재배열 (develop 에 변화 있음)-i 옵션 여부에 따라 develop 의 커밋 압축 여부를 직접 지정할수도 혹은 지정 없이 모두 그대로 유지할수도 있음(develop) git rebase -i HEAD~3그냥 develop 내부에서 혼자 커밋 히스토리 정리하는거 (develop 에 변화 있음)(main) git merge --squash developdevelop 커밋 히스토리를 하나로 합쳐서 main 위로 새로운 커밋 하나 생성 (develop 에는 변화 없음)그냥 merge 해올때 커밋 하나로 압축해서 가져오는거이후 git add 및 git commit 진행해야 merge 완료됨GitHubCrea..

.env 파일 위치.env 파일은 프로젝트 최상단 (root directory) 에 놓는것이 일반적대부분의 라이브러리 (dotenv, python-decouple, node dotenv 등) 가 root 경로에 있는 .env 파일을 기본적으로 읽음임시 테스트용 파일scratch/ 같은 임시 테스트용 폴더 사용.gitignore 에 scratch/ 폴더를 통째로 넣어두면 폴더 자체가 깃허브에 안 올라감.gitkeep 사용하여 폴더 구조 유지 가능requirements.txt 작성법재현성 (reproducibility) 이 매우 중요한 경우가 아니라면 직접 import 해서 사용하는 패키지만 기록예를 들어 openai 를 설치하면 내부적으로 httpx, tqdm 같은 의존성 패키지가 딸려올 수 있지만 req..

Python f-string파이썬에는 %, .format(), f-string 등 여러 가지 문자열 포매팅 방식이 존재2025년 현재 대세이자 권장되는 방식은 f-string권장 이유:간결함: 변수와 표현식을 바로 중괄호 안에 넣을 수 있음가독성: 문자열과 코드가 뒤섞이지 않고 직관적성능: str.format() 보다 빠름 (CPython 구현 최적화 덕분)표현력: 수식 및 함수 호출도 직접 넣을 수 있음사용법:문자열 앞에 f (또는 F) 접두어 사용{} 내부에 변수명 또는 파이썬 표현식 작성포매팅 옵션 사용 가능중괄호 자체를 출력하려면 {{ 또는 }} 사용PEP 498 (Formatted String Literals) 에서 제안prompt = f"""Summarize the text delimited ..

사용 예시import osfrom dotenv import load_dotenvdef main(): load_dotenv(dotenv_path='.env') openai_api_key = os.getenv(key='OPENAI_API_KEY') print(openai_api_key)if __name__ == '__main__': main()동작 원리load_dotenv() 통해 변수를 현재 실행 중인 파이썬 프로세스의 환경 변수에 등록os.getenv() 통해 환경 변수 사용os.environ 통해 현재 실행 중인 파이썬 프로세스에 등록되어있는 환경 변수 확인 가능꼭 .env 파일이 아니어도 상관없지만 파일 내용은 KEY=VALUE 형식이어야 load_dotenv 가 환경 변수로 등..

IssuesGitHub 의 Issue 는 버그 리포트, 기능 요청, 질문, 작업 항목 등을 기록하고 추적하는 데 사용하는 토론 중심의 티켓 시스템입니다.Issues 작성 방법title 및 description 작성 & 적절한 Assignees, Labels 등 지정혹은 Issue Templates 을 활용하여 작성제목은 일반적으로 [이슈 유형] 간결한 제목 설명 과 같은 형태로 작성ex.[Feature] 페이지 끝에서 자동으로 다음 페이지로 넘어가는 기능 추가[Feature] Add auto-pagination when macro reaches the last page설명은 자유 형식으로 서술형 응답으로 작성하면 되며, 템플릿에서 항목을 제공할 경우 항목에 맞게 작성하면 됨Issue Templates사용..

초기 커밋: README.md, .gitignore 등의 설정 파일들을 main 브랜치에 커밋main 브랜치에서 develop 브랜치를 분기하고, 개발에 필요한 템플릿 코드 등을 develop 에 커밋기능 단위로 develop 브랜치에서 feature/ 브랜치를 분기하고 작업 진행ex. feature/add-user-profile기능 개발이 완료되면 해당 feature 브랜치를 develop 에 병합병합 이후 develop 브랜치에서 버그가 확인되면 develop 브랜치에서 바로 수정 (git flow 방식에서는 develop 브랜치에 직접 커밋하지 않는 것이 원칙이긴 함)develop 브랜치에서 발견된 버그의 규모가 크다면 feature/ 브랜치로 분기하여 작업 진행후 다시 develop 에 병합실제 ..

Git Flow 브랜칭 전략을 전제로 합니다. develop 브랜치에서 feature 브랜치로 분기한 상황입니다. feature 브랜치 개발 완료 후 develop 에 merge 시, develop 에 이미 새로운 커밋 이력이 생겨있는 경우merge 사용이 일반적히스토리를 그대로 보존하므로, 이력이 안전하게 남고 협업에 적합merge 정책에 따라 rebase 혹은 squash 를 사용할 수 도 있지만 기본적으로는 merge 사용feature 브랜치에서 개발 진행중에 develop 에서 코드 수정이 발생해 수정된 develop 코드 기반에서 개발을 이어가야 하는 경우rebase 사용이 일반적커밋 히스토리가 깔끔해지고, develop 의 최신 상태를 기반으로 개발 가능merge 를 사용하면 불필요한 병합 커..

Create a merge commit vs Squash and merge vs Rebase and mergeCreate a merge commit포크 (병렬 분기) 형태로 병합fast-forward merge 가 가능한 병합일지라도 GitHub 상에서는 해당 옵션 선택시 항상 포크 형태로 병합커밋 이력을 직선형으로 유지하고 싶다면 Rebase and merge 옵션을 선택해야 함하지만 Rebase and merge 옵션을 선택할 경우 커밋 해시는 변경됨커밋 이력 보존SHA 동일Squash and merge직선형으로 병합커밋 이력 손실SHA 변경Rebase and merge직선형으로 병합커밋 이력 보존SHA 변경

fetch원격 브랜치의 최신 상태를 로컬의 원격 추적 브랜치로 업데이트하는 명령어입니다.git fetch / 에서 fetch 해옴git fetchremote alias 가 origin 으로 설정된 원격 저장소에서 모든 브랜치 정보를 가져옴git fetch --pruneremote alias 가 origin 으로 설정된 원격 저장소에서 모든 브랜치 정보를 prune 방식으로 가져옴git fetch --all모든 원격 저장소에서 모든 브랜치 정보를 가져옴git fetch --all --prune모든 원격 저장소에서 모든 브랜치 정보를 prune 방식으로 가져옴