글

라벨이 git인 게시물 표시

Gitlab으로 CI/CD하기( DevOps 구축 )

DevOps = Development + Operations 개발 조직과 운영 조직을 융합하기 위한 개발 방법론이다. 운영 조직에서는 서비스를 안정적으로 운영, 확장, 관리하는 것이 중요하다. 트래픽 모니터링, 재고 용량에 대해서 모니터링 등의 작업을 수행한다. 개발 조직에서는 기획에 따라서 새로운 기능을 개발하거나, 버그 수정, 성능 최적화 등을 수행한다. 어떤 작업을 수행하든 코드의 변경이 운영 조직에 영향을 미치고 결국에는 운영 서버에 반영돼야한다.
댓글 쓰기
Read more »

Git commands(branch, checkout, update 및 pull error 해결)

이미지
- git branch <new branch name> : 새 브랜치 생성 - git branch -a : local, remote의 branch 목록을 전부 출력. - git checkout <branch name> : 현 작업공간(현 branch)에서 <branch name>으로 이동 - git remote update : remote에서의 변경 사항을 갱신 Error 원인 및 해결법 사례1 : git pull <branch name> 할 때 다음과 같은 에러가 뜸. error: The following untracked working tree files would be overwritten by checkout: .idea/.gitignore .idea/inspectionProfiles/profiles_settings.xml .idea/modules.xml .idea/vcs.xml .idea/xxx.iml Please move or remove them before you merge. untrack 되는 파일들을 pull 하려고 할 때 로컬에 있는 파일들이 덮어씌워주기 때문에 경고가 생기는 케이스다. untrack할 파일들을 미리 .gitignore에 리스팅해두고 커밋했어야했지만 그러지 않았기 때문에 생긴다. 이 파일들이 속해있는 폴더 .idea 폴더는 IDE에서는 보이지 않지만 파일탐색기를 타고 들어가보면 다음과 같이 존재한다. .idea는 프로젝트의 메타데이터이기 때문에 프로그래머가 직접 수정할일이 없어서  IDE 프로젝트 트리에는 보여주지 않지만 Git으로 관리할 때는 여전히 관리 대상이다. 보통 .idea는 untrack 되는 파일로, .gitignore의 대상이다. 이미 .idea를 포함한채로 commit 했기 때문에  다시 .gitignore에 포함시키려면 별도의 작업이 필요하다. 이 작업에 대해서는 다음 포스팅을 참고한다. https://cpusuite.blogspot.com/2022...
댓글 쓰기
Read more »

Git .gitignore 사용법 ( .idea/를 gitignore 해, 말아?)

.gitigrnore는 git의 관리 대상으로 넣지 않을 파일들이 리스팅되어있는 파일이다. 간혹 .gitigrnore에 관리 대상으로 넣지 않을 파일들을 리스팅 했지만 실제 커밋하다보면 반영되지 않는 경우가 있다. .gitignore는 새로 추가되어서 아직 track되지 않는 파일들만 무시하기 때문이다. a파일을 생성하고(자의적으로든 Pycharm 프로젝트가 자동으로 생성했든) .gitignore에 리스팅하지 않은 채 이미 remote 저장소에 커밋했다면, 커밋 후에 a파일을 .girigrnore 파일에 리스팅해도 이미 a파일은 track되고 있다. 이런 경우에는 다음과 같은 조치를 취해야한다. 1 git rm --cached -r .idea/     -> 리포지토리로부터 .idea를 삭제한다. 2 echo '.idea' >> .gitignore    -> gitignore 파일을 갱신한다. 3 .git add .gitignore             ->  gitignore 파일을 add하고 커밋. 4 git 커밋 후 push .idea파일 또는 폴더를 삭제할 수 없다고 뜰 때는, 마지막 argument에 실제 경로를 기입해야한다. .idea/의 상위폴더가 utils라면 utils/.idea로 되어 있을 때에는 후자로 기입해야한다. 스택 오버플로글을 찾아보면 1에서 git rm -r --cached . 를 사용하라라는 답변이 있는데 댓글로 캐시된 파일 전부를 지우는건 과하다 라는 의견이 있다. 대댓글로, '큰 프로젝트를 관리할 때는 파일 하나하나 다 리스팅 하기 번거롭다' 라는 의견이 있고 rm -r --cached 이후에 gitignore갱신 뒤 add . 을 하지 않으면 remoted 브랜치와 차이가 생기기 때문에 문제가 발생할 요지가 있다. 참고로 git rm -h로 알 수 있는 rm -r의 정체는 rec...
댓글 쓰기
Read more »

