Razelo 기술노트

신입 개발자로 일할 경우 사내에서 접하게 되는 개발 문화가 있다. 규모에 따라 다를 수 있겠지만 개발자로 일하는 경우 애자일 문화, 스프린트 방식, 코드 리뷰, 개발 프로세스에 대한 회사만의 특유한 문화를 접하게 된다. 그에 대한 간략한 내용을 정리하고자 한다. 스프린트 일일 스크럼 회의 짧게 회의한다. 15분 ~ 20분 정도, 팀원들이 보여서 어디까지 했고 어제 무얼 했으며 오늘 뭘 했고 어떤 점이 문제인지 이야기한다. 스프린트 원칙 스프린트 기간 중에 서비스의 우선 순위를 바꿔선 안된다. 요구 사항이 생기면 진행 중인 스프린트 내에서의 변경을 해서는 안된다. 스프린트도 갑자기 종료될 수 있는데 이때는 어찌할 수 없는 상황에서만 종료되어야 한다. 스프린트는 정해진 시간 안에 끝내고 연속적으로 진행되어야..

간만에 도커를 실습하는 와중에 아래와 같은 에러를 마주했다. OCI runtime exec failed: exec failed: unable to start container process: exec: "ping": executable file not found in $PATH: unknown 내가 하고자 하는 명령어는 아래와 같았다. docker exec mysql ping findby docker exec findby ping mysql 즉 findby라는 컨테이너와 mysql이라는 컨테이너 사이에서 서로에게 핑을 보냄으로써 정상적으로 컨테이너가 살아있는 지 확인하기 위함이었다. 물론 당연히 떴으니 살아있겠지만 그냥 확인차 ping은 잘 날라가는 지 보고 싶었다. 근데 왜 위 오류가 발생했을까? 위 ..

오늘은 docker, dockerfile, docker compose, docker network에 대해서 알아보기로 한다. 협업에서 혹은 신입 개발자로 일하게 된다면 반드시 docker 혹은 가상화 기술에 대해 알고 있어야 한다. 그냥 업무 숙달의 일환이라고 생각하고 간단하게 살펴보자. 도커 공식문서: https://docs.docker.com/get-started/overview/ 가상화 기술이란? https://velog.io/@palza4dev/Docker%EC%99%80-%EA%B0%80%EC%83%81%ED%99%94-%EA%B8%B0%EC%88%A0 https://spidyweb.tistory.com/71 https://nomad-programmer.tistory.com/282 가상화는 물리..

협업을 제대로 해본 적이 없어서 협업 방식에 대해서 정리하고자 한다. 코드 리뷰도 제대로 해본 적이 없어서 협업 컨벤션이나 구체적인 루틴에 대한 이해가 필요할 것 같다. 간단하게 정리하고자 한다. https://backlog.com/git-tutorial/kr/ git 기본 명령어 정리 https://wecandev.tistory.com/152 인덱스(index): 커밋할 변경사항을 모아놓은 궁간임. 작업 폴더(work Tree)의 변경내용을 인덱스에 기록하는 것을 스테이지(Stage)라고 한다. 머지(Merge): 선택한 브랜치에 다른 브랜치에서 커밋한 내용을 병합하는 동작임. 컨플릭트(Conflict):동시에 같은 파일의 유사한 부분을 수정한 경우 발생하는 코드충돌을 의미하고 의도에 맞는 코드를 선택..

성공적인 git flow 모델이라고 하는 글이 있다. 개념 잡기에 좋은 글이다. https://nvie.com/posts/a-successful-git-branching-model/ A successful Git branching model In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful. nvie.com

https://analytics4everything.tistory.com/213 [5분 컷 이해] Docker 설치 및 사용, Dockerfile, Docker image 설명 요약 Docker을 이해하기위해서는 아래의 도커관련된 개념들의 이해가 필요하다. * 도커이미지? 도커 이미지는 도커에서 필요한 서버 프로그램 + 소스코드 + 실행 파일로, 프로그램을 구동하기위한 analytics4everything.tistory.com

아래와 같이 조금 더 디테일하게 적어줄 수 있을 것 같다. 이전에는 feat, docs, style, chore 등은 쓴 적이 없고 Delete, Add, Fix, Test와 같은 type만 적어줬는데 아래 처럼 feat, docs, refactor 등을 활용할 수 있을 것 같다. 이모지로 표현하는건 개인적으론 별로 좋지 않은것 같다. 근데 이건 그냥 개인 취향이라 하고 싶은 사람은 팀에서 잘 논의해서 결정하면 될 것 같다. 아래 양식 정도만 따르면 큰 문제는 없을 것 같다. feat : 새로운 기능 추가 fix : 버그 수정 docs : 문서 수정 style : 코드 포맷팅, 세미콜론 누락, 코드 변경이 없는 경우 refactor : 코드 리펙토링 test : 테스트 코드, 리펙토링 테스트 코드 추가 ..

아래와 같은 명령어를 입력한다. git config --global init.defaultBranch 이후에 아래 명령어를 통해 바뀐 default branch name을 확인할 수 있다. git config --global init.defaultBranch 아래와 같이 보여질 것이다. 참고로 원격에 있는 github 에서도 default branch 를 변경할 수 있다. 굳이 하지 않긴 하는데 방법은 아래와 같다. settings -> 좌측 메뉴에서 branchs 선택 -> Default branch 에서 switch to another branch 선택 -> 변경

