• 출처: 생활코딩: Visual Studio Code 로 다루는 Git - 버전관리편
• 출처: Git-Documentation-Book
• 추후 참고할것 : 코딩알려주는누나

Why 'git'?

• 버전을 업데이트 해나갈때, 만약 예전에 생성된 버그가 최근에서야 발견되었다면? 그 버그를 수정하려면 어떻게 해야하나?
  • 현재 수정본의 전수조사 vs 버그가 생성된 시점으로 돌아가서 확인 후 현재 수정본 수정
• 즉, 효율적인 버전관리를 위해 git을 사용해야 한다.

git의 매력

1. git의 불변성: git은 어떤 버전도 삭제하지 않는다.

2. HEAD와 master의 분리

3. branch

4. conflict 충돌

vscode로 git 사용하기

구조

: working directory -- add --> stage area -- commit --> repository(.git)

• HEAD: 어떤 버전이 만들어진 시점의 working directory 와 stage area 같은지 알려줌
• master: 마지막 버전이 무엇인지 가리킴
• working directory
• index = staging-area = cache
  : 사용자가 commit 할 때 git이 처리할 것들이 있는 곳
• repository(.git)

operation(행위) vs status(상태)

: 상태를 기억하고, 그 상태를 변경하는 행위를 알면 된다.

준비

• new window(새 창)

1. project 폴더 생성 -> vscode로 열기
2. 새 터미널 -> + 버튼 -> 기본 프로필 선택 -> Git Bash
3. 설정(ctrl + ,) -> exclude 검색 -> **/.git 을 삭제 -> 이래야 프로젝트 폴더에 .git이 생김. 즉 우리 눈에 보이게 됨
4. 터미널에 $ git init 입력
   : Create an empty Git repository or reinitialize an existing one
   : 깃에게 현재 디렉토리(폴더)를 버전 관리를 시킨다
5. 확장 - git graph 설치
6. $ git config --global user.name 'juyeonma'
$ git config --global user.email 'juyeonma9@gmail.com'

파일을 만들고, 입력하고, 올려보자

add 하고 commit 하자

1. $ git add work1.txt work2.txt
   : working directory에 있는 work1.txt과 work2.txt을 stage area로 add 한다

• add를 취소하고 싶다면?: $ git rm --cached work1.txt
• stage area에서 쫒아내고 싶다면: $ git restore --staged <file>
• 한번도 add 한적 없는 파일은 untracked file이다.

2. $ git commit -am "work_1"
   : stage area에 있는 파일들을 repository(.git)로 commit 한다. 그러면, stage area는 텅빈 공간이 된다.
   : add로 tracked 상태로 바꿔준 파일에 대해서만 -am 옵션을 작동하여 수정 시 또 add 할 필요 없이 바로 commit 해줌.(auto adding) 단 한번도 add 한 적 없는 파일은 여전히 add 하고 commit 해줘야 한다.
   : m의 의미: 뒤에 있는 내용이 메시지이다. 이 메시지는 동일해도 된다! 중요한건 commit id 니까.

.gitignore

• $ git add . (.:현재 디렉토리의 파일 전부) 금지!
  : config.txt 파일도 다 commit 되기 때문에, 큰일남!

  • config.txt: id나 password와 같은 정보가 들어있는 파일

• .gitignore 파일을 만들어서 그 안에 파일명을 넣어놓자

실수로 원격 저장소에 민감한 파일을 올렸어요!

$ git rm -r --cached 폴더 또는 파일명
$ git add .
$ git commit -am "커밋 메시지"
$ git push remote명 branch명

• 출처: git 저장소에 민감 정보 올라갔을 때 조치 | 특정 커밋만 삭제

head와 master를 움직이자

checkout vs reset

checkout: 시간여행

• $ git checkout 아이디: HEAD가 아이디를 가리킴
• $ git checkout master: HEAD가 master를 가리킴
  : 만약 master가 D를 가리킬때, HEAD도 D를 가르키게 하고싶으면?
  • git checkout D (아이디에다가 chechout 버튼)
    : HEAD와 master가 각각 D를 가르킴(HEAD -> D, master -> D)
  • git checkout master (master에다가 checkout branch 버튼)
    : HEAD가 master를 가르키고, master가 D를 가르킴(HEAD -> master -> D)

reset: 삭제/복원

1. HEAD가 가리키는 브랜치를 옮긴다. (--soft 옵션은 여기까지)
2. Stage Area(Index)를 HEAD가 가리키는 상태로 만든다. (--mixed 옵션은 여기까지)
3. Working Directory를 Stage Area(Index)의 상태로 만든다. (--hard 옵션은 여기까지)

• 'hard' 옵션
  : 워킹 디렉토리의 파일까지 강제로 덮어쓰기 때문에, reset 명령을 위험하게 만드는 유일한 옵션. 파일의 v3버전을 아직 git이 커밋으로 보관하고 있기 때문에 reflog 를 이용해서 다시 복원할 수 있다. 만약 커밋한 적 없다면 git이 덮어쓴 데이터는 복원할 수 없다.

• $ git reset --hard 아이디 : 삭제/복원
  : 만약 HEAD가 master를 가리킬땐, reset 하면 master가 움직임.
  : 그러나 HEAD가 master 이외의 버전을 가리킨다면, reset은 checkout과 같은 효과(즉 HEAD가 움직임)
  : 복원 하려면? 위험한 작업을 할 때는 이전의 commit id를 적어두고, 그 id로 다시 reset 하면 된다(git의 불변성!!)
  

parent