Git commands(reset, revert)

 reset 이력을 되돌리고자하는 그 당시 상태로 되돌린다. git reset <옵션> <돌아가고싶은 커밋> ex) git reset <옵션> ebf3fgh9 ebf3fgh9 이후의 내용과 상태는 옵션에 따라 달라진다. 옵션은 3가지 ( hard, mixed, soft )가 있다. git reset --hard ebf3fgh9 ebf3fgh9로 돌아간다. 돌아가려는 이력이후의 모든 내용을 지워 버린다. git reset --soft ebf3fgh9 ebf3fgh9로 돌아간다. 이후의 커밋의 내용, 스테이지가 그대로 남아있어서  바로 커밋할 수 있는 상태로 돌아간다. git reset --mixed ebf3fgh9 git reset ebf3fgh9 ( 옵션을 공백으로 둘 때는 기본적으로 --mixed로 작동한다. ) ebf3gfgh9로 돌아간다.이후에 변경된 내용들은 남아있지만 인덱스는 초기화됨. 커밋을 하려면 다시 변경된 내용은 추가해야 하는 상태이다. revert revert는 이전 이력은 그대로 두고, 되돌릴 커밋의 코드(내용)만 원복시킴. git revert <원복시킬 커밋> git revert 2664ce8 git revert 2664ce8..19fgk99(여러개 범위의 커밋을 지정해서 원복) 하지만 이력 중간의 특정 커밋을 reset을 사용하여 취소하려고 한다면  이후 이력을 모두 날려버리게 된다. 이런 때 revert를 사용하여 특정 커밋의 내용만 되돌릴 수 있다. 또한 이미 원격 리파지토리에 push 를 한 상태라면 reset을 사용하면 reset 하기 이전으로 되돌리기 전까지는 push 할 수 없게됩니다.  force 옵션은 위험하니 최후의 수단으로 가지고 있는다. 이미 push 한 코드라면 미련을 버리고 revert로 커밋을 되돌려야한다. -> 왜? push를 하게되면 가장 최신의 commit을 기준으로 브랜치에 반영된다.     0-1-2-3-...
댓글 쓰기
Read more »

Git commands(diff, stash)

 git diff branch_a branch_b branch_a와 branch_b 의 차이를 터미널에 보여준다. ex) git diff origin/master origin/feature_a git stash branch_a에서 작업을 하다가 다른 브랜치로 넘어가야 할 때 작업한 내용을 임시로 백업할 때 사용한다. commit을 해도 되긴하지만,  작업 도중인 중간 결과물을 commit 할 때에는 커밋 메시지도 뭐라고 넣을지 애매하고  취소할 때 귀찮기 때문에 stash가 용이하다. commit은 local에 변경 내용을 반영시키는 절차라서, 아직 반영 시킬 준비가 안 됐을 때 stash를 쓰면 용이하다.  git stash list 백업된(stashed) 내용을 보여준다. git stash apply stash@{0) (stash 이름으로 가져오기) or git stash apply 0  (stash 인덱스 번호로 가져오기) stash된 내용을 다시 불러올 때 사용한다. apply 뒤에 인자를 부여하지 않고 git stash apply만 입력하면 가장 최근의 stashed 백업을 가져온다. git stash drop stash@{0}  (stash 이름으로 삭제) or git stash drop 0  (인덱스 번호로 삭제) 특정 stash를 삭제할 때 사용 git stash branch new_branch stash된 내용으로 새로운 브랜치(new_branch)를 생성할 때 사용.  <참고 링크> https://backlog.com/git-tutorial/kr/ https://itholic.github.io/git-stash/
댓글 쓰기
Read more »

이 블로그의 인기 게시물

실무진 면접 경험으로 정리하는 백엔드 (1) : 에듀 테크 기업 면접

에듀 테크 기술 면접 시간 내어 이력서를 꼼꼼하게 봐주시고 서류상으로는 회사에서 원하는 background라고 생각해주셔서 느낌이 좋았다. 최근 본 면접들 중 가장 깊이있는 질문을 해주셨고 오답과 대안에 대한 설명도 해주셔서 배워갈 수 있었다. 아쉽게도 합격하지 못했지만 좋은 면접 경험이었기 때문에 다음 면접에서 더 견고한 답변을 위해 정리해보았다. 질문&답변&더 나은 답변 일반 질문 이직 사유? 경영상의 이유로 인한 권고사직, 프로덕트 개발과 프로덕트 피벗 과정의 공백기 회사의 이 직군에 지원하면서 뭘 기대하는지? 거의 혼자서 개발을 해왔는데 다른 관점의 의견을 들을 기회가 없었다. 여러 개발자의 의견을 듣고 내 의견에 태클을 걸며 같이 발전하면 좋겠다. 공백기에 뭐하고 있는지 ?  1. django template과 admin, 그리고 오픈소스 wysiwyg를 사용하여 블로깅 서비스 사이드 프로젝트하면서 풀스택 공부중이다. 2. 현업에서 줄곧 이미 구축된 ci/cd를 사용해오고있었는데 직접 구현을 학습하기 위해 github action workflow를 공부하고 있음.  기술&개발 관련 관리형 서비스를 쓰지 않고 aws ec2를 쓴 이유 ? - 비용문제 vpc 어떻게 설정했나? - production region은 모든 ip에 대해서 열고   development region은 사무실 개발 pc와 사무실 기기들의 ip만 접근가능하도록 함 nginx ssl 적용했다고 하는데, 인증서 뭐 사용했나? - 'let's encrypt'사용했는데 생각이 안나서 대답못함. socketio에는 wsgi or asgi? - wsgi vs asgi 차이점에 대해서 답변함. django vs fast api ? - 동기, 비동기 서버 기반과 기타 feature에 대해서 답변함. - django에서 기본 제공되는 템플릿, admin,ORM과 미들웨어들 - fastapi는 기타 기능들을 따로 붙여서 써야한다고 답변, django도 ...
Read more »

