Dev Blog

기존 포트폴리오가 v2024에서 v2025로 변경되었고백엔드를 기존의 내 blog와 공유하며 supabase로 처리하고 있기 때문에 관리 차원에서 저장소를 분리하기로 하였다.Front End만 따로 빼서 push해버릴 생각이었지만,커밋 로그를 다 날려버리면서 기존의 포트폴리오도 이전 버전으로 돌릴 예정으로잔디가 많이 비워져 버릴 것이기에 commit log 도 같이 옮기기로 하였다.기존 프로젝트 구조Backend는 필요 없어졌다. 초기 Node.js로 백엔드 구축시 express.js로 생성하였는데기존엔 포트폴리오에 기능들이 좀 묶여있었지만, 가장 중요한 Blog도 Next로 분리하였고 이제 포트폴리오는 단순 CRUD만 하는데 굳이 BackEnd가 필요없기도 했다 Node를 백에서 돌리기위해서는 EC2를 실행함에 있어 VPC비용도 나갔기 때문에 AWS EC2는 삭제처리와 더불어 백엔드 로직은 삭제하고 frontEnd 만 살리기로 하였다.작업은 생각보다 간단했다.git subtre

이전 포스팅에 rebase를 통해서 깔끔한 커밋 히스토리를 만들 수 있다라는 것을 강조했고,이를 주로 사용하여 깨끗한 커밋 히스토리를 관리하고 있었다.1️⃣"Rebase"로컬에서 main 브랜치에서 feat 브랜치를 생성하여 각자 개발을 진행하다 보면, 브랜치마다 commit에 따라서 HEAD가 달라지게 된다.이때 main 브랜치에 새로운 커밋이 추가되면,

근래 Git에 중점을 두고 학습하고 있는데,이게 단순하게 "git push" , "git pull" 만 하여 git에 담기만 하다 본격적으로 브런치를 사용하고 있는데정말 오늘 머리 깨지는 줄 알았다.. 삽질을 제대로 하였다.현재 포트폴리오에 Coding Timer + schedule 을 개발 중인데 운영 버전에는 아직 미완성 이라 제외했어야했다.그렇기에 내

Git은 코드의 버전 관리와 협업을 위해 설계된 분산 저장소 시스템이다.여러 개발자가 단위별로 나누어 동시 개발을 가능하게 하고 코드의 충돌을 효과적으로 관리할 수 있도록 해주는 'branch' 기능을 활용하는 것이 매우 중요하다.지난 번에 깃에 관해 설명한 포스팅을 이어, 이 기능을 "잘" 활용하여 더욱 체계적으로 작업을 진행하는 방법에 대해 포스팅을 남

깃에 대한 자료를 물색하다가 의문점이 드는 문장을 발견했다."깃 커밋 전략" 그러고보니 포트폴리오를 진행하면서 커밋에 큰 생각하지 않고 너무 무지성으로git add . git commit을 남발했던 것이 아닐까 라는 생각이 들었다.전 회사에서도 git은 리포지토리만 존재했지 99% svn을 주로 사용했고외주 인력들과도 형상관리를 SVN으로 진행했는데 커밋