개발 일기

🔧 git commit --amend 가장 마지막 커밋을 수정하는 명령어 (가장 최근 커밋)커밋 메시지, 내용, 또는 둘 다를 덮어쓰기 방식으로 수정실수로 커밋 메시지를 잘못 썻거나, 파일을 빠뜨렸을 때 유용하다 📘 예시 1: 커밋 메시지만 수정 1. 기존 커밋 확인git log --oneline -1> e1a2b3c Fix login bug→ 실제로는 로그인 버그가 아니라 "로그인 UI 수정"이었을 때 2. 커밋 메시지 수정git commit --amend● 편집기가 열리면 메시지를 수정Fix login UI layout● 저장하고 종료하면 커밋 메시지가 업데이트된다. 📘 예시 2: 빠뜨린 파일을 추가하고 커밋 수정 1. 파일을 농친 경우git add missing-file.jsgit comm..

Nice To Have ● 커밋 재작성 ● 커밋 수정 및 스쿼싱 (결합) ● 커밋 삭제 rebase -i 명령어를 통해서 이미 존재하는 커밋 이력을 편집, 조작할 수 있다. reword, edit 등 수정사항이 여러개라면 각 커밋마다 작업을 순차적으로 해주어야 한다.변경 작업이 완료되면 커밋 해시가 바뀌게 된다. 즉, 작업 대상의 커밋들이 모두 재생성 되었다는 얘기이다.추가로 특정 브랜치를 지정하지 않고 현재 HEAD가 위치한 브랜치를 기점으로 리베이스를 하게된다. git rebase -i [commit-hash] pick : 커밋 유지reword : 커밋 유지. 단, 커밋 메시지만 재작성edit : 작업과 커밋 메시지 모두 재작성fixup : 이전 커밋과 병합. 단, 커밋 메시지는 병..

Important ● 리베이스와 병합의 차이 ● git rebase ● 리베이스를 쓰지 말아야 할 상황 * 리베이스?병합?협업 과정에서 각자 피처 브랜치를 이용해 작업하는것을 이제는 안다. 여기서 내 작업이 끝나기 전에 누군가의 작업물이 메인 브랜치에 올라간 경우 변경사항을 최신으로 유지하기 위해서 나의 피처 브랜치에 pull을 해야 할 것이다. 이 때 병합 커밋이 필연적으로 발생할텐데 이런 경우가 아주 빈번하게 발생한다면 나의 작업과는 관계없는 병합 커밋이 많이 생기게 되어서 이력이 지저분해 질 것이다.🔧 기본 사용법: git rebase git rebase main위 명령은 현재 브랜치의 커밋들을 main 브랜치 끝에 다시 적용한다.목표: feature 브랜치를 main의 최신 상..

Critical ● 중앙 집중형(단일 브랜치) 작업의 문제 ● 피처 브랜치의 워크플로우 ● 풀 리퀘스트(Pull Requests, PR) ● 포크(Forks) ● 포크와 클론의 워크플로우Important ● 브랜치 보호 규칙 중앙 집중형 워크 플로우에서는 모든 사람이 단일(주로 main) 브랜치에서 작업한다.원격 및 로컬 저장소에서 단일 브랜치를 사용한다면 협업에 큰 문제가 생길 수 있다. 예를 들어서 미완성된 작업물에 대해 도움을 받기 위해 공유를 위해서 push를 하게 되면 브랜치가 하나밖에 존재하지 않기 때문에 미완성된 작업물 그대로 브랜치에 커밋이 되어버린다. 이렇게 되면 모두가 미완성된 작업물을 가지게 되므로 아주 큰 문제가 발생한다. 브랜치가 단일로 존재하기 때..

Critical ● 공개 저장소와 비공개 저장소 ● 공동 작업자 추가하기Important ● README.mdNice to Have ● 마크다운 ● Github Gists, Github Pages 공개 저장소는 누구나 접근이 가능하다. 단, 저장소의 내용을 변경할 수 있는것은 아니다.비공개 저장소는 공동 작업자로 추가되어야만 접근할 수 있다. 공동 작업자로 추가된 사람은 변경 사항을 저장소에 푸시할 수 있게된다. * 깃허브 공동 작업자 추가 방법 * README.md프로젝트가 무슨 일을 하는지 설명하기 위한 마크다운 파일이다. 루트 폴더에 추가해두면 깃허브에서 내용을 렌더링해서 페이지에 보여준다.마크다운이란?형식화된 텍스트를 만드는 간결하고 편리한 구문이다.텍스트..

