지옥에서 온 관리자 Git 1~10강 내용정리

Git 1강 -역사 및 배경지식

• 유닉스: 대형컴퓨터를 위해 나온 운영체제
• 리눅스: 유닉스를 개인용 컴퓨터를 위해 만든 운영체제 (리눅스 토발즈라는 사람이 만듦) 
• GNU(General Public License) 즉 GNU는 공개 소프트웨어 프로젝트 (리눅스 토발즈라는 사람이 리눅스를 개발하고 해당 제품을 팔지 않고 만든 개념)
• GNU 예) GNU개념을 갖고, A라는 프로그램을 만들어 소스코드를 공개했을때 어떤 개발자가 A프로그램을 기반으로 새로운 프로그램을 만들었을 경우 해당 프로그램도 공개되어야 함 
• DVCS (Distribution version controller system) :분산버전 관리 시스템,BitKeeper상용프로그램을 DVCS라 함 (GNU, GPL의 개념으로 많은 개발자가 A라는 프로그램을 개발할때 일정 분량을나눠 개발하고 관리 및 합칠 때 편리하기 위해사용하는 것)
• Git : BitKeeper 상용프로그램을 유료화로 변경하려고 할 때 무료로 버전관리시스템을 만듦 
• Git도 GNU기반이다  

Git 2강 - GitHub이야기 

Git은 프로그램

GitHub 개발자들의 코드가 저장되는 클라우드 저장소 

 

Git 4강 - 버전관리시스템이란?

VCS->버전관리시스템

file1.txt파일을 수정시 해당 파일에 데한 데이터베이스를 만들어 버전관리를 도와준다.

-> 만약 파일이 100개가 존재하는데 fil1.txt만 수정될경우 파일 100개를 저장하는 것이 아닌 부분변경된 부분만을 저장해 관리함

-> 바이러스가 걸리면 해결할 수 없다.. (어딘가에 백업을 하지 않았을 경우)

->vcs문제 1) 바이러스 2) 협업 x  (why? vcs는 로컬에서만 관리하기 때문) 

->위의 문제로 나온것이 cvcs 

cvcs란?centralized version controller system 즉 중앙집중형 버전관리시스템임 

-> cvcs는 협업가능 

-> 어떻게 ??? 중앙집중 컴퓨터에 각 코드들을 올려 관리함 

-> 위의 사진을 설명해보자면 .

1)은 만약 A가 file1.txt를 처음에 로컬에서 개발후 C(협업을 위해 코드를 같이 저장 관리하는)라는 컴퓨터에 업로드를 함

2) B가 C컴퓨터에 저장된 file1.txt파일을 받아, 수정후 C에 업로드

3) A가 본인이 올린 file1.txt파일의 수정 유무를 알지 못하고 기존에 자기가 작성한 코드(file1.txt의 원본)을 다시 올림 

4) B가 C컴퓨터에 file1.txt파일이 수정된 파일로 남아있는것이 아닌 자기가 수정하기 전의 file1.txt파일로 변경된 것을 모르고 다시 다운받아 개발함 

5) 이럴경우 B가 수정한 내용은 다 날아가는 문제 발생 

즉 CVCS에서 발생하는 문제는 

1) 협업을 잘 해야함 

2) 바이러스로 C컴퓨터가 날아가면???? 문제발생 

3) 끝점만 변경 기록함 (A라는 컴퓨터에 file1.txt 에 안녕아리는 내용이 저장되어 있음 ,해당 파일을 중앙저장소에 올리고 다른 B 컴퓨터가 중앙저장소에 저장된 파일저장, A컴퓨터가 file1.txt파일을 수정하여 안녕이라는 내용과 반가워라는 내용을 추가하여 저장하고 중앙저장소에 올릴경우 중앙저장소에서 기존파일은 히스토리 v1 , 새로 올려진 파일은 히스토리 v2 라는 식으로 히스토리를 관리하지만, 각 로컬 컴퓨터에서는 이러한 히스토리가 없음)

이러한 이유로 등장한 것이 DVCS(분산 버전관리 시스템) - Git

GIt 5강 - 분산 버전관리시스템

->분산버전관리 시스템과 중앙버전관리시스템의 가장 큰 차이는 히스토리를 로컬도 가지고 있다.

Git 6강 -Git 원리(3가지 영역)

- DVCS (Git)

- git init : 해당 폴더를 깃 폴더로 사용할게요

-> A라는 폴더에 test1.txt 라는 파일을 만들면 깃은 작업영역에서 일어나는 일을 인지하고 변경함지를 함 

-> 인덱스영역 (인덱스 =목차) (우리가 실제로는 볼수 없는 영역 ,트리 목차로 되어있음 )

->인덱스 영역이 만들어지는 시점은 git add 라는 명령을 할경우 

->git add :변경이 감지된 파일만 인덱스 영역에 기록됨 (tree라는 것 안에 )(tree는 폴더라고 생각해라)

(파일은 BLOB(Binary Large Object: 이진수로 된 큰 파일) 객체로 만들어짐)

->인덱스 영역을 영구적으로 저장하고 싶으면 헤더 영역에 저장하면 됨 

->헤더 영역은 브렌치로 즉 가지가 크게 하나 존재 

-> git commit :헤더 영역에 영구히 저장 

-> 즉 git commit 를 하면 초록색 테두리로 그려진 인덱스 영역에 해당하는 내용들이 헤더영역에 그대로 영구히 저장됨

->git commit는 영구히 저장한다.. 라는 뜻으로 이해하자

-> text2.txt라는 파일이 새로 추가되어 git add 후 git commit 시 git add에서 인덱스 영역에 저장될때 기존에 text1.txt파일은 기존 파일과 동일하기 때문에 해당 파일을 그대로 복사하지 않고 해당 파일의 해쉬값을 들고있는다.

Git 7~9강 -Git 기본기 실습

scm(형상관리,Software Configuration Management)

git init :작업영역을 만듦 

git status : 변경감지 확인 

git add . : 변경된 모든파일 인덱스 영역에 저장 (뒤에 . 이 모든 파일을 의미함 , git add 파일명 이런식으로 인덱스 영역에 저장가능)

git commit -m "영구히 저장하고 싶은 내용 올리기" : 헤더 영역에 영구히 저장 

git log -> 헤더에 기록된 내용들 확인 

Git 10강 -Git Reset명령어

git log가 맘에들지 않을때 log 를 복구하는 명령어 reset

reset 의 3가지 옵션 

1) hard -> test 1 상태로 돌아가길 원할때 

->test2에 대한 내용들을 전부다 지움 즉, test1.txt상태로 복귀

2)mixed->작엽영역의 내용 변경 필요

-> test2.txt파일은 남아있음 

3) soft ->커밋로그 변경시 

->즉 헤더 영역의 로그만 지움 

 

-git reset soft 사용법 (바로 직전의 커밋로그 변경하고 싶을때)

git reset --soft  돌아가고 싶은 상태의 commit 로그값  

-git reset mixed 사용법

git reset --mixed  돌아가고 싶은 상태의 commit 로그값  

git reset --hard 사용법

- git reset --hard 돌아가고 싶은 상태의 commit 로그값  

 

참고 강의링크: https://www.youtube.com/watch?v=p7Wd3p4hPCA&list=PL93mKxaRDidFtXtXrRtAAL2hpp9TH6AWF&index=11