일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- vite
- alias설정
- 화살표2개
- useQueryClient
- 서초구보건소 #무료CPR교육
- 문제해결
- 조건부스타일
- tailwindCSS
- parent padding
- createPortal
- ignore padding
- CustomHook
- QueryClient
- 리액트
- 제어컴포넌트
- twoarrow
- react
- 부모요소의 패딩 무시
- es6
- DOM
- 이즐 #ezl #욕나오는 #교통카드
- Carousel
- ?? #null병합연산자
- 함수형프로그래밍
- BlockFormattingContext
- transition
- debouncing
- 부모패딩
- BFC
- accordian
- Today
- Total
목록개발 공부/Git (26)
프론트엔드 첫걸음

git restore --staged [파일명] git add . 로 수정한 파일 모두를 스테이지에 올렸다. 그런데 스테이지에 올린 파일 중에 내가 스테이지에서 올리고 싶지 않은 파일이 포함되어있는 것을 확인했다. 이 때 git restore --staged [파일명] 사용하면 된다. 명령어 수행 후 git status 로 확인하면 해당 파일은 untracked files에 포함되어있는 것을 확인할 수 있다. * git status 했을 때 스테이지에 올라간 파일은 git restore --statged 명령어 통해 스테이지에서 내릴 수 있다고 쓰여있다.
git restore --source HEAD~1 [파일명] 1단계 전 커밋으로 돌린다. 현재 파일의 커밋되지 않은 변화는 사라진다. 이 때 HEAD는 여전히 가장 최근 커밋에 있고, 다시 가장 최근의 소스로 돌리고 싶으면 git restore [파일명] 하면된다. ex) a.txt 와 b.txt를 3개의 커밋 전으로 돌리고 싶다. git restore --source HEAD~3 a.txt b.txt

git checkout HEAD [파일명] 마지막 커밋 이후 a.txt 파일과 b.txt 파일을 수정했다. 그런데 a.txt 파일의 코드가 엉망이라 그냥 마지막 커밋지점으로 되돌리고 싶다. 이때 git checkout HEAD a.txt 를 사용하면 a.txt만 마지막 커밋의 코드로 되돌릴 수 있다. 또는 git checkout -- a.txt 를 사용할 수 있다. (HEAD대신 -- 사용) git restore [파일명] git checkout이 여러 기능을 하는 상태에서 git switch와 git restore가 도입되어 git checkout의 기능을 일부 대신하게 되었다. git checkout HEAD a.txt 대신 git restore a.txt 사용할 수 있다. 파일을 수정하고 git s..
git checkout HEAD~1 헤드에서 1개 이전커밋을 참조(확인)한다 git checkout HEAD~2 헤드에서 2개 이전커밋을 참조한다 git checkout HEAD~1 두번한 것과 같은 결과. git switch - 분리된 HEAD를 떠나 다시 가장 최근에 있던 브랜치로 돌아가고 싶을 때 사용한다. (내가 있던 브랜치 기억 안날때 사용한다. 기억이 나면 git switch [브랜치명] 사용하면 된다.)
git switch [브랜치명] git switch는 HEAD가 참조하는 브랜치를 바꾼다. HEAD가 참조하는 브랜치를 변경한다. git checkout [commit-해시] HEAD가 해당 커밋을 직접 가리키도록 한다. git checkout [해시] 명령하면 HEAD가 특정 커밋을 참조하게 된다. (detached HEAD) cat .git/HEAD 하면 git switch때 특정 브랜치를 참조하던 HEAD가 해시코드를 저장하고 있음을 볼 수 있다. git checkout를 통해 특정 브랜치의 특정 커밋상태의 코드를 확인할 수 있다.
Git Stash가 필요한 이유 Git Stash 는 새로운 브랜치에서 저장하기 전에 다른 브랜치로 이동할 때 사용한다. 공식적으로 커밋하고 싶진 않은데 다른 브랜치로 이동해야 할 때 사용 수정한 것을 커밋하지 않은 채로 다른 브랜치로 이동하려고 하면 아래와 같은 에러메시지 발생하고, 다른 브랜치로 이동하지 않는다. error: Your local changes to the following files would be overwritten by checkout: [내가 수정한 파일위치] Please commit your changes or stash them before you switch branches. Aborting 이 때 git stash를 사용한다. git stash 로 현재 브랜치의 작업을 ..

git diff Staging Area에 등록되지 않은 Working Directory의 모든 변경사항을 보여주고 Working Directory와 Staging Area 비교 git diff --staged git diff --cached 스테이지에 등록된 변경사항만 보여줌 git diff HEAD HEAD가 가리키는 최신 커밋과 Working Directory간의 차이를 보여줌 ex) test.txt 수정 후 add text.txt 로 수정된 부분을 스테이지에 올림 git diff시 스테이지와 워킹디렉토리 비교하므로 다른 점이 없음 (워킹디렉토리를 스테이지에 올려서) git diff HEAD했을 때에는 HEAD가 가리키는 최신커밋과 워킹디렉토리 비교하므로 수정된 부분이 보여진다. git diff [기..
Fast-forward merge란? main 브랜치에서 따로 브랜치로 생성한 version2 브랜치에서 커밋을 여러개 했다. version2가 마음에 들어서 main브랜치 쪽으로 병합시키려고 할 때 ( main 에서는 따로 커밋한게 없을때 ) main은 version2의 커밋들을 따라잡기만 하면 된다. 이를 fast-forward 병합이라고 한다. Fast-forward merge 수행방법 1. git switch [병합 주체 브랜치명] git switch main (main브랜치쪽으로 땡겨오는 거니까) 브랜치의 HEAD는 main을 가리키고 있어야한다. 2. git merge [병합 대상 브랜치명] git merge version2 main 브랜치 쪽에 version2를 가져와 병합한다.
git add와 commit 동시에 하는 명령어 git commit -a -m "커밋메시지" (a와 m 순서 바꾸면 안되더라)