[TIL] 26/09/09 - reset/restore/revert/branch/github

오늘의 키워드

• restore/reset/revert
• branch
• Github

---

reset/restore/revert

• 막상 사용하려하니 뭐가 뭐였는지 기억이 잘 안난다
• reset: 지우개로 과거 페이지를 완전히 지우기
• restore: 책의 특정 페이지를 복구
• revert: 틀린내용 긋고 새 노트 추가

1. reset
   reset --soft :
   스테이지 영역에(추적하는파일이니까) 파일은 그대로 남겨두고 커밋 메세지 등을 수정해서 다시 커밋하기 위한 목적으로 사용된다
   git reset --soft HEAD~ 로 쓰면 가장 최근의 커밋이 지워지는거니까 바로 이전 커밋으로 돌아간다!

   reset --mixed(default) :
   아무것도 안붙이고 git reset하게되면 실행되는 애가 mixed이다.
   git add로 추적하고 있던 파일도 지워버리는거임 << soft랑 차이점
   soft는 스테이지 영역 파일은 둔다했으니까

   reset --hard :
   사용에 주의가 필요한 hard이다. 커밋 이력 자체를 날려버린다
   가령 dummy.txt에 123을 쓰고 add하고 commit을 했는데 하드리셋했다
   그럼 123을 썼던 기억마저 잃어버리는거임
   

2. restore
   git add 전에 가장 최신의 커밋으로 돌리는거다.
   예를 들어서 a.txt를 수정(123작성)하고 커밋을 완료한 다음 추가 수정(456작성)이 일어났는데, 이 전으로 돌리고 싶다?
   그럼 add하기 전에 restore로 이전 지점으로 복구시켜주는거다.
   그럼 456이 지워지고 123만 남은 상태로 돌아가는거임
   그래서 책 특정 페이지를 복구한다고 한거네

   restore --staged
   앞선 상황에서 일단 add(456)를 해버렸어. 그럼 a.txt가 stage area에 들어가있겠지?
   그걸 복구 시킬 때 쓰는거야

3. revert
   특정 커밋을 취소한다
   좀 안전한 되돌리기라고 생각하면 된다.
   아래 그림이 reset과의 차이를 잘 보여준다.
   붉은 네모가 현재 지우고싶은 커밋이라고하면, reset은 그 사실 자체를 지워버린다
   반면, revert의 경우에 해당 커밋을 취소하되 변경된 사항을 현재 디렉터리에 반영한다
   예를들자면 마트에서 물건을 잘못삿는데, 리셋은 타임머신을 타고 돌아가 물건을 산 경험자체를 없애는것이고 리버트의 경우에는 영수증을 들고찾아가 환불을 받고 환불 영수증을 가져오는 행위라고 보면된다
   

   branch

   브랜치는 말 그대로 가지라고 이해하면 좋은 것같다
   현재까지 이해한 내용은 이렇다, github에서 레포지토리를 하나 만들고, git clone으로 저장소를 로컬로 옮겨온다. 그럼 기본적으로 main이라는 브랜치에서 실행되게되는데 공동 작업을 위해서는 main만을 이용하기는 어렵다
   이 때 사용되는게 branch이다 기능별로 branch의 이름을 붙일 수 있는데, git branch로 현재 생성된 브랜치를 볼 수 있고, git branch 이름 으로 생성할 수 있다.
   새로운 기능의 경우 feature, 핫픽스는 hotfix, 사소한 버그 수정은 fix 등의 이름을 붙인다
   각 브랜치에서 맡은 업무를 수행하고나면 git status로 변경 사항들을 확인하고 추적할 파일을 git add한다.
   이후 commit을 통해서 일종의 세이브 파일을 하나 만드는거지
   commit을 하게 되면 현재 작성된 코드들을 사진처럼 찍는다 해서 snapshot이라고 하는게 납득이 가능해진다
   지금 이 과정은 main이 아닌 새로운 브랜치에서 수정이 일어난거기 때문에 아직까지는 main 브랜치에 아무런 영향이 없다
   이제 git push origin feature/login 이런식으로 새로운 브랜치에서 한 일을 오리진(깃헙 레포지토리)에 올려주는거지
   여기서 PR을 생성하게된다 pull request
   깃헙에서 내 브랜치에서 수정한걸 메인에 합치고싶다고 알리는 것
   이후 리뷰 검토를 마친다.
   그럼 바로 변화되는게 아니라 merge가 가능한지 확인을 하겠지.
   충돌이 발생할 수 있기 때문이다. 여러 사람이 같은 영역을 다른 시간에 수정하거나 한다면 업데이트 되지 않은 부분을 수정하면서 버그가 발생할 수 있잖아
   머지가 완료되었다면 main 브랜치로 이동해서 최신변경사항을 pull 해오면 끝

   용어 공부

4. 처음에 레포지토리 만들면 로컬 환경에 받아와야 쓸 수 있잖아
   echo "# 123" >> README.md
   => 깃은 빈 폴더를 커밋할 수 없어서 리드미라는 마크다운 파일을 하나 만드는데, 레포지토리의 제목이 적힌 파일이다
   그럼 처음에 로컬에 올리는 과정마저 커밋이 일단 한 번 진행된다는건가?
   git init
   => 현재 내 폴더를 깃이 관리하는 로컬 레포지토리로 만들겠다
   => 사실 여기서 브랜치가 main/master가 생성되는데 최신버전은 main
   => 밑에 브랜치도 만들어지기 전에 커밋이 어떻게되는거지? 싶었는데 여기서 임의의 브랜치가 생성되는거임. 밑에 브랜치로 main이름을 짓는건 강제로 바꾸는거지 구버전에 master로 쓸 수도 있으니까 표준을 맞춰주는거다
   git add README.md
   => 처음에 만들어진 리드미 파일을 추적한다
   git commit -m "first commit"
   => 첫번째 스냅샷을 찍겠습니다
   git branch -M main
   => 현재 브랜치 이름을 메인으로 한다. 찾아보니까 옛날엔 master로 썼다고 하는데 글로벌 표준인 main으로 강제로 맞추는 느낌이다
   git remote add origin https://github.com/myhyeoeo/123.git
   => 내 로컬의 깃에 오리진이라는 별명으로 깃헙 레포지토리를 저장하겠다
   git push -u origin main
   => main브랜치의 세이브 내역을 깃헙 레포지토리에 밀어넣겠다
   -u는 앞으로 git push/pull만 치더라도 origin/main과 주고받겠다

5. origin과 main의 차이가 뭔가 헷갈린다
   오리진은 원격 저장소의 이름
   메인은 브랜치의 이름인데
   main은 로컬에 있는거고 오리진은 원격 저장소에 존재한다
   

git push <원격저장소> <브랜치> 
내 로컬의 브랜치를 원격 저장소로 밀어 넣어라
git pull <원격저장소> <브랜치>
원격저장소의 브랜치 최신내역을 내 로컬로 당겨와서 합쳐라

6. 그러니까 어쨋든 푸시는 로컬->원격 풀은 원격->로컬 이다
   내 쪽에서 하는 일이라고 생각하면 이해하기 쉬울거같다
   어쨋든 코드는 내가 짜고 나랑 가까운건 로컬이니까,
   로컬에서 푸쉬하면 원격 저장소로 가야되고 로컬 쪽으로 풀하면 원격저장소에서 가져오는 느낌인거지