GIT ‘REBASE’ 명령어
Git의 rebase 명령어는 기본적으로 한 브랜치의 변경 사항을 다른 브랜치에 적용하는데 사용된다. 이 과정은 브랜치의 기반점 (base)를 변경하는 것과 유사하여 rebase라고 불린다. rebase의 주 목적은 프로젝트의 커밋 히스토리를 깔끔하게 유지하는 것이다.
•
기본 원리 :
rebase는 특정 브랜치에서 시작된 커밋들을 새로운 기반점으로 옮긴다. 이 과정에서 커밋들이 새로운 기반위에 다시 적용, 재생성된다.
•
커밋 히스토리 정리 :
rebase를 사용하면 커밋 히스토리를 선형으로 만들 수 있어, 변경 사항을 추적하기 쉽다.
•
병합(Merge)과의 차이점 :
병합은 두 브랜치의 커밋 히스토리를 모두 유지하는 반면, rebase는 커밋 히스토리를 하나의 선형으로 재배열한다.
•
워킹 디렉토리 → 변경 사항 적용되기 전의 파일들
•
변경사항이 저장될려면 앱으로 들어가야된다.
•
인덱스는 변경사항이 적용된 코드공간
•
깃에서 파일추적은 add. → 사진 찍기
•
첫번째 화면 ⇒창문을 여는 것
◦
깃이 관리하는 폴더는 한 폴더당 하나, 하위 트리구조 만들면 안된다.
•
최초의 환경 세팅시!
◦
git init
◦
git add .
◦
git commit -m "환경세팅"
◦
까지 해줘야 된다. 기본!
•
작업영역
◦
하나더 생기면 변경감지 (인덱스를보고 판단)
•
인덱스
◦
폴더라 하지 않고 트리라 그런다.
◦
add 하면 박스가 생긴다. 트리라고 한다.
◦
내용을 변경하면 추가 박스가 생김. 이젠 내용은 참조로 포함한다.
•
헤더
◦
헤더에 줄이 생기면서 Master브랜치가 생김.
◦
포인터를 옮김
▪
헤더를 옮기면 변경된 라지박스는 버려진다. 해당 인덱스를 가지고 워킹 디렉토리를 복원한다. 리셋이라고 한다.ㄱㄷ
git rebase
git reset —hard 커밋해시
리팩토링 하기전에 커밋을 안하면, 복구하기가 되게 어렵다.
항상 뭔가 개발할때는 브랜치를 만들어서 해야된다.
reflog를 사용하면 reset —hard를 사용해도 된다.
git reset —hard 커밋로그 → 헤더 옮기기
git reflog
원본을 불변을 유지하는 것이 중요하다.
이전 데이터가 남아있어야지 복구를 할 수가 있다.
파일을 늘려가면서 관리 하는 습관을 키워야 된다.
폴더를 관리하는 것이 VCS
Cental version congrol system, 버전 관리를 서버에서만 한다.
Distributed Version control System.
깃허브는 모든 개발자들이 소스코드를 모아놓는 놀이터,
깃허브는 마이크로소프트꺼.
코파일럿
스쿼시, 리네임, 리칟ㅁ
git rebase — abort 는 rebase이후 모든 것을 버려라
git rebase —continue
마스터 옆에 rebase가 적혀있을때, 뭔가가 잘못된 것을 감지. 수정continue, abort 되돌아가는 것.
컴퓨터 실력은 디버깅하면서늘게된햐다. 에러문을 읽어야된다.
•
스쿼시
찌그러트린 애들이 최신 애들이어야한다.
햣
:
빠져나가기
명령행 모드
저장후 빠져나가기
일반모드
입력모드
i (insert)로 입력모드 변경 esc로 일반모드로 돌아올 수 있다.
vi
vi에디터를 사용할 줄 알아야 된다.