일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
31 |
- 피그마
- Taillwind
- Stack
- hook
- express
- Javascript
- grid
- CSS
- useCallback
- FigJam
- TypeScript
- axios
- useMemo
- SSR
- docker
- webpack
- 프로그래머스
- 코딩테스트
- TAILWIND
- 자료구조
- EC2
- render
- Next.js
- github
- HTML
- FIGMA
- git
- react
- Babel
- 해시
- Today
- Total
목록2023/12 (20)
나는 오늘도 멋있다
이전 글에서는 Home component를 다루는 page.tsx에서 nav의 기능을 다루도록 하였다. 하지만 나의 프로젝트 특성상 nav기능은 모든페이지에서 적용되므로 다시 Layout.tsx에서 그리도록 변경하였다. next.js의 파일구조를 명확하게 파악하지 못하여 발생한일이다. 사진과 보다시피 사이드에서 nav가 위치하고 있고 모든 내용들이 가운데에서 렌더링 되도록 하려는 구조였다. next.js 페이지 단위로 로드가 이루어진다는 생각에 메인 page.tsx에 nav기능을 넣은거 였다. 코드는 변경된것이 없다. 다만 코드의 위치변경을 해주었다. 이러한 점은 Login창을 구현하려할때 발견하였다. 기본적으로 유지되어야하는 Layout이 적용되지 않아서 알게 되었다. 아마 React의 영향이 아닌가 ..
1. 로컬브랜치 확인하기 git branch 2. 로컬브랜치 삭제하기 // git branch -d git branch -d yellow 3. merge되지 않은 로컬 브랜치 강제 삭제하기 //git branch -D git branch -D yellow 1. 원격브랜치 확인하기 git branch -r 2. 원격브랜치 삭제하기 // git push origin -d git push origin -d yellow
1. 로컬에서 변경할 브랜치 확인하기 git branch 2. 로컬 브랜치명 변경하기 // git branch -m [original_branch] [new_branch] git branch -m oldbracnh youngbranch 3. 변경된 로컬 브랜치명 확인하기 git branch 4. 원격 저장소에 반영하기 // git push origin :original_branch new_branch git push origin :oldbracnh youngbranch 5. 변경한 브랜치로 이동한후 기존에 가리키던 원격 브랜치경로 삭제 git branch --unset-upstream 6. 변경된 브랜치와 원격브랜치 맞춰주기 //git push --set-upstream origin git push --..
상황(강제로 진행하는거기 때문에 개인프로젝트 할경우만 사용 !비추천) sub브랜치에서 하나의 기능을 완성한후에 main 브랜치로 merge를 했다. 이후 sub브랜치에서 조금한 수정사항이 생겨서 변경후에 기존 merge를 취소하고 다시 merge하려 한다. 1. main 브랜치로 이동 // git switch git switch main 2. 로컬 과 원격 저장소의 main 브랜치 상태를 맞춰준다 // (HEAD->main) // git pull origin git pull origin main 3. 병합전 commit 해시를 확인 // git의 참조 이동과 관련된 로그를 확인함 git reflog 4. 돌아갈 commit 을 입력하여 상태돌리기 // git reset --hard git reset --..
4 ~ 8 일사이에 많은 일들이 있었다. 당연히 아르바이트 때문에 조금만 작업한 날도 있었지만.... Tailwind가 속을 썩있는 바람에... css 프레임워크는 처음써본다. 기본적으로 React에서는 styled-component를 사용했었고, css파일에 클래스를 정의하여 사용도 해봤다. 그래서 그런지 가독성이 떨어지는 부분이 있긴하다. 또한 유틸리스 클래스를 모르니 공식홈페이지를 보면서 적용하는것도 시간이 들어갔다. 초기작업이라 기본적인 css설정을 해놓고 추가로 설정들을 넣어볼예정이다. 태그 초기화는 할게 많지만 그때그때 필요한 부분만 하는게 좋을것같아서 아직 다하지는 않았다. router-button 클래스는 기본적으로 페이지를 이동하는 Link 태그의 css인데 많이 사용할거 같아 따로 빼두..
@tailwind base; - Tailwind css에서 기본 스타일을 주입하는 부분으로, 기본 스타일 및 글로벌 스타일을 정의하는 부분 - ex) 기본태그들의 초기화 or 프로젝트 전체적으로 사용될 css등(font 등) @tailwind components; - Tailwind css에서 컴포넌트 클래스를 주입하는 부분으로, 컴포넌트 단위의 스타일을 정하는 역할 - ex) 버튼,모달,카드 등의 UI컴포넌트 관련 @tailwind utilities; - Tailwind css의 다양한 유틸리스 클래스를 사용하기 위한 역할 - ex) 레이아웃, 텍스트, 색상, 간격 등 @tailwind variants; - Tailwind css의 가상클래스를 쓰기 위한 역할 우선순위는 utilities > compo..
학습계기 Css파일에 클래스를 정의해서 사용하는 기본사용법, React의 styled-component등 사용해 봤다. 하지만 사용하다보면 이것 또한 불편하다. 그래서 Css 프레임워크를 찾아보다가 Tailwind를 접하게되었고, 많은기업에서도 사용하는 거 같아서 요번 프로젝트에 도입하기위함 tailwind는 Utility-First 컨셉을 가진 css의 프레임워크 이다. [장점] 1. Utility-First 컨셉으로 빠르게 원하는 디자인 개발을 할 수 있다. 2. 클래스 작명을 고민할 필요가 없다. 3. HTML-CSS를 왔다갔다 할 필요가 없다. 4. 클래스명의 속성을 변경하기위해 CSS파일에서 클래스를 찾을 필요가 없다. 5. 기본 스타일 값을 자유롭게 커스텀 6. 반응형 디자인에 유용한 클래스들..
ERD를 작성한 후 github를 좀더 깔끔하게 관리해보려고 다른 프로젝트를 참고했다. 1. Labels 설정하기 2. issues Template 협업시에는 issues를 잘활용 하는것 같다. issues는 기획, 작업, 개선사항, 버그수정, 추가될 기능등 여러가지를 포함하여 이슈를 등록하고 해당 이슈를 기반으로 작업을 진행하는 것 같다. 위처럼 label을 설정하고 이슈 템플릿을 설정해놓으면 해당처럼 바로 작성할수있고 라벨을 설정할수있다. Projects는 칸반보드로 해놓고 쓰긴하는데 issues를 한눈에 볼수있기도하다. milestone은 아직 쓸생각은 없다. branch와 issues만 잘이용해도 git을 깔끔하게 관리할수 있을것 같다. 노력하자