: HEAD가 parent
: 만약 새로운 버전 E를 만들었다면..

• HEAD가 master를 가리킬땐(HEAD -> master -> D), master가 따라옴(HEAD -> master -> E)
• detached head state
  : HEAD와 master가 각각 D를 가르킬 때는(HEAD -> D, master -> D), HEAD가 따라옴(HEAD -> E, master -> D)

branch 병합

• git merge 아이디
• 병합 취소하려면 git reset --hard 그전 버전명

conflict(충돌)

: 충돌은 나쁜 것이 아니다! 오히려 git이 얼마나 천재적인지 알게 해줌!

• 병합하려는 branch에서 서로 충돌하는 파일의 내용이 있는 경우, 선택지를 줌.
  : "어떻게 병합할래?"

  branch	Zero (분기점)	A	B	C (병합)
  file	zero.txt	a.txt	b.txt	a.txt b.txt
  	1	1	111	111
  	2	2	2	2
  	3	333	3	333
  	4	A4	B4	conflict

• $ git config --global core.editor "code --wait"
  : 기본 편집 스타일을 vscode로 설정

• merge 하여 conflict 해결한 뒤에 해야할 것
  : add하고 commit 해주면 창이 하나 뜨는데, 이 창을 끄면 성공적으로 병합이 됨

원격저장소: github와 연동

1. $ git remote add origin 원격 저장소 주소

• 삭제 방법: $ git remote remove origin

2. $ git push --set-upstream origin master
   : 로컬 저장소의 master와 원격 저장소의 master를 페어링 시켜줌

• origin/master
  : 어디까지 동기화했는지 기록하는 특수한 브런치

• $ git push: 원격 저장소로 업로드

• $ git pull: 원격 저장소에서 다운로드

• $ git clone 원격 저장소 주소 .
  -.: 현재 디렉토리로 원격 저장소를 복제한다

rejected은 conflict와는 상관 없다

: 협업 시, 원격 저장소의 버전을 갖고있지 않은 상태로 원격 저장소로 push 하면 rejected가 남. 왜냐면, push가 성공하면 원격 저장소의 버전이 유실되기 때문에!

• 해결 방법: pull 하면 병합한 merge commit이 만들어지고, 그 뒤에 push 하면 된다.

원격 저장소도 branch의 원리가 적용된다

• conflict가 일어나면, 로컬 저장소와 똑같이 해결하면 된다.
• 원격 저장소의 master: origin/master
  로컬 저장소의 master: 그냥 master
  -> 엄연이 둘이 다른 master로 취급된다. 그래서 conflict도 똑같이 난다.

그외

• $ git status: 깃 상태 확인

• $ git log --oneline --all --graph
  : 한줄로, 전체 다(master가 가르키는 부분도 보여줘)(reset 해서 사라진 부분도 보이게끔?체크), graph로(branch를 나타내줌) 보자

• $ git reflog: 지금까지 한 모든 기록이 나타남

• $ git config --global alias.l "log --oneline --all --graph"

• 삭제하는 방법은 vim ~/.gitconfig에서 수정

• $ git config --global core.editor "code --wait": 뭔지 모르겠음

• $ ls -a (= $ ls --all)
  : 숨겨진 파일도 다 보여줌
  : ./ ../ .git/ work1.txt work2.txt work3.txt

• $ ls
  : 현재 directory의 파일을 보여줌
  : work1.txt work2.txt work3.txt

오류

warning: LF will be replaced by CRLF in 안녕/안녕2.ipynb.

• git config --global core.autocrlf true
• 출처: https://blog.jaeyoon.io/2018/01/git-crlf.html

# 참고

• 출처: [GIT] ⚡️ 깃헙 Pull Request 보내는 방법 - 알기 쉽게 정리

• 출처: Git - Pull Request 활용하기

• 출처: git 초보를 위한 풀리퀘스트(pull request) 방법

궁금증, 어려운 점

1. 먼저 rm과 restore의 차이를 찾아보았고, 다음과 같이 이해했습니다.

• 출처: https://stackoverflow.com/questions/65434544/whats-the-difference-between-git-rm-cached-git-restore-staged-and-gi
  git rm --cached: working directory는 그대로, stage area에서만 파일 제거.
  git restore --staged: working directory는 그대로, repository 안의 HEAD가 가르키는 commit 버전을 stage area로 복사함. 즉 stage area에 아직 commit되지 않은 파일은 삭제되는 효과를 가지므로 이 경우에는 rm --cached와 같은 결과를 보임.

  다음으로 rm시 cached의 차이를 찾아보았고, 이렇게 이해했습니다.
  git rm: 원격 저장소와 로컬 저장소에 있는 파일을 삭제한다.
  git rm --cached: 원격 저장소에 있는 파일을 삭제하지만, 로컬 저장소에 있는 파일은 삭제하지 않는다.

  그리고 이에 몇가지 궁금증이 생겨 질문드립니다.
  1.git rm --cached의 경우 "stage area에서만 파일 제거" 라는 설명과 "로컬 저장소에 있는 파일은 삭제하지 않는다."는 설명이 모순되는 것이 아닌지 궁금합니다. push 하기 전에는 로컬 저장소에서만 작업이 이루어지는데, 로컬 저장소의 파일은 삭제하지 않는데 stage area에서 파일이 삭제된다는건 모순 아닌가요??

  2.rm --cached와 restore의 차이에 대한 저의 이해가 맞는지 궁금합니다. 만약 rm --cached와 restore가 동일한 결과를 보이는 경우가 아닌 예시가 무엇이 있을지 궁금합니다.