Critical ● 원격 추적 브랜치 ● git fetch/pull 협업을 하지 않고 로컬 저장소만 사용할 거라면 fetch, pull은 필요없다. 하지만 협업할 계획이라면 매우 중요하다. * 원격 추적 브랜치로컬에서의 브랜치는 앞서 다뤄봤으므로 익숙할 것이다. 하지만 clone이나 remote를 통해 원격 저장소와 동기화를 이루고 나면 "origin/main"과 같은 새로운 브랜치가 생성된다. 이 브랜치가 원격 추적 브랜치이다.마지막으로 원격 저장소와 통신한 시점을 기억하는 포인터라고 생각하면 된다. 추가로 커밋 후 git status 실행 시, 로컬에서만 작업했을 때와는 다른 메시지가 출력된다. "origin/main" 브랜치에 비해서 커밋 1개가 앞서있다는 얘기이다.앞서 말했듯이 원격..

Critical ● 깃허브가 하는 일 ● git clone ● 깃허브 등록 및 SSH 키 설정 ● 깃허브 저장소 만들기 ● 원격 작업 ● git push * Github 란?깃 저장소를 위한 호스팅 플랫폼이다.깃 허브에 등록한 저장소가 포트폴리오가 될 수 있다.최신 정보를 얻기에도 매우 유용하다. git clone 로컬에 없는 저장소를 가져온다.깃허브의 공개 저장소에 있는 것들은 모두 클론이 가능하다. 단, Push는 불가능하다.그리고 거의 대부분의 경우에 깃허브가 쓰일 뿐이지 깃허브만 가능한것이 아니다. git clone 명령어도 github와 관계가 없다. 깃허브 등록 및 SSH 키 설정 (Windows 기준) * 왜 SSH 키를 사용하는가?✅ 1. 보안 강화 ●..

Critical ● 커밋 체크아웃 ● 분리된 HEADImportant ● 변경사항 무시하기 ● git restore(복원)/reset(재설정)/revert(되돌리기) git checkout 명령어로 브랜치를 생성하거나 이동하는것 말고도 이전 커밋을 확인 할 수도 있다. git checkout HEAD를 해당 커밋으로 이동시킨다. 명령어 실행 시 HEAD가 분리된 상태라는 메시지가 출력된다.브랜치는 언제나 해당 브랜치의 최근 커밋을 가리키고 HEAD는 그 브랜치를 가리키게 된다. 일반적으로 HEAD는 커밋이 아닌 특정 브랜치를 참조하게 된다.하지만 해당 명령어를 통해서 HEAD가 특정 커밋을 참조하도록 바꾼다. 원래 브랜치를 참조하던것이 커밋을 참조하게 되었으므로 분리된 상태가 된 것..

Important ● 스태시의 기초 ● git stash save/popNice To Have ● git stash 적용 ● 스태시 삭제 ● 여러개의 스태시로 작업하기 스태시는 유용한 기능이지만 반드시 사용해야 하는 상황은 발생하지 않는다.대부분 save와 pop을 사용한다. 브랜치에서 작업을 하다가 완료되지 않은 상태라서 커밋을 하지 않고 다른 브랜치로 이동해야 하는 경우에는 상황에 따라 해당 작업이 이동하는 브랜치로 따라오거나 깃에서 브랜치를 이동하지 못하도록 막는(병합 커밋 발생 예상 시) 두 가지 옵션이 존재한다.이 때 스태시를 사용한다. git stash (=git stash save)커밋되지 않은 변경사항을 저장하고 변경사항들을 모두 초기화 시킨다.내용이 삭제되는것이..

Critical ● git diff 명령어 실행 결과 읽기 ● git diff 명령어의 기본적인 사용 방법Important ● 브랜치, 커밋, 특정 파일의 비교 ● git diff --stage git diff는 깃에서의 변경 사항들을 보여주는 명렁어이다.git status나 git log처럼 저장소에 아무런 영향을 미치지 않는 명령어이다.git diff스테이지에 등록되지 않은 작업 영역의 변경사항을 모두 나열한다.(아직 스테이지에 올라가지 않은 상태)(작업 영역 파일의 변경사항을 알려준다)(각 라인을 해석하면 위와 같다)a는 커밋된 파일, b는 작업 영역의 파일이다.git diff HEAD마지막 커밋이 실행된 이후의 변경사항을 모두 나열한다.마지막 커밋 이후 변경 사항을 스테이지에..