일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- Express
- Push
- MongoDB
- 네이티브
- navigation
- scope
- JavaScript
- 자바스크립트
- 리액트
- Python
- JS
- 카카오
- Background
- graphql
- github
- 변수
- Notification
- 알림
- 면접
- 디자인
- 배포
- 후기
- AWS
- 네비게이션
- ubuntu
- 스코프
- EC2
- React
- 레이아웃
- NATIVE
- Today
- Total
목록Git (2)
어서와, 개발은 처음이지?

개요 git blame 명령어를 사용하면 라인별로 누가 어떤 커밋을 남겼는지 히스토리를 볼 수 있는데, vscode에서 git lens를 사용하면 git blame 기능을 쉽게 사용할 수 있습니다. 이 기능을 사용하면 개발중에 history를 추적하기 좋은데, 최근에 prettier rule을 바꾸면서 전체적으로 code style을 변경하게 되었습니다. 이로인해 아래 이미지처럼 수많은 diff가 생겨나게됐는데요. (왼쪽 노란 부분이 다 diff!) 사실 이런 코드 스타일 규칙 일괄변경 사항은 개발 시 큰 관심사가 아닌 내용인데, 이 변경 사항으로 히스토리가 오염(?)되고 기존 커밋이 가려져서 확인하기 번거롭게 만드는 불편함이 생겼습니다. 이번 글에서는 blame 시 이런 불필요한 커밋 히스토리를 가리..
최근에 시간적 여유가 생겨서 개발 외에 다른 사항에도 투자할 시간이 생겼습니다. 그에 따라 이번에는 node 프로젝트의 배포 프로세스를 구성하는 과정을 기록하고자합니다. 1. 개요 오픈소스가 등장하고, IT 업계의 생태계 규모, 성숙도, 접근성이 높아지면서 바야흐로 협업의 시대가 도래했습니다. 그에 따라 컨벤션, 테스트 코드 등의 개발 요소에 대한 중요성도 높아지게 됐는데, 아직도 통상 '귀찮다' 라는 이유로 마음 한 구석의 불편함을 무시한 채 잠재적 기술 부채를 키워가는 사람들이 많고, 저 또한 그랬습니다. 하지만 고맙게도, 우리는 협업 단계에서 이런 중요한 요소들을 지킬 수 있는 환경을 형상관리 도구를 사용하여 쉽게 구축할 수 있습니다. 지금부터 git 환경에서 이런 사항들을 자동으로 검증할 수 있는..