최근 실습때문에 Hyper-v 를 on으로 바꿀 일이 있었는데 이후에 코딩을 하던 중 git push origin main이 먹히질 않는 문제를 발견했다. 보기에는 단순히 로그인 access가 만료되었다고 떠서 다시 로그인하면 될 것 같은데 사실 문제는 그게 아니다. Hyper-v를 켜둬서 문제가 생긴거다. 왜 Hyper-v가 영향을 준건진 모르겠지만 방금 확실하게 테스트해본 결과 Hyper-v를 켜두면 git push 가 안먹히고 Hyper-v를 꺼두니 이제서야 git push 가 잘 먹힌다. 어떤 연관관계가 있을까. 지금은 모르겠다. 확실한건 도커든 뭐든 간에 뭘쓰다가 이상하다 싶으면 혹시 며칠전에 Hyper-v 관련해서 작업해본 적이 있었는지 떠올려보면 될 것 같다.

private repository 에서 작업하면서 인증키를 등록해놓은 상태여서 push 하는데 문제가 없었다. 다만 문제는 근 몇주간 클라우드 세팅때문에 코드 작업을 거의 진행하지 못했는데 갑작스레 인증키가 invalid 하다는 에러가 떠서 push 가 되지 않았다. 우선 아래와 같은 명령어를 입력해주자. $ ssh-keygen 이후 passphare 등을 묻지만 그냥 엔터로 입력하고 지나가도 무방하다. 그리고 나서 키가 생성되는 위치와 함께 키 생성이 완료됬음을 알 수 있다. 그리고 cat 명령어를 통해 id_rsa.pub 키를 알아낸다. 자 이제 이 pub 키를 github 에 가서 등록해줘야지만 private repository 에 push 를 할 수 있다. 그리고 이후 아래와 같은 과정을 거쳐서 ..

주말에 읽어보자구요 ~ https://tech.ktcloud.com/84?category=465864 도커를 공부하는 초보자를 위한 안내서 5편 - 도커 설치 및 명령어 실습 도커(Docker) 기초 다지기 - 도커 명령어 및 실습 앞선 포스트를 통해 도커가 무엇인지 공부했으니, 이제 실전에 돌입할 차례입니다. 도커 설치부터 핵심적인 명령어까지 실습을 통해 차근차근 알 tech.ktcloud.com

저번에 프로젝트 하다가 충돌나서 그지점부터 로그 전부다 잃어버리고 고생꽤했던 기억이 있는데 기말고사 끝나면 이 영상으로 내용 좀 확실하게 알아놔야겠다. (참고로 복구못함 ㅠ) https://www.youtube.com/watch?v=wVUnsTsRQ3g

오늘 프론트 팀에서 api 하나를 추가하달라고 하셔서 잠깐 이것저것 만지고 있었다. 오랜만에 들어와서 만지는거라 잠깐 어색한 순간에 에러가 나는 것을 그냥 --force로 눌러버렸다. (솔직히 말하면 살짝 귀찮았다. 근데 대가가 너무 참혹했다.) git push -u --force origin main 문제없겠지하고 깃허브에서 리포를 살피는데 이런... 커밋 히스토리가 모두 날라갔다. 엥 왜 1커밋이 있지? 하고 살폈는데 이전 기록이 모두 사라졌다. 사실 예전에도 이런 경우가 한번 있었다. 170 커밋정도가 있었는데 정말 말 그대로 시원하게 싹 날렸었다. 아마 세달전이었던 것 같다. (근데 그때는 사실 혼자 작업하는 기간이어서 크게 문제가 되진 않는다고 생각하고 계속 진행했었다. ) 그런데 이번에는 팀원..

왜 언제가부터인가 .gitignore가 적용되지 않는다는 사실을 발견했다. 현재 프로젝트를 진행하면서 yml 파일을 제외시키려고 사용하고 있었는데 갑자기 안된다. 브랜치들을 살펴보니 그리 오래된것 같지는 않았고 커밋 서너번 전부터 이런 현상이 나타났던 것 같다. 해결법은 간단하다. git의 캐시문제라고 한다. git bash 에서 아래와 같은 명령어를 친다. (마지막에 점 찍는거 빼먹으지 마시구) 들고있던 캐시 전부 비워주자. git rm -r --cached . 그 다음은 하던대로 똑같이 진행해주면 된다. git add -A git commit -m "removed git cach" 뭐 이런 식으로 하던대로 진행되면 된다.

git init git branch -m main git remote add origin "github.com/your_ropo.git" git add . git commit -m "first commit" git push -u origin main 만약 git push -u origin main 에서 error: failed to push some refs 에러가 발생한다면 git push -f origin main 을 실행

유용하게 쓸 수 있는 깃 컨벤션을 정리해놓았다. 우리 팀에서 쓰던 건데 팀원분께서 친절히 정리해서 올려주셨다. 기왕이면 지켜서 쓰자. 🧬 Git Branch Convention 형태 : 이름/기능이름_날짜 1️⃣ 각 단어 전부 소문자 - E.g. nickname/signin 2️⃣ 한 기능을 자주 수정해야 할 때 날짜 붙이기(날짜 양식 : YYMMDD) - E.g. nickname/signin_211125 📝 Git Commit Convention 형태 : 커밋타입: 커밋 메시지 - E.g. Add: 카카오 로그인 구현 커밋 타입 리스트 - Add: 기능 추가 - Fix: 코드 수정 ❗️ 잘못된 코드 수정 - Delete: 기능 삭제 - Refactor: 코드 리팩토링 ❗️ 잘 되어있는 코드 수정 - T..

1. git checkout // 변경할 branch로 checkout 2. git branch -m // 새로운 이름으로 local branch의 이름을 바꿈 3. git push origin -u // 새로운 이름으로 된 branch 를 remote에 push 4. git push origin --delete // 변경 전 branch 를 remote에서 삭제