프론트엔드 첫걸음

그림자 DOM 확인하기 1. 그림자 DOM 표시 설정 그러면 크롬 개발자도구에서 input 요소 내부의 shadow dom 을 확인할 수 있다. type:file인 input 태그는 type:button인 input 태그 + span 태그 가 합쳐진 형태다. 이 숨겨진 돔을 찾아서 "파일선택" 버튼에 스타일을 입힐 수 있다. 나만몰랐냐구

:: Pseudo-element 의 사용 :hover, :focus, :active 등 Pseudo-class 는 해당 요소가 '다른 상태일때' 다른 스타일을 적용할 때 사용 ::first-letter, ::first-line ,::after,::before등 Pseudo-element는 해당 요소의 '일부분' 에 다른 스타일을 적용할 때 사용 변하는 데이터가 들어있는 요소에서 첫 번째 글자만 스타일링 해야하는 경우, 자바스크립트를 사용하지 않아도 된다. 예 ) clear : both 박스 float:left 적용한 박스 아래에 clear: both라고 적힌 빈 div 박스를 만들어 줄 때 (다른 기능없이 clear:both 기능만 하는 div박스를 html로 만드는 대신) pseudo-element로 ..

최초로 깃 레파지토리를 만들면 아래와 같은 설명을 볼 수 있다. 여기서 -u 라는 설정은 무엇일까? -u 는 로컬브랜치와 원격 브랜치를 연결하는 upstream 의 -u 이다. 처음으로 로컬브랜치를 원격브랜치에 푸시할 때 로컬브랜치와 원격 브랜치를 연결하려고 -u 옵션을 사용한다. 예를 들어 새 브랜치 tmpbranch 를 로컬에서 만들고, git push origin tmpbranch 로 깃허브에 새 tmpbranch 브랜치를 만든다. 그 다음에 변경사항을 커밋한 다음 git push 하면 아래와 같은 에러메시지가 뜬다. 업스트립이 설정안되어 있다는 뜻이다. 그러니까 로컬의 tmpbranch와 원격의 tmpbranch가 연결이 안되어있다는 의미이다. 한번 git push -u origin tmpbran..

변경사항을 원격에 반영 , push 할 때 브랜치를 선택하여 push할 수 있다. git push [원격명] [branch명] 로컬의 브랜치를 깃허브의 브랜치로 push 한다. git push origin master 는 로컬의 마스터브랜치를 깃허브의 마스터 브랜치에 push한다는 뜻이다. 깃 레파지토리를 만들어서 최초로 git add origin master [원격url] 하는 명령은 원격 url을 지정하면서 동시에 깃허브에 master 브랜치를 생성하는 명령이다. (존재하지 않는 브랜치에 push하면 원격저장소에 브랜치가 생성되면서 push된다.) git push [원격명] [로컬 branch명]:[원격 branch명] 브랜치 명 하나만 쓰면 해당 이름의 로컬브랜치에서 원격브랜치로 push하는데, 로..

remote 깃에게 알려줄 목적지 url git remote -v 현재 저장소에 있는 원격(목적지 url)을 나열해서 보여준다. git remote add origin [url 주소] 원격이 없는 경우 새로운 깃 리파지토리를 만들어서 내 로컬저장소에 원격을 지정하는데, 이 원격(목적 url)의 이름은 origin으로 한다. "깃 , 여기있는 url을 origin이라는 이름으로 원격저장소로 정할게" origin이란 이름은 master(or main) 처럼 관행적인 이름이고, 바꿀 수 있다. git remote rename [기존원격명] [바꾸고싶은 원격명]

https://docs.github.com/en/authentication/connecting-to-github-with-ssh Connecting to GitHub with SSH - GitHub Docs Secure your account with 2FA docs.github.com 여기 나온 순서대로 하면 되는 생각보다 쉬운과정인데... 에러가 안난게 이상해서 성공한게 기뻐서 기록하는것.. 1. SSH 정보란? SSH 키를 사용하면 방문할 때마다 사용자 이름과 개인 액세스 토큰을 제공하지 않고도 GitHub에 연결할 수 있다. 2. 기존 키 확인 터미널에 아래 명령어 입력 ls -al ~/.ssh id_rsa.pub id_ecdsa.pub id_ed25519.pub 셋 중 하나가 없으면 새 SSH키..

git repository를 내 로컬에 복사해오는 명령 git clone [url] git clone하면 새로운 폴더가 생기고 그 폴더 안에 초기화된 깃 저장소가 들어있다. 해당 깃 저장소에서 git status, git log 명령어 사용할 수 있다. (그것이 바로 깃 저장소니까..) "Make sure you are not inside of a repo when you clone" 로컬에서 작업하는 기존의 git repository 안에서 git clone을 하지 말라는 뜻 같음..

해당 코드펜 링크의 로고를 클릭하면 코드펜에서 콘솔에 찍히는 결과를 확인할 수 있다. 이벤트버블링이 발생하는 코드 See the Pen Untitled by JEONG (@cona) on CodePen. 👍 을 클릭하면 "like it"을 , title을 클릭하면 "title" 을 콘솔에 찍게 했을때 title을 클릭하면 title만 찍히지만, 👍을 클릭했을 때는 like 와 title이 두번씩 찍힌다. 이 때 내가 유도하지 않은 title 이벤트의 target이 title클릭 했을 때의 target과 다르다는 점에 주목하자! 이는 이벤트 버블링 때문이다. (자식요소 클릭했을때 이벤트 버블링이 일어나서 상위요소의 이벤트를 발생시키는 효과가 일어났다. 이벤트버블링에 의한 이벤트 발생 시 currentTar..

git log --oneline 을 보고 되돌아갈 해시를 복사한 후 git reset [돌아갈 곳의 해시] 하면 커밋이 취소된다. 그러나 워킹디렉토리에는 작업물이 남아있는 상태이다. 만약 워킹디렉토리의 작업물을 삭제하고싶으면 git reset --hard [해시번호] 사용하면 된다 또는 git reset --hard HEAD~1 사용해도 된다. 그러나 git reset은 내 커밋을 없애버려서 협업하는 사람들에게 혼동을 준다. 이미 커밋되어 공유된 코드를 내가 바꿔버리는 명령어이기 때문에 위험하다. git revert가 안정적이다. 나 혼자 작업할 때 마지막 커밋을 취소하고 싶다면 // [방법 1] commit을 취소하고 해당 파일들은 staged 상태로 워킹 디렉터리에 보존 $ git reset --so..

잘못 커밋한게 있으면 그 잘못커밋한것을 복구할때 git revert [잘못된 커밋의 해시] 그러면 Revert "make a bad commit" 란 커밋메시지가 적히면서 커밋되는데, reset은 내가 커밋한 사항을 아예 없앰으로써 내가 이미 커밋한 코드를 받아 작업하는 동료들의 코드에 혼동을 줄 수 있는데 반해(코드가 꼬일 수 있다) revert는 잘못된 코드를 취소하는 새 커밋을 만드는 것이라 더 안정적이다. +) revert와 reset을 사용할 때 reset은 이전 커밋을 없앨꺼니까 없애고 나서 마지막이 될 커밋의 해시(마지막 성공 커밋 해시)를 적어주고, revert는 '나 이거 잘못한 커밋이야' 하는거니까 잘못 커밋한 해시를 적어준다.