노마드코더 개발자북클럽 Clean code TIL 6 : 6장. 객체와 자료구조

      오늘 TIL 3줄 요약 구현을 감추려면 추상화가 필요하다. 객체 지향 코드에서 어려운 변경은 절차적인 코드에서 쉽다. 절차적인 코드에서 어려운 변경은 객체 지향 코드에서 쉽다. 모듈은 자신이 조작하는 객체의 속사정을 몰라야한다. -> 특히 기차 충돌 코드를 피하라. TIL (Today I Learned) 날짜 2025. 06.01 오늘 읽은 범위 5장. 형식 맞추기 기억하고 싶은 내용을 써보세요. 도형 클래스는 간단한 자료구조로, 도형 동작 방식은 Geometry 클래스에서 구현한다. 객체라면 내부 구조를 감춰야 한다. 정확히는, 1. 동작을 공개하고  2. 자료를 숨겨라. 함수나 타입을 보호할지 공개할지에 대한 확신이 부족할 때 잡종 구조가 생긴다.  DTO = 자료 전달 객체 db, 통신을 위한 소켓에서 받은 메시지의 구문을 분석하여 db의 raw data를 애플리케이션의 객체로 변환할 때 유용. 새로운 자료 타입을 추가하는 유연성이 필요하면 객체가 더 적합하다. 새로운 동작을 추가하는 유연성이 필요하다면, 자료구조와 절차적인 코드가 더 적합하다. 활성 레코드는 자료로 취급하며 비즈니스 규칙를 담고 내부자료(높은 확률로 활성 레코드 인스턴스)를 숨기는 객체는 따로 생성한다. 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요 잡종 구조 !! 내가 최근에 구현한 클래스 인 것 같다. 다시 리팩토링 할 까? 한 때는 이론적인 책이구나라고 생각했는데, 이 챕터를 읽고 생각이 바뀌었다. 아주 좋은 실례를 다루고 있어서 고개를 끄덕이면서 읽게 되었다. 특히, 활성 레코드의 취급에 대한 부분이 명쾌했다. 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.   #노개북   #노마드코더   #개발자북클럽  
Read more »

백엔드 개발자가 Djnago fullstack 사이드 프로젝트를하며 ( html, css, vanillaJS 그리고 JS프레임워크 )

서론 웹 개발 환경에서 FE 개발자와 BE 개발자는 상대의 업무를 서로 이해하게된다면  좀 더 총괄적인 서비스의 흐름과 병목지점을 파악할 수 있다. 때문에 이 둘의 협업 과정은 자연스럽게 Full-stack을 지향하고 있는 과정이라고 생각한다. 24년 12월부터 Django fullstack 사이드 프로젝트를 시작했다. 본론 시행착오 python django 코드 뿐 아니라 html + css + js도 함께 커버하기에 작업에 상당한 context switch가 있었다. 머릿속에 그린 것을 도식화나 문서화하지 않고 무작정 뛰어들었기 때문에  디자인 중인 화면을 확인할 곳이 없었다는 흠이 있었다. 특히 wireframe, 화면설계서가 없으니까  백엔드 작업시 하나의 기능을 완성하기 전까지 제대로 빌드가 되지 않기 때문에  dribble이라는 디자인 사이트를 많이 참고했다. 중복 작업과 반복 작업 중복, 반복 작업 django template language에서 상속을 지원하기 때문에 베이스 템플릿을 상속받아서 페이지를 제작할 수 있다. 템플릿에서 내부에서 여러번 쓰이는 컴포넌트가 불편하다면 공통 컴포넌트를 만들어주면된다. 그러나 컴포넌트를 FE 프레임워크 레벨 정도로 관리하기는 쉽지 않다. 공통 컴포넌트를 관리하려면 프레임워크의 틀을 따라가야하는데 이 시점이 프론트엔드 프레임워크 선정을 할 타이밍이라고 생각한다. JS로 모든 것을 control한다는 것의 간결함 FE UI 프레임워크에서는 html로 작성한 class, id 명을 js에서 검색하여 따르기보다 js로 직접 동적으로 문서 객체를 생성한다. 참조하기도 간편하고 관리하기도 쉽다. js는 bom(부분적으로)과 dom을 컨트롤 할 수 있다. 결론 결국 아주 간결한 landing page 외에는 JS 기반 프레임워크를 사용해야한다. 나는 왜 바로 FE 프레임워크로 뛰어들지 않았나? 더 깊고 가파른 학습을 위해 컴퓨터공학이나 소프트웨어학과의 교육 커리큘럼도 그렇고 프레임워크 이...
Read more »