xtring.dev

git을 사용하기 위해 git init을 실행하면 자동으로 생성되는 .gitignore 파일이 있습니다. 예측하기로, git 버전 관리를 하는데 있어 git에서 업로드하지 않을 파일 목록을 지정한다고만 알고 있었습니다. .gitignore 파일이란? git 버전관리에서 제외(Github에 업로드하지않을 파일 목록)할 파일 목록을 지정하는 파일 .gitignore이 파일명이며, 해당 파일 목록에 들어가는 대표적인 것은 node_modules가 있습니다. node_modules에 대한 정보는 package.json 안에 명시되어 있기 때문에 해당 module이 없더라도 npm i[install]를 실행시키면 node_modules 안에 생성됩니다. 따라서 node_modules를 굳이 github에 올리지 ..

회사에서 관리하는 Remote Repository는 이전에 GitLab에서 관리되어지고 있다가 서버 개발자 분께서 자동 배포기능을 만들기 위해 GitHub로 프로젝트를 이관하면 어떻겠냐는 제한을 했습니다. 그런데 이전 commit log를 모두 날려버린다면 너무 아깝기도 하고 작성했던 코드도 모두 날리게 되어 쉽게 실행하지 못하던 와중에 좋은 방법을 찾게 되었습니다. Repository 미러링 1. open terminal 2. 복사하고자 하는 저장소(GitLab)의 bare clone을 생성 git clone --bare https://gitlab.com/user_id/old-repo.git 3. 새로운 저장소(GitHub)를 만들고 mirror-push를 진행합니다. cd old-repo.git gi..

Git을 왜 사용해야하지? 개발자라면 어느 누구나 'Git'에 대해서 들어 보셨을 거에요! 'Git을 통해 협업을 한다.', '버전 관리를 하기 위해서 Git을 사용한다.' 이런 말을 흘려들어서 라도 들어봤을거에요. 맞습니다. Git은 다수의 사람들과 협업하고 공유하고 관리하기 위해 사용하는 분산 버전관리 시스템입니다. 두 명의 개발자가 하나의 서비스를 효율적으로 합치고 비교하고 관리하기 위해서는 필수적으로 필요한 것이 Git입니다! 지금부터 Git에 대해서 알아 보겠습니다. Git에 대해 더 이해해봅시다. 코딩을 할 때 단순히 Command + z(ctrl + z)를 눌러 이전 상태로 되돌린다면 어떤 시점에 어떤 것들이 바뀌었는지 모두 기억하기 어렵습니다. Git은 이 시점들을 원하는 시점마다 버전을 ..

Git, Github, branch 자주 사용하는 커맨드 정리 Git, Github, branch 자주 사용하는 커맨드 정리 : 네이버 블로그 13 Git Commands Every Developer Should Know Git을 처음 알게 되면 '버전관리가 왜 필요하지?', '너무 복잡해...'와 같은 생각을 하시는 분들이 많을 거에요. 저도 마찬가지로 Git을 처음 사용하기 시작했을 때는 정확히 어떻게 사용하고 왜 사용해야하는지 몰랐어요. 오히려 프로젝트를 진행하는데 관리차원에서 복잡해서 힘들다는 생각을 했었죠. 그땐 너무 모르고 있었죠...⭐️ Git을 사용했을 때 장점은 코드에 대한 히스토리를 남겨 버전을 관리하고 다수의 인원이 협업하는 코드를 관리할 수 있게 해줍니다..

탐욕 알고리즘. 그리디 알고리즘(Greedy Algorithm)이라고도 불리는 알고리즘에 대해서 알아보겠습니다.(이하 그리디 알고리즘이라고 부름) 그리디 알고리즘은 동적 프로그래밍(Dynamic Programming) 사용 시 지나치게 많은 처리를 한다는 것에 착안하여 고안된 알고리즘입니다. 동적 프로그래밍과 함께 상호보완하는 개념입니다. 그리디(탐욕) 알고리즘이라는 이름이 붙게 된 이유는 '미래를 생각하지 않고 각 단계에서 가장 최선의 선택을 하는 기법'이기 때문에 지어졌다고 합니다. 각 단계에서 최선의 선택을 하는 것이 결국 전체의 최선이길 바라는 알고리즘이죠. 모든 경우에서 그리디 알고리즘이 최대 효율을 만들어주지는 못합니다. 쉬운 예로 마시멜로 이야기와 함께 해보겠습니다. 지금 마시멜로우를 앞에 ..

postmortem : an analysis or review of a finished event postmortem은 '사후처리'라는 의미를 가지고 있습니다. 이는 SW 프로젝트에서 서비스의 문제가 생겨 서비스가 중단되는 경우 이에 대한 처리를 하는 것을 의미한다. 이를 실행하는 방법은 문제를 해결한 뒤 postmortem meeting을 통해 1) 근본적인 문제가 무엇이었는지(root causes) 2) 이 일로 무엇을 배웠는지(lessons learned) 3) 해결하는 과정이 적절했는지 등등을 점검한다. 이런 절차를 가지는 이유는 서비스 관리, 결과에 대한 책임을 묻는 것이 아닌 더 나은 서비스, 문제에 대한 방지책을 만들기 위한 프로세스를 구축하기 위함이다. 사건에 대한 비판적인 분석을 통해 더..