합니다, 개발공부📝 합니다, 개발공부📝

사이드 프로젝트를 초기 진행을 해보면서 사용자에게 서비스를 제공하는 방식으로maven repo 제공 방식을 경험해볼 수 있는 기회가 생겨서 어떻게 구현했는지 기록해보았다!  github을 이용해서 maven repo를 구현해서 사용할 수 있게 제공해보았다.       mvn-repository-publish maven repo 형식으로 서비스를 제공하기 위해서 mvn-repository-publish를 사용할 수 있다. 공식 문서 : https://docs.github.com/ko/packages/working-with-a-github-packages-registry/working-with-the-gradle-registry#authenticating-to-github-packages Gradle 레지스..

이전에 Jenkins를 이용하여 CI / CD를 구현한 적이 있는데, 이 부분을 Github Action을 이용하면 매우 간단하게 진행된다고 하여 aws ec2환경에서 구현해보았다. Github Action 테스트 먼저 테스트용 Github Action 파일을 작성하여 실행이 되는지 확인하였다. 확인 과정에서는 Ktlint를 이용하여 문법을 체크하도록 설정한다. 프로젝트에 ktlint plugin을 추가해준다. ↓ https://seosh817.tistory.com/154 [Kotlin/TDD] ktlint를 이용하여 코딩 컨벤션 맞추기 NextStep 이펙티브 코틀린 with TDD, Refactoring, Clean Code에서 배운 ktlint 설정 법을 정리해보고자 합니다. 린트 검사로 코드 개선..

Git에서 로그인을 다르게하면서 사용자를 바꿨다가 다시 돌아와서 push 하려고 하자 Git Error permission denied to 오류가 발생하였다. 이는 이전에 로그인했던 기록때문에 올바른 사용자로 변경되지 않아 발생하는 문제였다. 이때 계속해서 git config를 이용해서 설정을 다시 해주어도 인식하지 못하고 같은 문제가 발생하였는데, 다음의 글을 보고 문제를 해결하였다! ↓ https://stackoverflow.com/questions/5335197/gits-famous-error-permission-to-git-denied-to-user Git's famous "ERROR: Permission to .git denied to user" I have tried googling and ..

이번엔 지난번 강의에서 듣고 알고 싶었던 Github Actions에 대해 유튜브 강의를 찾아 간단하게 공부했다! (강의내용을 정리만 하였다!) 모든 글과 캡쳐는 다음의 영상을 듣고 정리하였다!🙌 ↓ https://www.youtube.com/watch?v=R8_veQiYBjI Github Actions 개발자 workflow를 자동화 하는 플랫폼으로 workflow 중의 하나인 CI / CD 또한 Github Actions를 통해서 자동화 할 수 있다. 자동화 작업의 필요성 작업을 자동화 하는 일이 필요한 이유는 무엇일까? 먼저, 개발에서 많이 사용되는 Github이란 오픈 소스 프로젝트를 위한 플랫폼으로 공개적으로 프로젝트를 사용하고 기여하는 작업을 가능하도록 한다. 위에서 말한 workflow란 새..

프로젝트 진행하면서 git branch 전략을 적용하여 develop에서 개발을 진행하고 PR이 승인되면 main 으로 코드를 merge 하고 있는데, 개발을 잘못하여 main 브랜치에서 작성하고 commit 하였다는 것을 알게 되었다. ① commit 복사 //단일 커밋 복사 git cherry-pick commit hash //여러 커밋 복사 git cherry-pick commit hash1 commit hash2 //hash1과 hash3 사이의 모든 커밋 복사 (^을 붙이지 않으면 앞의 commit은 포함되지 않음) git cherry-oick commit hash1^...commit hash3 이런 경우에 git cherry-pick을 이용해서 이 문제를 해결할 수 있다. 단일 커밋을 복사할 ..

git 커밋을 작성할 때는 원칙에 맞춰 일관성있게 작성해야만 다른 개발자가 봤을 때에도 커밋이 어떤 메세지를 담고 있는지 명확하게 알 수 있다. Commit Message 구조 type: Subject//제목 body//본문(내용) footer//꼬리말 type : 커밋의 의도 Subject : 최대 50글자, 마침표는 포함하지 않음, 영문으로 작성시 맨 앞은 동사원형 + 맨 첫글자는 대문자 body : 최대 72글자, 무엇을 왜 했는지 작성, 긴 설명이 필요할 때에만 작성, 제목과 구분하기 위해서 한 칸 띄고 작성 footer : Issue Tracker ID를 나타내고 싶을 때 작성 ("유형: #이슈 번호"의 형식으로 작성) Fixes: 아직 해결되지 않은 이슈 수정 중 Resolves: 이슈 해결 ..

git을 활용하다 보면 필요에 따라 새로운 브랜치를 생성하고 이용해야 하는 상황이 발생한다. 어떤 필요에 따라 각각의 브랜치를 이름지어야 하는 지 알아보자. Master / Hotfix or Issue / Develop / Feature / Release Master Branch Main Branch로 Release(배포) 할 수 있는 브랜치이다. 최종 배포 이력을 관리하기 위한 브랜치로 배포가능 상태만 관리한다. Hotfix Branch 이미 출시된 버전에서 버그가 발생되는 경우 master 브랜치에서 바로 수정하지 않고 hotfix 브랜치를 분기하고 수정 후 병합한다. 문제가 발생한 부분만 빠르게 처리하며 수정이 완료된 후에는 develop에도 병합해준다. Develop Branch 다음 출시 버전을..

git에 올라가면 안되는 파일 (.env, application.properties, secret key...)을 올렸을 때 이를 해결하는 방법을 알아보자. 올라가 있는 파일 삭제 먼저 git에 push된 파일을 먼저 삭제해보자. //원격 저장소와 로컬 저장소에 있는 파일 모두 삭제 $ git rm 삭제할 파일 이름 $ git rm -r 삭제할 파일 디렉토리 //원격저장소의 파일만 삭제 $ git rm --cached 삭제할 파일 이름 $ git rm --cached -r 삭제할 파일 디렉토리 .gitignore에 해당 파일 추가 올려진 파일을 삭제했다면 .gitignore에 올리면 안되는 파일, 디렉토리를 설정해준다. 이미 commit으로 올라가 있는 파일, 디렉토리의 히스토리 삭제 원격저장소의 파일을..