Git add ~ commit ~ push 까지

깃과 깃허브의 개념

 

깃 : 로컬에서 버전관리
깃허브 : 로컬에 있는 것을 원격으로 올리는 저장소

 

깃의 버전관리 영역!! (파일의 라이프사이클)

Untracked : 버전관리 되기 전 파일들
Unmodified : 처음 저장소를 Clone 하면 모든 파일은 Tracked이면서 Unmodified 상태
Modified : 어떤 파일을 수정하면 Git은 그 파일을 Modified 상태로 인식한다. 커밋을 하기 위해서는 이 Modified 상태의 파일을 Staged 상태로 만들기 위해 git add 하고나서 commit!

삽질 1 : 파일을 수정하고 계속 커밋을 시도했었는데 git add를 안해서,, add 와 commit 을 세트로 인식하자

Staged : Git으로 버전 관리되는 영역

마지막엔 꼭 Commit!!!! 해주어야 버전 저장이 된다

---

[필수 터미널 명령어]

1) ls list (현재 경로 확인용으로 계속 확인해주면 좋음)
2) cd change directory
3) code . open VScode (대신 VScode에 shell 설치 되어있어야 함)
4) mkdir make directory
5) cd .. change directory to Parent Folder
6) pwd print working directory

---

[터미널로 깃헙에 프젝 올리는 방법]
터미널 단축키 ctrl + shift + ~

1) git init
"현재 폴더를 git으로 관리하는 폴더로 만들거야"

2) git add .
. 은 '전부 다' 라는 뜻.
"현재 경로의 모든 파일을 버전관리 하겠다!!"

3) git status
add한 파일들 버전관리 되고 있나 확인

4) git commit -m “first commit”
히스토리 만들기

ex. first commit, second commit, third commit…
최종 최최종 진짜최종과 같은 의미

5) git remote add origin https://github.com/furaha707/first-project.git
원격 주소의 repository로 내 소스코드를 업로드한다

6) git remote -v
원격주소와 연결되었나 확인

7) git push origin master
최종 푸시!

---

[추가/수정하면서 커밋하기]

1) 수정 후 git add .
--> 모든 파일을 항상 통틀어서 버전관리를 하면 오류 생겼을 때, 어느 파일에서 생겼는지 모를 수 있기 때문에 부분적으로 올리는 것 추천
2) git status 로 수정된 사항 확인 가능
3) git commit -m “modified”

---

[권장 : master 보다 main 브랜치 이름 사용]

git config --global init.defaultBranch main

--> 앞으로 git init 을 할 때 항상 main 이라는 이름으로 기본 branch 가 만들어지도록

git branch -m main

--> 현재 브랜치를 main으로 바꾸기. 이젠 git init 하면 항상 main으로 뜰 것이다^^

---

[커밋 되돌리기 reset --hard VS revert]

reset, revert 는 원격 X
local에서 일어나는 일들이라는것!!

1) reset --hard (soft, mixed 는 실무하며 천천히 이해해보자..)
타임머신 타고 되돌아가고 싶은 시점으로! 즉 목적지
지목한 시점 이후의 기록들은 없애고 그 시점으로 가버리는 것

--> 이미 푸시했다면, reset 을 로컬에서 사용하고 다시 푸시하면 반드시 충돌이 있기 마련,,

2) revert
되돌리고 싶은 작업 상태로!
revert 했던 기록들도 남겨짐

--> 협업 때 더 추천하는 방식. 기록이 남기 때문

나의 이해력을 도왔던 만화ㅋ
http://www.devpools.kr/2017/01/31/%EA%B0%9C%EB%B0%9C%EB%B0%94%EB%B3%B4%EB%93%A4-1%ED%99%94-git-back-to-the-future/

---

[Clone 과 Fork 차이점]

Git clone (내가 계속 써왔던 방식이다)

• 원격 저장소 (GitHub repo) 1개를 여러명이서 함께 사용하는 방식
• 원격 저장소 1개에다가 같이 작업할 사람을 collaborator로 추가해서 함께 작업
• 소규모 개발팀 / 스타트업

GitHub fork

• 원본 저장소 (GitHub repo) 를 여러 명 / 팀이서 각자 복제를 함
• 각자 자기만의 repo가 생김 (여기서 각자 개발 진행)
• 자기 repo의 수정사항을 원본 repo 로 반영시킴
• 팀이 너무 많은 개발단위 / 대기업

"제일 큰 차이점은 원본은 건드릴 수 있는 권한이 있냐 없냐!"